What Is the Cloud Native Maturity Model? Definition and Assessment Criteria

Cloud-Native Maturity Model Overview 

Cloud computing has existed since the early 2000s, with Amazon launching AWS in 2002 and Microsoft introducing Microsoft Azure in 2009. Dozens of other cloud service providers (CSPs) have emerged since then, offering businesses on-demand access to extra computing capacities and storage resources.  

Virtually limitless scalability, optimized total ownership cost (TCO), and greater flexibility in application deployment and distribution rapidly “sold” the advantages of cloud computing to business leaders. With that, the first cloud-native operating models emerged.  

Instead of building and hosting applications in local data centers, software engineers switched to using the cloud as the “launchpad” for new offerings. New software architecture patterns emerged, like microservices and containerization, allowing software to be reliably deployed across a distributed environment. 

Amazon, Netflix, and Spotify used a cloud-native approach to software engineering to dramatically increase the scale, stability, and distribution capability of their products, with traditional businesses soon following suit. Coca-Cola migrated applications from a single data center to the cloud to eliminate single-point-of-failure risks and increase software engineering efficiencies. Walgreens opted for microservices architecture to create a better digital commerce experience. Three-quarters of large enterprises now use microservices, but does it make all of them cloud-native? 

Yes, but only to an extent. Because cloud-native business models are not just new software architecture patterns or greater usage of cloud technologies. It is also a fundamental shift in operational processes and cultural practices.  

To gain the most value from the cloud, leaders also need to optimize the software development life cycle (SDLC). Cloud-native practices like DevOps (and later DevSecOps and MLOps) have emerged to improve the collaboration between different engineering teams and maximize all the new capabilities cloud technologies provide.  

With so many changes to the standard processes, it’s hard to understand where you stack in terms of adoption and how you compare to industry leaders. For this reason, the Cartografos Working Group has developed a Cloud Native Maturity Model — a list of guidelines and practices to help adopters better navigate the cloud ecosystem.

Cloud-Native Maturity Model 3.0  

Originally proposed in 2021, the cloud-native maturity model has undergone several interactions, which are backed by the evolution of CSP offerings.  

The model has five components:

• Business outcomes: What value do you expect to achieve from the cloud-native?
• People: What skills, processes, and cultural practices are required to support the new way of working?
• Process: How do you design modern software engineering workflows and adopt practices like CI/CD, IaC, continuous testing, and embedded security?
• Policy: Which policies do you need to ensure security and compliance?
• Technology: What extra technology is required to support cloud-native application development, optimize infrastructure management, and enhance security?

The current 3.0 edition places business outcomes at the top of the model, with People, Process, Policy, and Technology as supporting pillars. Business goals must inform the decision to go cloud-native. The model also emphasizes the shift left of business strategy and the need to view costs differently, especially in terms of CAPEX vs. OPEX, and the adoption of FinOps for enterprise organizations to optimize cloud costs.  

Levels of Cloud-Native Maturity  

Every organization’s journey to the cloud is unique. Some choose to go cloud-native for newer applications. Others progressively modernize existing IT estates and adopt better operating practices like containerization, DevSecOps, zero-trust architectures, and more innovative technologies.  

Source

Fundamentally, the cloud-native maturity model has five stages. Different teams and products within your organization can be at different stages of maturity.    

At Level 1, organizations have ad hoc processes for many engineering tasks. Some Git workflows are repeatable — while others are not. CI/CD practices aren’t optimized, with many tests and reviews done manually. Security updates, as well as app deployments, are also done by hand. There’s no change control process in place, and there’s no central logging point for security information and event management (SIEM).  

At this stage, organizations need to build a solid foundation for cloud-native application development. They should switch from periodic releases to continuous integration, adopt better infrastructure monitoring practices, and automate infrastructure configuration and provisioning.  

At Level 2, organizations decide to move more applications to the cloud. The first successfully migrated application will help establish the new processes, policies, and benchmarks for engineering teams. To support new cloud-native development processes, you’ll need to establish cross-functional teams and adopt Agile project management practices for a faster feedback loop.  

Progressively, you’re developing replicable workflows covering source control management with the ability to view, merge, tag, and approve new commits to trigger deployment. Software development teams transition to using containers and container orchestration platforms to automate infrastructure management. Security requirements are formalized for new features, and the continuous integration pipeline includes unit testing against these requirements.  

At Level 3, a good fraction of the organization’s portfolio is already cloud-native, yet processes are still far from being efficient. Given the early wins, you have a buy-in to scale the processes. However, this raises new challenges related to security, compliance, and infrastructure availability.  

More cloud-native tools are being introduced, resulting in a growing sprawl and lack of standardization between teams. Infrastructure as a Code (IaaS) practices are in place, but inefficiencies still exist in the deployment, driving up cloud computing costs.  

