All About the Apps
Showing results for 
Search instead for 
Do you mean 

DevOps and OpsDev: How Maturity Model Works

BTopham ‎04-26-2013 08:16 AM - edited ‎06-09-2015 03:05 PM

Our DevOps maturity model describes five levels of maturity. For each level we examine three dimensions:

  1. Process maturity
  2. Automation maturity
  3. Collaboration maturity

Each maturity level is described as the combination of these three dimensions. In order to progress from one level to another it is essential to improve in all three dimensions.


As an application or a service transforms throughout its lifecycle from business need, to software requirements and implementation, to quality assurance, and eventually to deployment and operations, many processes are implemented along the way. These are broken into numerous activities and performed by different people, possibly owned by different parts of the organization or even outsourced. In this paper we provide some examples of how DevOps maturity of entire processes or individual activities can be measured. It is possible that different activities in the organization are at different levels of maturity: gradual progress can be planned starting with the activities that are most critical to your organization, or where it “hurts” the most (time, cost, people, etc.).


Most of the existing DevOps maturity models focus on the build-test-deploy-release Continuous Delivery pipeline, driven by the software development teams. Our maturity model is designed to cover the entire lifecycle of an application or a service for large enterprises, regardless of whether the change is driven by the software development teams looking to adopt Agile practices, or central IT teams shifting to Lean IT and mass production approaches.


Our maturity levels and process maturity definitions are aligned with the CMMI maturity model.


As you review this paper, note that DevOps practices do not suit all applications or services in the portfolio. For some applications or services frequent delivery does not justify the cost, and more traditional waterfall approaches may be more appropriate.


The Five Levels of Maturity Model


Level 1 – Initial

  • Process maturity:  At Maturity Level 1, processes are usually ad hoc and chaotic. The outcomes of the processes are unpredictable, often exceeding allocated budget and timelines. There is a tendency to abandon processes at times of crisis, and it is impossible to repeat successes.


  • Automation maturity:  There is no automation of processes or even activities, resulting in processes being unrepeatable, poorly controlled and slow.


  • Collaboration maturity:  This level is characterized by poor, ad-hoc communication and coordination between the teams. The roles and responsibilities of teams are not well-defined. The teams provide information through formal communication channels. Decisions are made independently by the stakeholders responsible for the processes’ activities and then communicated to other teams.

Level 2 – Managed

  • Process maturity:  At Maturity Level 2, the processes are managed but not standardized across projects or even across different lifecycle stages of the same project. The standards, process descriptions and procedures can vary considerably in each specific instance of the process (i.e. in the different work groups).


  • Automation maturity:  A process is documented and partially automated. There is siloed (tasks vs. process) automation with no central infrastructure.


  • Collaboration maturity:  Managed communication and coordination: regular sync meetings are held; the release is communicated and coordinated between development and operations. The teams share information and – in some cases – even resources; the roles of the stakeholders are well defined. There is frequent communication between the teams. There is some shared decision making, but most of the decisions are still taken separately, and coordinated or communicated afterwards with other teams.

Level 3 – Defined

  • Process maturity:  Processes are well characterized and standardized across projects. These standard processes are used to establish consistency throughout the organization. Projects establish their specialized processes by modifying the standard processes to fit their needs and requirements, while still keeping to the standard frameworks defined by the organization.


  • Automation maturity:  There is central automated infrastructure that supports overarching enterprise processes built for the overall organization, instead of silo automations tailored for specific application or services, environments, or even tasks.


  • Collaboration maturity:  Collaboration is established between the teams. It becomes an essential part of the established processes and tool chains enabling idea sharing, better visibility and faster feedback.  All team members belong to a single system with shared accountability, frequent communication and mutual trust.

Level 4 – Measured

  • Process maturity:  Process quality and performance are measured to achieve visibility and predictability.The performance of processes is controlled using statistical and other quantitative techniques, and predictions are based, in part, on a statistical analysis of fine-grained process data.


  • Automation maturity:  Automated end-to-end processes are measured and controlled, providing visibility and insights into each activity (status, cost, time to complete, stakeholders), as well as cross-activity insights. The metrics of the automated processes are measured against the business goals.


  • Collaboration maturity:  Collaboration-based processes are measured to identify inefficiencies and bottlenecks by collecting information about people involved in activities, their level of expertise and contribution, relevance of the information or efficiency of the performed steps.

