DevOps maturity model - Part 2

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. 

This is Part 2 of the DevOps maturity model post that provides 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.

DevOps maturity model is described in  Part 1 of the post.

 

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.

 

Part2_managed.png

                       

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.

Part2_defined.png 

 

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.

Part2_measured.png

 

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.

Part2_opsdev.png

 

Summary

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 blog 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.

 

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

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.