Simplified DevOps Maturity Model
As organizations embark on adopting DevOps practices, they typically adopt a series of DevOps practices and improve along a maturity curve, where specific practices and processes are improved first, followed by others.
Typically maturity models can be complex, multidimensional constructs which are used to measure maturity, plan improvements and in some cases document the organization's effectiveness. The traditional 5 level model (Initial, Managed, Defined, Quantitatively Managed, Optimizing) is perhaps overly complex for describing the maturity of an organization on their DevOps Adoption.
We can define a simpler model, something similar to this three-level model for Continuous Delivery Maturity: http://bekkopen.github.io/maturity-model/
If we created a model that described a typical sequence of evolving DevOps maturity where the focus started with improving development practices, then focused on deploying and releasing consistently, finally focusing on how the organization optimizes the end-to-end lifecycle, we could use the model as a reference for where customers are on their own DevOps adoption.
A simplified model could adopt the following definitions of each of the three 'levels'
Adopting | Scaling | Optimizing |
---|---|---|
Starting to adopt DevOps, development teams focus on their core software development practices to streamline and accelerate their ability to organize and create software. Specifically they focus on adopting modern development practices, source code management, automating build and testing to make their work more consistent and responsive to change. | Building on stable, iterative, and repeatable development practices, teams scale and extend these practices to address the challenges of delivering code to production, bridging the gap with automated configuration, deployment, and release of applications to end users. | With a maturing DevOps lifecycle, teams focus on optimizing their business value, leveraging end-to-end feedback, monitoring, and insight to streamline and improve DevOps practices. They identify and address constraints, such as security testing, where they tune and improve their processes increasing velocity, quality, and security. |
Primary Emphasis for teams just adopting DevOps | Primary Emphasis for teams scaling their DevOps transformation. | Primary emphasis as organizations maximize the value of their DevOps lifecycle. |
Consistent modern development (typically agile) processes and collaboration to keep the team in synch with the project goals and changing business priorities. | Consistently packaging and managing their binary assets makes it easy to deploy the right version to the right environment. | Understanding cross team and cross organizational issues to optimize and manage their portfolio of projects |
Sharing common code repository for distributed version control and branches so that team members have access to the most recent version of their code. | Automating the deployment and configuration of the application to ensure consistent, repeatable and fast deploys. | Organizations develop and deploy dashboards to monitor and track key business metrics and KPIs so they can remove constraints that slow down value delivery. |
Automating build and testing as much as possible to ensure their code is consistently built and tested | Extend automated testing as they mature to incorporate extensive functional, performance and acceptance testing. | As organizations mature, they realize that a common constraint is Security Testing, which is often referred to late phases in the development project. This often results in re-work and delays. A strategy to address the constraint is to shift security testing left and make it part of every build. |
Adopting continuous integration to ensure each commit is built, tested and validated. | ||
Collecting data and insight about the effectiveness of their development processes. | Gathering data and insight about the effectiveness of the delivery processes | Continuous improvement practices to analyze the value stream and identify opportunities to improve and optimize the flow from Idea to Production. |
This maturity model CLOSELY aligns to our current features:
Starter = Adopting | Premium = Scaling | Ultimate = Optimizing |
---|---|---|
Build / Test | Scaling | Security |
Code quality | Disaster recovery | SAST |
CI Statistics & Graphs | Live upgrade assistance | DAST |
Include centralized CI definitions in projects | DB load balancing | RASP |
Service desk | IAST | |
Governance | Coming: Git fusion | Software composition analysis / license management |
Multiple assignees | Coming: flaky tests | License Management |
Issue weights | PostgreSQL HA | |
Burndown charts | GitLab Geo for distributed cloning | Optimize Velocity |
Approval flows (Merge requests approvals, multiple approvals) | High Availability support | Ops dashboard |
Restrict push and merge, push rules, block secret push | Group issue boards | Security dashboard |
Group webhooks | (project manager dashboard?) | |
Admin control, Audit log | Deployment | (executive dashboard?) |
Remote repository mirroring | Multi project pipeline graphs | Cluster monitoring |
Contribution analytics | Multiple Kubernetes clusters | Coming: Cloud Development |
Authentication (Kerberos, Multiple LDAP/AD server, Create and remove admins based on LDAP groups, LDAP group sync) | Deploy boards | Epics |
Canary deployments | Roadmap | |
Browser performance testing | Coming: Value Stream Analysis | |
Coming: Load/performance tests | Coming: Monitoring Alerts | |
Binary repository | Coming: Tracing | |
Automatic reverts | Coming: Feature flags | |
Release trains | Coming: Production monitoring | |
Metrics | Coming: Error Tracking | |
Coming: Logging |
If we were to embrace a simplified maturity model as described here, it could help define our paid plans and provide guidance as to how to align future features.