In my last blog post, I looked at cargo cults and how they pervade DevOps thinking in many businesses. Simply put, in many cases, DevOps is not fully understood, but certain elements of it are nonetheless recognised and implemented. This results in an incomplete and often inadequate emulation of DevOps that can actually cause more problems than it solves, with senior IT professionals simply missing the point.
DevOps is a mindset and cultural issue not a department, job or even set a of discrete tasks! Unfortunately, this aspect doesn’t gel well with traditional approaches to IT, and the result is a kind of inappropriate amalgamation of the two.
One of the biggest mistakes that organisations make is to directly associate automation with DevOps. The simple fact is that while automation might be part of a successful DevOps implementation, it’s not actually a necessary facet of DevOps in general.
For example, I was recently talking to a head of engineering at a large financial institution. He told me he had been informed that the board had decided to initiate a programme to automate all their infrastructure provisioning. His primary concern was that this would probably happen in isolation to the development tooling already in place.
This, of course, misses the entire point of DevOps, where automation is good but not entirely essential. Automation will make things work better but only if it exists in a framework that allows it to do so. Yes, you’re going to see improvements in performance and, hopefully, reliability if you automate – but you’re not going to change your world.
And, of course, this development in isolation is simply maintaining the silos already in place – the antithesis of what DevOps is trying to achieve.
I’ve actually heard people say “We’ve bought JIRA Agile (as it was called – now part of JIRA Software) so we’re now an agile company”. Here, we’re getting “We’ve automated ops so now we’ve got DevOps”. Nothing could be further from the truth – this sort of position is fundamentally flawed. Neither DevOps or Agile are simple paradigms where you can follow a prescribed set of rules and you’re done.
The whole point of DevOps is to create seamless integration of and collaboration between development and operations, breaking down silos in the process. That, however, has not stopped companies from setting up dedicated DevOps departments or advertising positions for ‘DevOps engineer’.
The flaw in this thinking should be evident. By creating specialist jobs and departments for DevOps, all you do is create yet more silos, putting middlemen into a situation that is crying out for consolidation of influencing parties.
I recently heard a presentation from a senior manager at an international airline, who was describing their journey towards DevOps. Having heard that DevOps was about getting development and operations to work better together, they created a DevOps team to ensure that work flowed from development to operations effectively. And they were also to ensure that operations data flowed back to the development teams effectively.
What they learnt was they had simply created a further disconnect between development and operations. Rather than bringing those teams together, they had widened the gulf and introduced a bottleneck that just exacerbated their problems. In fact, the DevOps team became a significant roadblock and became the whipping boy for any problem or delay that was encountered.
I understand that this became such a burden that the entire team quit as one – leaving a yawning gulf in their wake.
Need help with your DevOps strategy and tooling? Contact us at email@example.com to find out what we can do for you.