At this stage, leaders are focused on workflow optimization. The main aim: pre-furnish integrated developer environments with standardized tools, improve collaboration between teams, and optimize resources. A greater degree of software release processes gets automated, along with lifecycle operations like upgrades and patching.  

At Level 4, security, policy, and cloud governance improvements are the key objectives. The software engineering processes are already cloud-native, backed by DevOps best practices. Teams can focus more on strategic initiatives like new customer-facing feature development rather than new infrastructure setup and management.  

You are consolidating the number of tools used by the team to optimize costs. The adoption of platform engineering functions may be discussed at this stage to ensure even higher developer productivity. At the highest level, you are working on implementing a better cloud governance model designed to standardize container auto-scaling policies, security configurations, and other necessary controls to ensure lean operations.  

At Level 5, you have a strong cloud function, operating at its peak most of the time. Thanks to earlier investments, you are not experiencing unpleasant surprises like sudden data loss, auditory fines, or massive application performance dips.  

IT spending has become more predictable with the adoption of FinOps practices. DevSecOps governs software engineering workflows. Developers have self-service access to the tools and infrastructure they need. There are occasional hiccups along the way, surely, but these have minor impacts.  

How to Assess Your Cloud-Native Maturity Levels  

The cloud maturity model provides a framework for moving from the current setup to the desired future state. It is not a hardline manual but rather a set of milestones leaders should aim for to improve their operations. 

To evaluate the organization’s current maturity levels, Infopulse cloud consulting team applies the following approach.  

Measure the Current Baseline  

Performing a simple “lift and shift” migration of several applications to cloud infrastructure does not automatically qualify an organization as cloud-native. Cloud adoption is a continuous journey, assuming a fundamental shift in application design and deployment, infrastructure provisioning, management, and monitoring, as well as ancillary practices like security and governance.  

Most companies already have a sizable application, platform, and infrastructure estate, as well as established software engineering practices.  

Hence, the first step is to understand which facets are already in place and which ones are missing. A good baseline for cloud-native journey typically includes the following elements:  

Set Cloud Adoption Objectives 

The core motivations for cloud adoption can range from improving the total cost of ownership (TCO) for infrastructure to faster application release cycles or easier product distribution. These drivers must be properly formalized both in terms of business and technical requirements.  

For example, if your target business outcome is to deliver an exceptional customer experience, the technical requirements are: 

• “Migrate customer app A to the cloud and implement the auto-scaling of cloud instances and traffic load balancing”
• “Deploy apps across multiple availability zones with the CSP to reduce latency and reduce risks of localized failures.”

For every objective, you also need to provide a clear-cut justification of why certain cloud capabilities are the best option. For example, when developing a new business continuity plan (BCP) plan for our company, we decided to back up over 46 different production systems to a secondary European data center to reduce the odds of any data loss or operational disruptions and enable more distributed work.

By moving the company’s RMS (Rights Management Center) to Azure Information Protection, the global Infopulse team can now easily access all corporate documents from any location. Similarly, the adoption of Azure DevOps service allows us to securely store code versioning in the cloud and on-premises, guaranteeing both high accessibility and redundancy.  

Case Study

Learn more

Azure DevOps Adoption for Secure Code Versioning

Benchmark Your Current Operations Against the Target Objectives  

The goal of a cloud-native maturity model is to help you understand how different operational elements contribute to your target outcomes. In this regard, you need to assess:

• Cultural practices: Do you have established feedback loops for exchanging ideas? How are requirements collected and transformed into project plans?
• Product/Service Design: What’s your current approach to ideation? How do you determine what new features must be created or what product improvements are due?
• Processes: What methodology do you follow — Agile or Waterfall? Are these processes well-defined, repeatable, and yield predictable outcomes?
• Delivery: How does your organization build and deploy new software to production?
• Architecture: What patterns do you follow, and how do these aid or hinder your goals?
• Infrastructure: What types of assets do you have? How do you handle provisioning?
• Maintenance: How do you ensure the availability, security, and reliability of your technology estate?

Based on these parameters, you can measure your current cloud maturity levels and prioritize specific areas for improvement.  

Sample Cloud-Native Maturity Assessment Matrix  

Source

The Next Steps: Advancing Your Maturity Adoption  

Cloud-native operations isn’t a sprint of adopting several cloud services but a marathon requiring ongoing research, evaluation, and measurement of your progress. Break down your business objectives into specific actions you need to complete across the people, processes, technology, and policies axes. Establish milestones and adopt metrics that will help you quantify the progress (when possible). Focus on the areas where you can get quick wins to ensure greater stakeholder support and team buy-in. If you need help with turning these steps into action, reach out to the Infopulse cloud consulting team.