Level 5 – Optimized

  • Process maturity:  There is continuous assessment of the overall process (as opposed to optimization of separate activities) aimed at achieving the business objectives with minimal risk and cost.


  • Automation maturity:  There is continuous improvement of automated process using metric analytics, self-learning and self-remediation. Self-service automation is provided to different stakeholders in the organization.


  • Collaboration maturity:  Collaboration is optimized for effective and continuous knowledge sharing and individual empowerment.


This section provides several practical examples on how the model is used to estimate the maturity level of different activities, and what is required to move to the next level.


Level 2 – Managed

In the following example we have an organization that has established a release process that matches Maturity Level 2. The process is managed but not standardized across the organization: development teams are managing their own release processes, and IT release teams have their own procedures. The teams communicate frequently and coordinate activities, such as the hand-off of release binaries from development teams to operations, or feedback about the release status and performance measured by the IT operation teams. There is no end-to-end automation of the entire process, but separate activities are managed and automated.

Since there is no collaboration or shared accountability between the teams, we can see duplications of functions: for example, two release teams (one for applications and another for operations), or separate automation infrastructure for application release vs. IT release as defined by ITIL practices.



Level 3 – Defined

In order to move from Maturity Level 2 to Maturity Level 3, the organization from the previous example needs to be able to establish end-to-end release processes eliminating the silos, and avoiding the duplication of functions. All stakeholders involved in the process should have shared accountability, and visibility into the process and outcomes of each activity.


Level 4 – Measured

Measured state is driven by analytics providing insights into established end-to-end processes. The goals that can be achieved at this stage by the organization are predictability and better risk assessment. This level is a pre-requisite to Maturity Level 5, since only after the activities are measured (for time, cost and business value), can they be optimized or provided as a self-service.


DevOps and OpsDev

Initially coined by Patrick Debois in 2009, DevOps is a culture and methodology that stresses collaboration and shared accountability between software developers and IT operations professionals, enabling faster and high-bandwidth feedback loops across the departments.


After engaging with many enterprises, we learned that the adoption of DevOps practices and methodologies in large enterprises is often driven by IT operations, and not necessarily by the developers of the Line of Businesses. We call this OpsDev.


While DevOps in many cases is driven by Agile delivery teams, targeting increased velocity and business agility, through our many interactions with enterprises we learned that IT operations have their own drivers:


  1. Industrialization of service delivery models:  An existing challenge for IT operations is IT industrialization, and applying manufacturing best practices to IT processes, aimed at optimizing the cost and speed of the services’ delivery. One of the main principles of the lean manufacturing practices is standardization and automation of the service delivery processes related to all stages of the lifecycle – from demand to fulfillment. This direction is aligned with the process maturity model.
  2. Automation of processes:  In order to achieve mass production, IT Operations needs to automate its processes, such as release of changes, environment provisioning, monitoring, remediation of problems, etc. Automation of these processes should be done for the overall organization, not for a specific service, environment or task.
  3. Collaboration with stakeholders:  Increasing business agility requires different levels of collaboration between IT Operations, and business and development teams, in order to optimize the balance between speed and risk. IT operations’ role is transformed into a facilitator and “enabler”, providing guidance and policies, frameworks that can be used by IT consumers, self-service standard offerings or service brokerage of external service providers. This shift requires a different level of collaboration with IT consumers, such as Lines of Business or external service providers and outsourcers. In the case of outsourced services, the visibility of the processes, shared frameworks and traceability become even more important, and shared accountability is governed by the contracts.


So while DevOps and OpsDev have a shared goal of maximizing the business outcomes, the drivers can be different. Nevertheless, they go through similar transformations of the three dimensions mentioned above – process standardization, automation of processes, and collaboration with the stakeholders.



DevOps holds various interpretations and approaches, often borrowing and assimilating conventions from different areas ranging from scrum, Agile, Kanban, Lean IT or ITIL. All these have a shared goal of maximizing business outcomes and helping enterprises keep up with the new business pace.


This article proposes a simple model that can help enterprises in their DevOps journey. It provides them with a means to measure the progress of the DevOps adoption, regardless of whether the change is driven by the software development teams looking to adopt Agile practices, or central IT teams shifting to Lean IT and mass production approaches.


Article contributors: Shani Inbar, Sayers Yaniv, Pearl Gil, Schitzer Eran, Shufer Ilan, Kogan Olga, Srinivasan Ravi





About the Author


27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all