Having focused on the DevOps subject for some time now, I’ve been looking at how to characterize the maturity of enterprises in the DevOps space. And I found some quite interesting elements. Typical DevOps maturity models focus on the automation and technology, while separate agile models focus on culture and processes. Interesting. Sure you can do DevOps without Agile and Agile without DevOps, but aren’t both doomed to work together? Do you really need DevOps if you do one or two deployments a year? And can you really do Agile without automation.
As you can guess, my answer is no. I strongly believe Agile and DevOps are to me like the two sides of the same coin. Sure they started from different points of view, but are quickly coming together in addressing the increased need for IT to respond to the responsiveness requirements of the business. I also assumed that deployment happen in cloud based environments as this is the natural complement to DevOps. It may seem like a lot of assumptions, but frankly, most customers I’m talking to, highlight all three in the same sentence.
So, I tried to combine both maturity models into one. I did not start from scratch, I actually started from what I found on the internet in general and from “the Agile Maturity Model applied to Building and Releasing Software” from ThoughtWorks in particular. I’m not considering the maturity model as being definite, rather as work in progress for which I’m interested in feedback.
As many other maturity models, I used a CMMI type 5 step model, going from 1, fundamentally no DevOps implemented to 5, a fully integrated approach. I also identified a number of characteristics that are critical for the maturity. These comprise:
- Organization, focusing on the organization itself, how the boundaries are identified, how the culture evolves. Here we go from a scattered organization where each team works in isolation to one where cooperation and sharing is part of the culture. Tasks are dispatched to avoid bottlenecks and knowledge is shared. Continuous improvement is in place, so teams adapt their processes and procedures based on past learning.
- Teamwork goes from nonexistent to be at the center of the values. People are helping each other out to a common objective. Communication is of the essence. Success is celebrated and seen as an achievement of the team, not of individuals. People are empowered to take decisions and move things forward, and feel recognized for the work they do.
- Build Management & Continuous Integration, go from manual processes to fully automated ones, freeing the developers so they can continue their development work. Beyond the actual automation, the focus moves to the resolution of automation problems, the standardization of builds and deploys and the use of the appropriate environment for each step in the development process. Re-use and automation are at the core of the effort.
- Continuous Delivery / Deployment. Where the previous point is focused on the integration of the different steps in the development process itself, and as such with agile, this point really looks at the integration of development and operations. The maturity goes from manual development performed by the operations teams to fully automated ones triggered by the developers themselves. This is one of the areas where the transition to full DevOps succeeds or fails, that is why I kept a separate columns and put it right in the middle of the model. How far you go in the automation of the deployment really depends on the system type (see previous blog entry). If you end up doing several deployments a day, you may want to fully automate the deployment of all changes automatically to production (Continuous Deployment), for others, continuous delivery (improve and automate the software delivery process) may be enough.
- LifeCycle Management and Compliance, what ultimately counts is the management of the lifecycle of the application, from initial development to end of life. This lifecycle crosses both development and operations. In traditional approaches, new functionality is created by development while fixes are done by maintenance teams that are typically located within operations. Agile and DevOps change that paradigm and have one team responsible for the evolution of the application. In the traditional approach, the lifecycle management is manual, releases are infrequent and things happen ad-hoc. In a mature devops environment, not only is the lifecycle fully managed but it is also included in a project and portfolio management environment allowing to capture user requirements, prioritize them, manage the development cycles and allocate the budgets.
- Testing, is an area that consumes time and resources in traditional development. Automating the testing process frees-up developers for coding functionality. Testing can be automated at all levels, unit, module, integration etc. This however requires the development of appropriate test scripts and the provision of test data. As maturity improves, not only is testing automated, but it is also formally included in the development process so it becomes a standard part of the process rather than being an ad-hoc activity done occasionally. Automation allows the implementation of measurement which leads to the possibility of doing continuous improvement. So, identifying the problems, understanding where they come from and highlighting what needs to be done to avoid them in the future are key criteria for a learning organization. Ultimately that is what we want to turn the development and operations teams into. Manual interventions become the exception rather than the norm.
- Data & Integration Management. The last area I want to highlight is not directly related to the development and operations processes as such, but moves the environment to what is known as a platform service. In building applications, developers are calling on data structures (typically databases) and integration middleware to allow application components to talk to each other. As we move to cloud and to the full use of cloud functionality, standardizing the data and integration services is quickly becoming critical. By automating the deployment of such functionality we facilitate operations, by transforming it in a aaS service we remove the need for the developers to focus on data structures and integration tools.
So, having explained the commons, here is what i came up with:
First of all, do you believe there is anything major that I missed in this description? Second, are the level descriptions accurate and are they at the right place. I had following ideas in mind when defining the five layers:
- Initial: The traditional development environment where dev and ops are completely separated and applications are handed over.
- Managed: initial understanding is gained in development and/or operations that something needs to happen. In development the focus is on agile while on the operations side initial automation is experimented with. The organization starts to understand it needs to collaborate and share experience. Typically pockets of people are starting while the others are still doing the classical way.
- Defined, a companywide approach is taken, things are structured. Not everything may be in place as the organization is learning, but processes are defined and automation is established.
- Measured, now the processes and automation are in place, the team starts measuring to gain a better understanding of how they are doing. This enables continuous improvement and that is the objective of this layer. Waste is taken out of the system and a culture of improvement is established.
- Optimized, when things are firmly established and this IS the way things are done. People are recognized for their achievements, success is celebrated. The boundaries between the columns is disappearing as the organization has full end-to-end view.
Actually, I do not believe any organization is at the optimized level yet, but a number of them are at the measured level. What is important is for enterprises to understand where they are on each of the topics and how they should evolve. What do they need to focus on? How can they approach things? That’s the reason for putting such maturity model together. Again, tell me what you think and how that resonates with you.
The original version of this blog entry was plublished on the CloudSource blog in May 2015