Your organization is probably in the middle of a DevOps transformation. Perhaps you struggle to get there. Great questions are: where did you start, what went well and what could be better?. The most important question is: “where are you now in your journey”. It could be the case that a lot of organizations have the same questions. It’s not easy to find answers that apply to all organizations since a DevOps transformation affects all of the departments and all organizations are different. Can a framework help here? At which maturity level are you? Meet the DevOps Maturity Model.
Do you need it?
Before diving into the details of the Maturity Model, let’s first try to answer the main question: do you need this model at all?
If you are a brand new startup that completely immersed in cloud-native without any legacy, delivering reliable software from source code to production quickly and without a lot of errors, security issues and so on, you’re in good shape. Even better if you already collect continuous feedback to improve the next iteration. This proves you have automated a lot of steps from the software development lifecycle. Things look promising when you are at this maturity level.
But what about large organizations with legacy code, long-winded approval processes, siloed teams and lots of manual handovers? Companies who react “ad-hoc” to external changes and disruptions of their production environments. Imagine there are a lot of developer teams without experience with CI/CD, DevOps, and production monitoring. Then you definitively benefit from using a DevOps Maturity Model to chart your course.
What is it?
A DevOps Maturity Model is a conceptual model in the form of a matrix of maturity levels at one side and areas (with subtopics) at the other side. Organizations use these models to determine the current (and desired) level of DevOps related topics.
DevOps itself is not just about having a Continuous Integration / Continuous Delivery pipeline in place for your applications and/or infrastructure. It’s much broader and does not only focus on the technical aspects. Organizations adopting DevOps typically struggle with topics like these:
- How to automate the right things to remove toil and manual process steps
- How to properly perform release management
- Get teams and managers to adopt a product-centered mindset
- Hoe to create multi-disciplinary teams that take responsibility for their product
- How to establish and improve the collaboration between teams
- How to bring Continuous integration / Continuous delivery into reality
The DevOps Maturity Model acts as a “mental guide” to determine the level of these topics and it helps you lay out a path to advance from one level to the next one. There are various DevOps consultancy firms to guide you in your journey towards DevOps.
In the next section, I will highlight the most common topics which a lot of Maturity Models have in common.
The four main areas
Almost every DevOps Maturity Model is based on specific areas of interest. These areas reflect the various aspects of DevOps in an organization.
- Technology: perhaps the most common area but a challenging one. Think of the following topics in this area: the provisioning of environments, the way data(bases) changes progress from one stage the other, the implementation of centralized monitoring and logging, etc.
- Process: think of the following in this area: the consistency, or the lack of, delivery processes. Or Change management: who can decide what, how many people involved in making decisions or how long they take. The way you are continuous testing and the way you write and keep documentation up-to-date. And the most important aspect: how all of the processes are organized within the context of all of the developer teams.
- People: this area all has to do with the human factor. Nothing is more dynamic and diverse than this. It’s about how teams are organized (and positioned), how teams learn (new things) and how competencies are acquired. And what about the levels of self-organization?
- Culture: culture is all about team communication including feedback within teams or coming from the applications being delivered. It’s also about collaboration across departments with various stakeholders. But also about the way teams handle outages (blameless retros or not).
All of these areas have more topics than just listed here. It’s a high-level overview to emphasize that there are so many aspects, not only the technical ones. The technical ones are less than 50% of the total amount. Let’s now move on to see the different levels at which organizations can be in their journey.
Maturity levels
Most DevOps Maturity Models define five levels of maturity. These levels are as follows.
Initial level
On the initial level, the organization might not be aware of what DevOps is or they do not see the potential benefits. At this level, the organization has to start from the very beginning. Organizations on this level typically follow a waterfall project management approach for their IT projects, have long approval and change processes, and have teams structured around a skill, not product. They plan and design everything up-front before the development teams start coding and, when all is done, separate teams deliver the application to production. Tests start very late in the process. It is very likely they do not practice the concepts of shift-left security.
Operations is a separate team that waits for developers to hand over their applications with (in the best-case scenario) a thick manual of instructions on how to deploy it. More often than not, the handover of the new version and associated information about deployment is characterized by missing information, miscommunication and finger-pointing when things inevitably go wrong.
A lot, if not all, steps to deploy an application are manual tasks with the help of various scripts and procedures. Those scripts are difficult to manage since they differ for every application or even version. Applications have a lot of technical debt and don’t share the same architecture principles which make it hard to automate common CI/CD processes. All-in-all, every application is a snowstorm, consisting of many individual snowflakes.
For organizations like these, the DevOps Maturity Model can be overwhelming. But they can also benefit the most. It helps if someone steps up and takes a leadership role to take the first steps. Often, the first steps taken are grass-roots, bottom-up activities by engineers.
The repeatable level
Organizations at this level know the core principles of DevOps and apply them as good as they can to their daily jobs. Environments and their configurations are versioned and can be set up consistently. They are on the right way to facilitate the collaboration between development and operations. Changes do not come as a surprise but are well communicated. Organizations operating at this level are not just “reactive” to all that comes across their path. They are pro-active and work their way towards repeatable processes for the areas they understand well.
However, teams tend to ship rather big features that are difficult to manage and test. Breaking monoliths into smaller microservices remains a challenge. Project managers still think in large projects sometimes managed from start to end. Operations teams need to manually intervene when things in production go wrong. Firefighting is very common. Compliance is a topic requiring constant attention.
Defined level
A key characteristic of this level is consistency across areas and topics. Processes are repeatable but also standardized. Think of the following: database changes are performed automatically with every release, non-production deployments are rolled out automatically and monitoring is integrated with every application. Integration tests are executed automatically and act as quality gates for any later stage in the delivery pipeline.
Teams are organized around projects or products and not around skill-sets. Development teams work towards the execution of clear requirements that deliver clear business value. User stories are written consistently and the team uses Definition of Ready and Definition of Done properly. All of this follows the overall vision of the company which is communicated clearly to all people involved. Furthermore, documentation and release notes are created automatically and are regularly validated.
Managed level
At the managed level all of the environments are managed effectively. Database changes and rollbacks are tested with every iteration of the product itself. The delivery process is predictable and runs frequently. Therefore, stakeholders know what and when to expect. Applications are actively monitored in production and (the right) metrics are gathered. Teams know how to incorporate feedback for their next iteration.
The organization uses a knowledge management tool to capture existing knowledge and use this to bring more knowledge to the teams. Mentors coach the teams to push them forward.
Culture is not a bottleneck to changes but is welcomed to achieve organizational goals. Individual development teams know how to utilize the cultural aspects to push their products forward.
Optimized level
Big applause for teams at the optimized level. Toil is fully automated and testing is done in production. They know how to deal with problems like overloaded systems: do nothing. The system itself will scale or adjust to this peak. It also adjusts to potential problems like network interruptions or other infrastructure failures.
Two other examples: chaos monkey tests are performed randomly, environments and applications are resilient and don’t break. Upgrades and patches are performed within the internal SLO. No change windows need to be communicated to end-users. The user experience is optimized and teams think and act in a customer-centric way.
The continuous delivery process is a reality as well as continuous testing and performance management. Real-time feedback on quality assurance and compliance issues flow back to the team. Tickets are created automatically with the right priority. This brings up new organizational requirements that are implemented using a fully integrated set of processes across all departments.
Assessment & where to start
Even if you know what DevOps is and how to put it in practice, it’s good to do a proper assessment. The number of topics is too big to guess where you are and where to advance. To complicate things, teams can be at different levels for different topics in the same area. It’s about finding the biggest bottlenecks and set the right priorities.
For example team A is at the “repeated level” on test automation but at the same time at the initial level of continuous deployments. Perhaps they have a bunch of very good testers in their team. Now there is a need to boost the deployment process to advance to the next level. And this is just a single topic in the technology area.
Do it yourself…or?
One of the hardest questions to answer is: how to do the assessment and who should do it? Should the team do it themselves or should it be done by an external expert? A team might not have reliable information about how well they are doing. An external expert sees the team from a different perspective. It’s difficult for a team to observe themselves while they are executing their day to day tasks.
It’s best to have an external expert help and guide the team to assess the levels of the different topics. Self-assessment can be a good start, but having an external expert helps to get a more objective view. A coach that helped other teams before can also compare the “score” of the team which is being coached at the moment. A coach brings tips from other situations and/or scenarios of similar organizations. All of these benefits pay off in the future.
Practical links
Whatever your choice to start is (do it yourself or hire an expert), it’s always good to go a (quick) self assessment. For example the website DevOpsMaturity offers a wizard of questions you need to answer. The outcome shows you in which areas you score “good” and which areas require attention. You can the outcome to pinpoint the attention when hiring an external expert or to make a plan with the DevOps team(s) themselves first.
Be sure to check out the following links to existing DevOps Maturity Models and other valuable sources:
- Do you really do DevOps? Important questions to get you on the right track. Source: website of DevOpsGroup.
- Consult the most recent report of the DevOps Research and Assessment group.
- Atlassian, the founder of the popular ticketing tool “Jira” also has a DevOps Maturity model.
- Last but not least: the DevOps Institute which has valuable information and practical guidelines.
Conclusion
To put DevOps in practice across the entire organization, a DevOps Maturity Model can help to determine the maturity level of a lot of key DevOps topics in various areas. It is hard to get a reliable overview without this model since there are so many aspects involved. Furthermore, in an ever-changing world, these aspects influence or even conflict with each other at the same time. Technology advances so fast and it’s already hard for teams to keep up with this.
Therefore I hope this article gave you useful tips and best practices to evaluate the current state of your DevOps organization. Hopefully, you will benefit from it in your existing journey.
