DevOps has transformed the IT industry by changing how teams within an organization operate, collaborate and deliver from inception to operations. Most organizations have already begun the transformation journey to implement various aspects of DevOps to improve their delivery chain. Many of these organizations are already reaping the benefits from a Time to Market, resource savings and cost benefits perspectives.

But have they really reached the potential of what a complete DevOps strategy has to offer? Is there a mechanism in place to measure their improvements? Is there a methodology in the way they analyze the results and work towards continued improvements?

Often we see an organization make considerable investment to implement a DevOps strategy but once the initial implementation(s) is complete, no matter how successful, it may become stagnate. It’s so important that organizations of all sizes understand that DevOps is a journey and NOT a destination.

This is where a DevOps Maturity Model will help!

A DevOps maturity model determines growth through continuous learning from both teams and organizational perspectives. It allows for an organization to properly asses and measure where they are in their journey and enable them to plan out to address gaps via process, people, capabilities and/or tooling.

The Challenge

The following are the 7 key practices of DevOps:

1. Configuration Management
2. Continuous Integration
3. Automated Testing
4. Infrastructure as Code
5. Continuous Delivery
6. Continuous Deployment
7. Continuous Monitoring

The major challenge that we face is that these practices begin from inception to ongoing operational activities. For those who are familiar with IT Maturity Models, you will know that to cover all aspects of DevOps, it may require multiple models such as CMMI, ITIL/ITSM and Agile Maturity Model.

Unfortunately, in the space of DevOps Maturity Model and the explosion of DevOps popularity, there’s a number of models available for organizations to measure themselves up against, but not one of them has yet to take the lead as the de facto standard. For the sake of this article, we’ll limit the review to two. One generic model and one vendor driven model.

Review of Two DevOps Maturity Models

The first is a generic Maturity Model for DevOps which ranges across many areas including culture, build/deploy, release and more. This particular model follows the Crosby/Humphrey approach. In of itself, there is a lot that is self explanatory as the model breaks out into 6 core categories with 5 Levels of maturity. Within each section is a description and an associated expectation provided. At first look this a tremendous start to any view of what level your organization is at.

The challenge is that because it’s a common framework, it’s not prescriptive on how the categories can be measured or assessed. There’s no formal audit such as a CMMI type model that can be applied nor any standard definition of terms and compliance. That said it does allow for an organization to have a framework to build from. Typically, if there’s no Process Engineering team within the organization, many would require the expertise of IT Consulting firms whom have built on top of the framework to aid in defining the state and roadmap to DevOps maturity.

The second Maturity Model details the progression of improvement applicable to the build and release domain. The diagram below represents a version of the DevOps Build/Release Maturity Model from IBM. The benefit of this model is that it has the power and the resources of IBM behind it. The framework is well documented and has a tonne of material to support the implementation, measurements and on-going assessment. It is absolutely the closest thing to a well defined standard as I’ve seen in the DevOps Maturity Model space.

The challenge (Or benefit to some organizations) is that it’s an IBM proprietary Model. To take full advantage of all aspects (Use of model, training, support, consulting) you will need to go through IBM which to some organizations can be an expensive venture.    

What about CMMI?

Unfortunately CMMI does not yet have a model for DevOps specifically. The said, a CMMI framework is a solid foundation to build from. Some of the benefits of a CMMI like model is the structure and rigor in which the model can be measured through the level of documentation and suggested options built into to help guide an organization. Through audits (I know bad word, but shouldn’t be) we can continuously measure the level of maturity through evidence based reviews.

Perhaps the most important aspect that I’ve borrowed from CMMI that I feel ALL organizations should undertake no matter which model they apply, is the concept of an SEPG or Software Engineering Process Group.

This is the team or individuals who would be responsible for:

1. Coordinate Process Improvement initiatives
2. Coordinate metrics and work product evidence collection
3. Lead Change Management activities related to DevOps improvements (tools, processes and capabilities)

In Conclusion:

Unfortunately there’s no silver bullet or clear path for an end to end successful DevOps implementation. Once again, the process is a journey and not a destination. This journey will be completely different for every organization.

The good news is that we can start to measure our DevOps capabilities, collect metrics and work to continuously improve with the use of a Maturity Model and associated industry best practices. By committing time and resources to measuring and continuous improvement, your organization will be in a better position to take on whatever disruptive technologies, capabilities or methodologies that will come.

Please let us know if you have any feedback regarding this article. We’re also happy to help with any guidance related to maturity models for your organization. Reach out to us at info@bgmot.com