When we speak about DevOps, there is still a lot of confusion about what we mean, and rightfully so. DevOps is a confused concept. An approach that I and others have found helpful for approaching and understanding DevOps is the concept of a maturity model.
Maturity models are a relatively old tool in the organizational change toolbox. They theoretically allow us to grade ourselves and see where we stand in relationship to our peers and to best practice. Motivating change through fear and competition is an age-old tactic, but it’s not one that I find very interesting. More powerful uses of these models occur along 2 dimensions:
- Comparison to ourselves, measuring change over time
- Developing a vision of what success in our organization could look like in manageable stages
The latter is probably the more important capability that maturity models provide when starting off. I’m sure we’ve all heard, and ourselves expressed, the doubt that DevOps or some new approach or technology can deliver on its promises. As the old internet joke goes:
- Write unit tests
- ???
- Profit
Indeed, as with any hype-cycle-prone buzzword, it can’t fully deliver. But a maturity model with compelling examples can help us to see where we are and envision a realistic next step without necessarily having to embrace the grand vision of an end-state to which we cannot see a path.
These models can give us the impetus to get going. Can’t see yourself empowering your developers to push changes to production many times a day? That’s ok, neither can I. But maybe we can see ourselves putting a few tools and guardrails in place to give our developers a little more responsibility and self-determination by (for example), allowing developers to release their own transports to QA with automatic code checks as guardrails. Or perhaps we can enable our teams with a few automation tools to cut down on manual documentation tasks that no one wants to do. And once we’ve taken one step in that direction, how about another? What would that look like?
Soon we start seeing how we can get to the next plateau and plot the next stage our of journey. And as we start to make these small changes to move us to the next stage in the maturity model, we use that model simultaneously to keep ourselves honest and to show our progress. Have we reached that plateau where we can let off the pressure and look around or are we still on the ascent where we need to keep our nose to the grindstone and our eye on the prize? If we have concrete descriptions of what life looks like in the next stage of progress, we know what our target is and when we have arrived.
There is a lot more to discuss around maturity models. Therefore, maturity models and frameworks are themselves a dime a dozen: CALMS, Gartner, and CA to name a few. Additionally, each model tracks different types of capabilities and levels, and they envision different structures of the organization and different definitions of DevOps itself. However, the questions pile up as we dive deeper into them. What capabilities are the key pillars of DevOps? What levels should we use? Can our model change over time as we learn more about our needs? Similarly, is it important that the model stay constant even as we change? Can we pick particular capabilities and leave others by the wayside? Do we need an organizing principle like a framework or can we make progress organically?
On April 16th we’ll host a DevOps Roundtable event kicking off with a discussion of DevOps maturity. Also, these events are participant driven, and the conversation will follow the interest and experiences of the participants. You can learn more and sign up on the event page and join us for the discussion.
If you are interested in viewing similar articles, visit our blog, here.
View our LinkedIn, here.
