Fear Makes The Wolf Look Bigger
Change is Coming: The 3 Keys to the DevOps Revolution
The biggest impediment to the DevOps “Revolution” may be the language used to describe it. Many proponents focus on the automation aspect of DevOps. At its core automation implies giving up control and that’s a scary prospect. This tech-centric focus does a disservice to what DevOps is really about.
Automation is just one aspect of DevOps, and at the risk of committing heresy, it is the least interesting. Please, before you make a run on pitchforks hear me out.
DevOps is based on 3 key pillars: People, Process and Automation. I believe their importance to a business should be considered in that order.
People
The goal of DevOps first and foremost is to better understand and serve the needs of the business stakeholders. That includes application owners, end users, business departments, developers and IT operations. Without understanding the needs of the business and putting systems in place to gather that information consistently it is impossible to prioritize automation tasks. A typical enterprise environment may rely on hundreds of applications. Without knowing which applications are critical and what the needs of the stakeholders are how can DevOps determine where to focus efforts, let alone know what to measure to demonstrate value?
Sure IT Ops wants to make their jobs easier, but to what end if it doesn’t serve the needs of the business as a whole?
Process
Let’s be honest, people aren’t comfortable with uncertainty. And while processes can be unwieldy and an impediment to rapid change, they exist for a reason. It’s key to understand those reasons before attempting to automate. And where processes don’t exist, “unanticipated changes” can, from the perspective of a user consuming services, seem arbitrary. DevOps encourages focus on understanding and documenting process prior to automation. And when done right the DevOps process creates feedback loops to improve the process over time.
The output of good process is predictable results. In a 2016 State of DevOps report PuppetLabs reported that a high performing organization (for simplicity’s sake let’s define that as one well along the DevOps adoption curve) had a significantly lower failure rate when making changes (0–15%) than low performers (16–30%). Those high performers also reported a faster mean time to recover (MTTR) of less than an hour vs. their low performing counterparts who had an MTTR of less than a day.
Assuming DevOps evangelists are preaching the gospel of more rapid releases and continuous integration through automation can you see why a high failure rate and long MTTR the organization may currently experience could invoke a sense of fear?
Automation
Improve code quality? Increase release velocity? Absolutely important aspects of automation. But for the DevOps team the purpose of this automation is understanding of the flow of work from the business all the way through to customers, and whether they have visibility into this flow, including the status of products and features.1
And to become a truly exceptional DevOps organization the focus needs to be on actively and regularly seeking customer feedback, and incorporating this feedback into the design of their products.2
Final Thoughts
No one familiar with the successes seen in high performing organizations will discount the power of DevOps. But focusing on the tools and automation aspects alone does a great disservice to the hard work those same DevOps teams did in the people and process areas. The tools enabled their success but their focus on people and process was the engine that drove it.
- State of DevOps Report pg.34
- IBID
