DevOps maturity model - Part 1

As DevOps gains momentum in the industry, it is taking on various interpretations and approaches. This article is based on HP’s research and industry experience. It will propose a maturity model for DevOps, evaluate the key success factors and their evolution. Application owners, development teams and IT operations personnel who are looking to adopt DevOps or mature their DevOps practices, will be able to learn the DevOps landscape, assess their current position and work out their evolution path.

Part 1 describes the proposed DevOps maturity model. Part 2 contains several practical examples on how the model is used to estimate the maturity level of different activities, and what is required to move from one level to the next.

 

How Maturity Model Works

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 article 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 read this article, 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

 

  Part1_maturity_model.png                     

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.

Part 2 of this article will provide 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.

 

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

 

Tags: Olga Kogan
Labels: DevOps
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Seasoned architect with over 12 years of experience in the enterprise software business, contributing to setting the roadmap / vision, high ...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.