I was at a conference recently when I saw it. I sighed and shook my head.
A development manager from a large enterprise organization was explaining how they had created a DevOps maturity model based on CMMI. They went on to describe their current state of maturity and their plans to get to ‘full maturity’ in the next three years. He continued by explaining how they had presented this plan to executive management and subsequently received approval for a new ‘DevOps team.’
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again.
Unfortunately, we’ve seen this movie before, and we know how it ends: badly.
The Danger of Maturity
Perhaps I’m overreacting. I am sure that organizations that go down the maturity road are well-intentioned. The challenge, however, is that once an organization starts talking about maturity, benchmarks, and comparing itself to its peers, it always seems to be the beginning of the end.
In my previous life as a consultant, I conducted many maturity assessments (not of DevOps, but in several other areas). I always hated doing them. I knew that they would provide limited value, except to make the client feel that they weren’t doing “too bad,” and then to point out all of the areas in which they were deficient — so that we could sell them more consulting to fix those things.
At some point, I decided that I had played this game long enough and, therefore, stopped doing assessments. The great irony, however, was that my clients begged me to keep doing them.
What I discovered was that enterprise executives loved having these external assessments done for them. It allowed them to show that they were progressive, monitoring their current state and taking action to improve.
It was great political cover. But it almost never resulted in any marked improvement in the organization’s operational state. It was just a dance.
The Risks Inherent in ‘Doing DevOps’
As DevOps adoption increases across many enterprises, there has been a predictable rise of DevOps maturity models, mostly from consulting and technology companies, to help them assess their current state — and, of course, to sell them more consulting or new technology to improve their maturity.
And like all maturity assessments that have come before them, it is unlikely that they will lead to any significant organizational transformation, but instead merely give enterprise organizations political cover, confident that they are ‘doing DevOps.’
Consulting and technology companies often create assessments to assess the progress of things like DevOps because they are essentially cultural transformations. As such, these efforts are unlike traditional IT projects and are difficult to measure and report progress.
Enterprise executives, always under pressure to justify their resource spend and activities, are therefore willing consumers of these assessments, because they help leadership justify its efforts. For the same reason, executives also start to create structural edifices that likewise help them communicate to the organization that they are taking action.
These political demands are why there has been a recent trend within large enterprise organizations to create new DevOps teams and new roles such as the ‘DevOps engineer.’ But these creations not only miss the point, they actually increase the risk of undermining the very cultural shift they are trying to (or should be trying to) create.
At its core, DevOps is a cultural transformation — a new way of working and collaborating — that brings the organization together to deliver better services more efficiently, rapidly, and reliably. While adopting DevOps principles in narrow bands within an organization made sense for companies experimenting with this new concept, the entire organization must ultimately apply such principles holistically throughout the enterprise to be both effective and transformative.
The creation of DevOps teams or new DevOps-specific roles is antithetical to this objective.
Don’t Confuse DevOps with Continuous Delivery
Organizations should not view DevOps as a project or even a methodology, but instead as an overarching philosophy that governs how the entirety of the IT organization operates. To a certain extent, the use of ‘dev’ and ‘ops’ in the name creates a false impression of its real focus: creating a collaborative and integrated operating model for IT —and over time, for the entire organization as it becomes increasingly software-defined.
But rather than this holistic approach, many organizations view DevOps as just another development methodology and as synonymous with deployment automation. They, therefore, attempt to apply it on an application-by-application basis. This approach is wrongheaded.
Organizations should not confuse DevOps with its closely-related cousin, the Continuous Delivery (CD) movement. CD is essentially a structured process by which developers continually integrate code throughout the development lifecycle and, using high degrees of automation, rapidly test and deploy that code into production.
CD is a powerful approach that can increase organizational agility, dramatically decrease time-to-market and improve software quality and reliability. It is often critical for any customer-facing, business critical application. But it is not necessarily a good fit for every application within an enterprise.
In enterprise organizations, there are many applications, which, while critical to business operations, are not providing competitive advantage to the organization and simply do not demand the rate of change or warrant the investment in automation that CD provides and requires. Organizations should, therefore, apply CD principles on an application-specific basis.
This is not true of DevOps. Instead, organizations should adopt it holistically, embracing it as the new way work gets done within IT, and by extension, throughout the entire enterprise – what Intellyx calls the DevOps Virus.
The Intellyx Take
In all of the swirl and hype that surrounds DevOps, there is one group of organizations that never talk about maturity: DevOps pioneers.
Sitting at that same conference where I heard the enterprise application manager regale us with the stories of his DevOps maturity model, I also had the opportunity to gain insights from one of the founders of the DevOps movement at Netflix.
Never once did he mention the word ‘maturity.’ Instead, he talked about the business objectives they were trying to achieve. He discussed how they were continually seeking to improve their deployment processes. He shared how they were always looking for ways to make both their systems and their development efforts more resilient. He explained how they were applying new tools to help them on their quest.
But he never talked about maturity.
Having spent the early part of my career in a large enterprise, I am well-versed in the political reality that is corporate IT. I understand the razor’s edge that enterprise executives must walk to get things done and move the organization forward while dealing with the constant push to reduce costs and justify resources.
Conducting maturity assessments and creating new organizational teams and roles are understandable reactions to these pressures. But allowing the organization to go down this road puts it at risk of undermining the cultural transformation that must be at the heart of DevOps adoption.
Copyright © Intellyx LLC. Intellyx publishes the Agile Digital Transformation Roadmap poster, advises companies on their digital transformation initiatives, and helps vendors communicate their agility stories. As of the time of writing, none of the organizations mentioned in this article are Intellyx customers. Image credit: Darion.
Comments