The Urgency for DevOps Adoption
Whilst working on the recently published whitepaper “Enterprise DevOps: Building a Service Oriented Organisation” one thing we had to give consideration to was what role, if any, Bi-Modal IT (or other similar models) should play. Our early drafts had no mention of Bi-Modal IT, but during the revision process we concluded that a paper about Enterprise DevOps would not be complete or credible without addressing it. In the end, this led to one of my favourite parts of the paper, our model for the urgency of DevOps adoption. But before I describe that, let me explain how we got there…
Firstly we had to think about whether it makes sense to apply DevOps to all software work within an organisation. My view is that because DevOps is not a highly prescriptive methodology or one-size-fits-all approach it can be applied universally. Many believe that DevOps should only be used where speed is important (and robustness less so) but, as I said in my post DevOps Everywhere, this is not true:
Should the choice of whether to adopt DevOps be based on a trade-off between speed and risk? The answer is no. Because this dichotomy does not exist. Yes DevOps increases agility and reduces lead times which allows you to respond faster in rapidly changing complex business domains. But this is not at the expense of robustness. The opposite is true: DevOps is more rigorous and achieves higher levels of quality.
At around the same time (and completely independently of me), two very eminent DevOps proponents wrote posts containing a similar message. Martin Fowler said this:
One of the striking things that we learned at ThoughtWorks when we started using agile approaches for rapid feature delivery is that we also saw a dramatic decline in production defects.
There is a false assumption that is still pervasive in our industry: that we must trade off responsiveness against reliability. The conventional wisdom is that if we make changes to our products and services faster and more frequently, we will reduce their stability, increase our costs, and compromise on quality.
This assumption is wrong.
Companies like Amazon and Google haven’t beaten all-comers by building flaky, insecure systems. What’s special about the DevOps movement is that it represents a game changer, a true paradigm shift. The people who built the DevOps movement had to solve a wicked problem: how to build reliable, secure distributed systems at an unprecedented scale, while enabling a rate of change orders of magnitude faster than the industry had ever achieved.
Once you conclude that it is desirable (and in some cases essential) for an organisation to apply DevOps everywhere, the question then becomes what approach you should take to the transformation? Do you try to roll out DevOps across the organisation as fast as possible? Or do you take a steadier approach, starting with the areas where it will be easiest to be successful and demonstrate value? Our conclusion was that which approach you choose should be governed by how urgent the need for DevOps is for your business. Furthermore, our experience suggested that this urgency would be largely influenced by the extent to which your business differentiates itself using software and how dynamic the business environment is in which you operate:
From this we decided to view Bi-Modal IT as a useful model for choosing how to target DevOps adoption within an enterprise if the overall need is non-urgent. And of course Bi-Modal is not the only game in town for this: Martin Fowler’s Utility vs. Strategic could also be used (and is an approach that I happen rather to like).
One criticism that has been levelled at the Bi-Modal IT model is that its approach for targeting the use of more agile ways of working is inappropriate:
If you want to rapidly cycle new ideas, you are going to need to modify the back office systems of record just as frequently as the front office systems of engagement. You can't come up with clever pricing plans without modifying the systems of record that support them.
Indeed I made a similar point during this video discussion: “There is no point having a team that can deliver a mobile app quickly if as soon as they need a change to the back-end it takes a year”. And in this analysis of why a large government project struggled to deliver the expected results, this was also one of the factors cited:
They were messianic about building the front end, doing it in an agile way, front facing, with their beautiful apps, and they were right about all of that…But they had no grasp of how complicated it was to tie the front end to the legacy back-office, these old and creaky legacy systems we have, with which it had to work.”
However to use this as a criticism of Bi-Modal is, I think, unfair. Bi-Modal suggests using Gartner’s own Pace-Layered Application Strategy. Whilst I think the choice of the term “Systems of Record” was perhaps unfortunate as some have interpreted that as meaning “legacy” or “back-office”, in practice it is a method of classification that “reflects how the applications are used and their rate of change” rather than whether they are front-office of back-office (or shiny new systems written in node.js vs. legacy applications written in COBOL). Indeed, I once introduced build automation and Kanban to a team developing primarily in COBOL which resulted in improvements in responsiveness, predictability and reliability (that were needed at the time). It may not always be easy or obvious how to implement DevOps in these environments, but that does not mean it is not possible or any less desirable.
Even though Gartner’s paper makes it quite clear that for most organisations “Mode 2 will start modestly, with a project focus; but as it expands, Mode 1 will shrink”, I do accept that a possible danger with Bi-Modal IT is that it could lead to a division in an organisation between Mode 1 and Mode 2 which may entrench positions and could make enterprise-wide adoption of DevOps harder in the long run, rather than easier.
Of course many organisations simply do not have the luxury of taking a phased approach to DevOps adoption. They are on the burning platform and it is time to do DevOps or Die. As Jean-Marc Cadudal put it: “Where companies are in danger from new-entrants, or where competition is very high, there is little choice but going full-speed to DevOps”
Fortunately, for those businesses that do need to transform urgently, and as described in our whitepaper, Kanban “provides a low risk way to implement a DevOps philosophy and drive the required change in culture and mindset". And recent reports are continuing to confirm that it is both effective at scale and less costly to implement than other approaches:
Three large Chinese companies have Kanban implementations of 3000 to 5000 people.
One reports productivity improvements of 10-50%, averaging over 25%. The introduction of Kanban at scale in their organization, across more than 10 product units, has produced productivity gains equivalent to hiring 1250 additional engineering staff.
The firm now intends to scale the success of this pilot to around 100,000 workers.
Costs for adopting Kanban appear to be in the range of 1/10th to 1/30th the cost of adopting alternative modern management techniques.
I know that not everyone agrees with my view that DevOps is the right choice everywhere. And I accept that there is still much debate around the validity of Bi-Modal IT. I do however hope that people will find our model for the urgency of DevOps adoption helps them understand how quickly transformation is required.