DevOps is about improving the vital intersection between Development and Operations, yet the concept itself has reached a critical crossroads. Simon Kent says it’s time to adjust course before DevOps hits the road to disaster.
I’m all in favour of DevOps. Anything designed to improve communications and facilitate collaboration in IT is valuable. IT has a poor track record of communication and collaboration, so in acknowledging and addressing these deficiencies, DevOps has clearly an important role to play.
However, as the hype around DevOps grows, I see it headed in a potentially disastrous direction. Why? Because too often, the positive conversations around DevOps belie the fact they are still too inward focused. IT’s biggest problem is that it sees the world inside-out, viewing business technology through the prism of its own problems. Successful business IT operates outside-in, understanding the challenges faced by the business from an outside perspective.
DevOps condones a collaborative, outside-in approach to ensure the services being built and supported serve a definitive business purpose. However, if the conversation and thought processes around DevOps continue to be inside-out, nothing will change and DevOps will be labelled a flop.
Wrong approach
Take a look at the Wikipedia definition. Yes, Wikipedia entries are not definitive or official, but they tend to reflect the general consensus and for that reason can offer a useful zeitgeist summary.
Where in this definition is mention of business need, business value, business outcomes, business strategy etc? Yes, it mentions collaboration and communication, but the language is pure ITIL circa 1998. In other words, DevOps is in danger of being another process, another tick-in-a-box.
Similarly, this ITSM.tools article features a number of highly respected ITSM commentators explaining DevOps in 40 words. The quotes very clearly explain what DevOps is and why it is needed. However, I see little thought put into ‘how’ it will work. Yes, the interviews had limited scope to offer detail. However, given that the ‘how’ will ultimately decide whether DevOps makes any real contribution, it’s a worrying oversight and an indication that DevOps is on a dangerous path.
In fairness, I see the deficiencies of this article on other blogs, social media and in face-to-face conversations. The mistake is identifying the problem and presenting DevOps as a magic-bullet solution.
DevOps isn’t a product or absolute method. It cannot be distilled into a training programme that once passed, will guarantee its graduates a fix. DevOps can’t be purchased and slotted into the organisation. This is why DevOps is in a precarious position. Unless we take the correct step in the correct direction, DevOps will potentially achieve NOTHING.
The missing element of DevOps
Paul Wilkinson is right when he says “DevOps should be renamed BizDevOps”.
There is nothing wrong with the concept of DevOps. But DevOps on its own isn’t sufficient, you must include Business Relationship Management (BRM) to ensure business stakeholder value is being developed, realised, optimised and maximised.
Relationships are the fulcrum, the critical element of DevOps. Yes, we can automate processes, change the feedback process and create a platform for development and operations to work side-by-side. But without relationships being acknowledged and addressed, we’ll just be left with a new set of ideas and processes. If we fail to consider business needs and business outcomes, DevOps will have a disastrous ending.
BRM itself isn’t a magic bullet. But it must be part of the DevOps conversation and we must stop trying to avoid the elephant in the room that is stifling business IT.