The internet is awash with useless discussions that overcomplicate DevOps and its key concepts. If we don’t keep DevOps simple, it will knock team confidence and limit progress
Back in the early 2000s, many freshly minted engineers were eager to learn about everything and anything. The advent of the new technological world meant that there were a few topics that were rather abstract and made any discussion on the topic deeply philosophical.
The best example of this was probably “Web 2.0”. What was it, really? There was always a voice out there – a blog, an interview, an opinion piece – that would claim that everything you thought you knew about Web 2.0 was wrong, because “the real” Web 2.0 was not this trivialised “thing the average Joe was talking about”. What generally followed was a word soup either aimed at pitching vendor uniqueness or raising the profile of a sophisticated speaker, rather than really clarifying what Web 2.0 was about.
Increasingly these days, the same seems to be happening in the DevOps space. On a near daily basis, new articles are published claiming “This is NOT DevOps” and “You don’t get it, DevOps is not about this!” or “This is not how you do continuous delivery,” and so forth.
While well-intentioned and often with a precise mental model in mind, the reality is that these articles are not really helping, but just creating more confusion at a time when – if anything – companies need to grow their confidence in their ability to drive digital transformation. What’s more, people seem to actually have a pretty good view on what it means already.
Keep DevOps simple
So, let’s make it very simple. DevOps is about breaking the silos that exist in IT and in the business. Visualise old style vertical teams and departments: Engineering, QA, IT Ops, product owners, etc. Each department has its own policy and well-defined “interfaces” that define how a development team pushes new code to QA environments, how and when that code can be pushed to production, and so on.
Now, visualise horizontal slices of these teams, one slice per product. Team A is focused on the success of product A, they define one way to work together for that success and share expertise to get there. Some companies will merge some roles, others will keep distinct roles, it doesn’t matter: Businesses are living DevOps when their cross-functional teams feel their “first home” is their product team, not their department.
From there, either tool A or tool B can be used with whichever methodology is preferred, it does not matter. The right methodology is the one that fits with the company’s DNA and helps reinforce the right DevOps motion. Companies do not need to worry about whether something “is” or “is not” DevOps, as what matters is the change of behaviour that is being driven.