Enhancing Your Cloud Strategy with a Cloud Maturity Model

A cloud maturity model (CMM) is a framework for assessing your organization’s cloud readiness. Regardless of size or cloud experience level, any organization can use a CMM. For an organization that is entirely new to the cloud, a CMM helps develop a cloud adoption strategy. An organization with existing cloud infrastructure can use a CMM to evaluate operational or security weaknesses and develop a plan to optimize them.

The reason CMMs are important is simple. Cloud adoption can and does go wrong. A recent survey found that 43% of organizations experienced a delay to their scheduled AWS go-live date. A CMM guides organizations through the cloud adoption journey to improve the probability of success.

This article will explore cloud maturity modeling, different CMM models, and five best practices to enable you to take what is most relevant and apply it to your organization. 

Summary of key cloud maturity model best practices

The table below summarizes the key cloud maturity model best practices covered in this article.

Best practice	Description
Set cloud adoption objectives	To benefit from a cloud maturity model, you must clearly understand the business outcomes that cloud adoption will achieve.
Identify your cloud maturity level	You must understand your cloud maturity level to benefit from using the cloud maturity model. You then set objectives and develop a roadmap to increase your cloud maturity level.
Pick a cloud maturity model	Choose a cloud maturity model to serve as your roadmap for evaluating and optimizing your cloud capabilities.
Follow a cloud maturity model	Developing your cloud maturity will typically involve three significant areas: People Process Technology
Avoid cloud adoption pitfalls	Understand where other organizations went wrong to avoid repeating the same mistakes.

 

Cloud maturity model best practice #1: Set cloud adoption objectives

If you’re reading this article, your overall goal is likely cloud adoption. Beyond this goal, you must have set business objectives for cloud services. A CMM can help achieve your objectives, not define them for you.

Cloud providers have developed excellent resources for cloud adoption based on the successes and failures of their customers. For example, the Microsoft Azure cloud adoption journey has seven stages.

The image shows the seven stages of the Microsoft Azure cloud adoption journey (Source)

The Define Strategy stage includes three recommendations that will help you set cloud adoption objectives:

1. Understanding motivations – Focus on understanding cloud economics or Total Cost of Ownership, because cost savings are a common motivation for cloud adoption.
2. Identify desired business outcomes – They provide an example template to bridge the gap between business and technical conversations.
3. Define your business justification – Creating a business case for cloud adoption can help garner internal support from your internal teams, e.g., finance. 

Cloud maturity model best practice #2: Identify your cloud maturity level

Typically, an organization progresses through six maturity levels during its cloud adoption process. The table below includes a description of each level, from 0 to 5. 

Maturity level	Description
Level 0	The organization needs to prepare for the cloud. It is currently reliant on on-premise infrastructure or has no legacy infrastructure.
Level 1	The organization has explored using the cloud and considered what they would migrate.
Level 2	The organization has a process for moving applications to the cloud. Specific business units may be using the cloud, but the wider organization is unaware.
Level 3	Cloud adoption follows documented processes throughout the organization. Cloud-based systems are monitored and optimized.
Level 4	Using cloud services is the default, and different cloud providers are leveraged depending on the use case. Operations teams are using continuous monitoring to increase the efficiency of cloud services.
Level 5	Cloud-native services are the default deployment model. Cloud service monitoring and analysis show that operations are optimized.

Which level applies to your organization? Understanding your current maturity level will help you define your objectives and identify the gaps you need to fill. For example, suitable objectives at level 0 include:

Business objective	Better understand the Total Cost of Ownership and determine a cloud budget.
Technology objective	Deploy a development environment to Amazon Web Services.

 

An organization at a higher maturity level may be looking to optimize its cloud environment by setting the following objectives:

Business objective	Reduce cloud costs by 10%.
Technology objective	Improve security incident response time by 25% by integrating with a third-party cloud management platform, like CoreStack.

A cloud maturity model is not about being 100% in the cloud. Your organization's culture, expertise, or business requirements may mean a hybrid architecture is the right solution. Your organization could be striving for completely cloud-native services or migrating and optimizing a minor part of your IT architecture to the cloud to provide burst capacity in the cloud.

Cloud maturity model best practice #3: Pick a cloud maturity model

A cloud maturity model will help guide you from inception to adoption of cloud technologies. Examples of common CMMs are provided in the table below. 

Model Name	Description	Published by
Cloud Maturity Model	CMM 4.8 addresses the maturity of an IT organization's business and technology capabilities in specific domains and across cloud service models.	Open Alliance for Cloud Adoption
Cloud Native Maturity Model	This model intends to help you move from inception to full adoption of cloud-native technologies using the CNCF landscape to achieve the full benefits of running scalable applications in modern, dynamic environments in public and hybrid clouds.	Cartografos working group
Cloud Security Maturity Model (CSMM)	A CMM for cloud security readiness is called a cloud security maturity model. The CSMM diagnostic assesses the state of your cloud security program against 12 categories over three domains of the CSMM.	IANS and Securosis
Software Assurance Maturity Model (SAMM)	SAMM supports the complete software lifecycle, including development and acquisition, and is technology and process-agnostic.	OWASP
AWS Cloud Adoption Framework	The AWS CAF helps to identify and prioritize transformation opportunities, evaluate and improve your cloud readiness, and iteratively evolve your transformation roadmap.	AWS
Microsoft Azure Cloud Adoption Framework	The Azure CAF provides guidance and best practices for adopting Microsoft Azure. It is designed to help you confidently adopt the cloud and achieve business objectives.	Microsoft Azure
Google Cloud Adoption Framework	The Google Cloud Adoption Framework helps you identify key activities and objectives that will reliably accelerate your cloud journey.	GCP

Cloud maturity modeling can be applied to your cloud adoption or specific aspects of your cloud environment. You could use the framework for cloud governance, compliance, security, or adopting new technologies.

Suppose your organization is entirely new to the cloud. In that case, starting with a cloud-agnostic CMM like the Open Alliance for Cloud Adoption cloud maturity model is an excellent place to start. 

A cloud provider-specific CMM can be used alongside a cloud-agnostic CMM. While the AWS Cloud Adoption Framework contains many cloud-agnostic best practices, it uses AWS terminology that can be confusing in non-AWS environments. Use one of the cloud provider CMMs when you are confident about which cloud provider(s) you will use. 

If you want to optimize the security aspects of an existing cloud environment, then a cloud security maturity model (CSMM) will be more appropriate. The IANS and Securosis CSMM assesses the state of your cloud security against 12 categories over three domains, and there is an online diagnostic tool.

Cloud maturity model best practice #4: Follow the cloud maturity model

Let’s look at the Open Alliance for Cloud Adoption (OACA) Cloud Maturity Model Rev. 4.8 in more detail to understand what using a cloud maturity model looks like. The OACA CMM addresses both non-technical and technical capabilities and will help you answer the question, “What should our journey to cloud and hybrid IT look like?”

The OACA CMM covers the progression of cloud adoption from a baseline of no cloud services through five progressive levels of maturity.

Five progressive levels of maturity of the OACA Cloud Maturity Model. (Source)

The following image provides a more detailed description of each CMM level. The descriptions from the OACA CMM are closely aligned with the more general descriptions in the Identify your cloud maturity level section.

Summarized description of each OACA Cloud Maturity Model maturity level. (Source)

At each level, the CMM distinguishes between non-technical and technical capabilities. A capability is further subdivided into many domains covering people, process, and technology. Examples of non-technical domains are finance, skills, and governance. Examples of technical domains are IT architecture, data, and management tools. Refer to the Open Alliance For Cloud Adoptions Usage Manual for a complete list of the domains. Organizations can select a subset of domains based on their use case. 

Let’s review an example of this for three different use cases.

Step 1 – Identify business goals

The first step is to understand the goals that the organization must achieve through cloud adoption. An example of a business goal is:

Business goal	Description
Preparing new products to innovate past the competition	Create flexible capacity for new business and products by using cloud services.

 

Step 2 – Define use cases for CMM

This assessment is completed based on the organization's objectives. The OACA recommends documenting objectives as use cases required to achieve the business goals. 

The table below shows three use cases from the Open Alliance For Cloud Adoptions Usage Manual and uses the numbering from the manual. These use cases cover a spread of CMM maturity levels and highlight the stakeholders involved in a CMM assessment. In the following Step 3 – Conduct CMM assessment section, the use cases are repeated to provide examples of the non-technical and technical domains that these use cases cover.

Use Case #	Description	Stakeholders	CMM Maturity Levels
1	Ability to rapidly provision infrastructure and platform services for development and test systems from private, public, or community clouds	Dev/Engineering, DevOps, Test, Integration or Build/Deploy Teams and Systems, Procurement, Commercial, Security & Risk Mgt, Architecture	1-2
6	Ability to begin experimenting with cloud-native applications	Dev/Engineering, DevOps, Architect, Procurement, Security, Compliance, Enterprise Architecture	3-5
11	Ability to develop and deploy production-ready cloud-native applications	Ops, SA (System Administrator), Build/Deploy (Integration) Teams, Strategy, Security, Compliance, Enterprise Architecture	4-5

 

Step 3 – Conduct CMM assessment

This assessment aims to determine the current cloud maturity level and develop a roadmap to improve it. The assessment involves interviewing stakeholders from the selected domains relevant to your use cases.

To assess maturity, you must assess non-technical and technical domains. Consider the people, process, and technology elements in each domain. The table below shows the selected domains for the example use cases. 

Use case #	Non-technical domains	Technical domains
1	Skills Procurement Projects	IT Architecture Applications IaaS PaaS IPaaS Data
6	Finance Enterprise Strategy Structure Skills Compliance Business Process Commercial Portfolio Management Projects	IT Architecture Applications Management Tools Operations Processes Security PaaS STaaS Data Data Lifecycle Management
11	Enterprise Strategy Structure Culture Skills Compliance Business Process Portfolio Management Projects	IT Architecture Applications Management Tools Operations Processes Security IaaS PaaS STaaS IPaaS Data Data Lifecycle Management

For each domain, you should interview stakeholders, and to perform a consistent assessment, the CMM provides a series of control questions as an Excel questionnaire (OACA CMM Analysis Questionnaire v4.8.xlsx). An excerpt from this questionnaire is below:

Non-technical

Domain	Skills
Focus Area	Processes
Control Question	Is there a process defined to ensure new hires' skills are assessed appropriately?
CMM Stages
CMM 0 (None)	No consideration of cloud and cloud skills is incorporated into the process.
CMM 1 (initial, ad-hoc)	HR / Talent Acquisition performs basic checks to match technical skills required by the position as specified by Hiring Managers.
CMM 2 (repeatable, opportunistic)	HR / Talent Acquisition performs basic checks to match technical skills required by the position for all postings, as specified by Hiring Managers.
CMM 3 (defined, systematic)	HR / Talent Acquisition matches technical and soft skills required by the position for all postings, leveraging the existing skill competency matrix defined by Hiring Managers.
CMM 4 (managed, measurable)	HR / Talent Acquisition matches technical and soft skills required by the position for all postings, leveraging the existing skill competency matrix – Candidates are only sent to Hiring Managers once technical competency matrix matches >70%.
CMM 5 (optimized)	HR / Talent Acquisition matches technical and soft skills required by the position for all postings, leveraging the existing skill competency matrix – Candidates are only sent to Hiring Managers once technical competency matrix matches >70%; Hiring Managers assess depth of skills via panel interviews, case studies, and presentation skills analysis.

An example of non-technical control questions. (Source)

Technical

Domain	IT Architecture
Focus Area	People
Control Question	Who is responsible for incorporating cloud service provider capabilities into architecture?
CMM Stages
CMM 0 (None)	No specific accountability is assigned for incorporating cloud services into an enterprise's architecture.
CMM 1 (initial, ad-hoc)	Periodically, engineers, DevOps, systems administrators and architects will update architecture artifacts with cloud service provider capabilities.
CMM 2 (repeatable, opportunistic)	It is common for engineers, architects and DevOps to update architectural artifacts with cloud service provider capabilities.
CMM 3 (defined, systematic)	A standard framework such as TOGAF exists and is consistently used for updating architectural artifacts with cloud service provider capabilities.
CMM 4 (managed, measurable)	Updating architectural artifacts with cloud service provider capabilities is monitored and managed. Governance and periodic maturity assessments ensure compliance with this process.
CMM 5 (optimized)	Current state architecture artifacts are dynamically generated from the data sources within the operating environment, representing a snapshot of the existing environment. Transitionary and future state architectures are generated by modeling increases in scale, increases in performance, or cost optimizations.

An example of technical control questions. (Source)

The answers from the stakeholder interviews can be matched to a CMM maturity level. The level may vary across domains. Summarizing the domains on a barrier chart will identify the least mature domains and enable you to focus where there is the greatest potential for improvement.

An example barrier chart ordered by the least mature domains. (Source)

Step 4 – Develop a roadmap and execute

Based on the CMM assessment, a roadmap is developed that contains projects aligned with the domains. Using the barrier chart above as an example, preliminary projects should address skills, tools, architecture, and governance. The table below suggests project examples to mature from level 1 to level 3. However, some domains must grow from a different maturity level, and the desired future maturity state is higher or lower.

Capability	Domain	Focus Area	Current maturity level 1	Project example of maturing to level 3
Non-technical	Skills	People	Employees need more skills.	25-50% of employees possess and exhibit the appropriate skill level (Advanced).
		Processes	Employees choose to develop skills, attend training when opportunities arise, and make it part of their annual career development plans.	Employees are encouraged to attend cloud-relevant training at least once a year.
		Technology	Employees might track classes or development opportunities independently, using ad-hoc methods.	Skill development & training tracking system (e.g., online Skills Profile) is available, but usage is not encouraged/enforced.
Non-technical	Governance	People	Those who know they exist can find governance, risk, and compliance documents.	A communication plan exists, and feedback is obtained from the organization to update documents.
		Processes	Cloud bills are registered after costs are incurred.	Expected cloud budgets are known.
		Technology	Limited tools are available to monitor and report risk, security, and compliance information.	Defined and communicated auditing and monitoring exist/are signed off by all business units, with manual ad-hoc auditing.
Technical	Management Tools	People	Individual service consumers or LOBs control management tool selection.	Deployed internal and CSP  management tools, including some integrations that provide a hybrid IT view of some services.
		Processes	Some pre-production support teams are leveraging CSP-provided management tools.	CSP-provided management tools are integrated with internal support management tools, including end-to-end real-time service monitoring.
		Technology	Simple monitoring is provided, but contained to those services running within the cloud platform.	All CSP offerings include service dashboards with measured KPIs, including real-time end-to-end monitoring and reporting for each cloud service. Monitoring spans across cloud platforms.
Technical	IT Architecture	People	Based on personal interest, certain architects have some cloud knowledge.	All of the architects share a common framework and associated training regarding the enterprise approach to leveraging cloud services.
		Processes	Cloud-based solution design is pursued at times, but not consistently. When carried out, cloud architecture is addressed differently by different teams.	Solution teams consistently create architectural documentation for cloud solutions. A centralized or federated collection of standard cloud architecture templates and processes are available. Teams consistently start solution design from the core architecture processes and artifacts.
		Technology	Teams develop cloud building blocks on an ad-hoc basis. When used, building blocks are manually developed/ integrated via the portal of the cloud service solution.	RESTful APIs are a standard IT management methodology. The end user can use the interfaces without knowing of their existence.  A set of standardized cloud environment management tools and interfaces exist.

Projects are likely to have dependencies. For example, addressing cloud skills gaps is necessary to mature IT architecture discussions to include cloud services.

To build a roadmap, the OACA recommends that you:

• Ensure that selected domains cover both non-technical and technical capabilities.
• Determine the current CMM level for the selected domains.
• Determine the CMM level that describes the target state for the selected domains.
• Start at CMM level 1 and build to higher maturity levels. (Building to the same maturity levels across domains is optional.)
• Build a realistic timeline and build in feedback loops to measure the resulting benefits from each milestone. Identify KPIs so that you have something measurable to track.
• Consider the business impact and perform a risk assessment of potential disruption that the roadmap may cause.
• Have a higher level executive to champion the roadmap and remove any blockers to the initiative.

Cloud maturity model best practice #5: Avoid cloud adoption pitfalls

The following table lists common cloud adoption pitfalls and where a CMM can help.

Pitfall	OACA CMM Domain	OACA CMM Focus Area	CMM Project
Bill shock	Skills	People	Make sure all teams understand cloud total cost of ownership.  Considering costs can be new to technical teams, make sure the costs incurred by their cloud deployments are available.
	Governance	Technology	Improve your governance posture with a third-party management tool like CoreStack to continuously optimize cloud costs.
Vendor lock-in	IT Architecture	People Processes Technology	Vendor lock-in is a common concern, and with cloud computing costs following Bezos’ Law,  “The Cost of Cloud Computing will be cut in half every 18 months”  – Bezos’ Law ( Source), you want to avoid getting tied to an uncompetitive vendor. Adopt a cloud architecture that maximizes portability. Use frameworks, like Terraform, that support infrastructure-as-code to enable deployment to a different cloud.
Data Security And Privacy	Data	People Processes	Data in the cloud is stored on a shared infrastructure. Take time to understand the aspects of cloud security that are your responsibility. Develop processes that ensure that security best practices are being followed, like secrets management and encryption at rest and in transit.
Compliance And Regulatory Risks	Compliance	Technology	Make sure that you understand your regulatory requirements and data location restrictions.  Involve your organization’s legal team to help establish cloud governance policies. Continuously monitor and audit your organization's compliance posture with a third-party management tool like CoreStack.

Conclusion

This quote from Mike Chapple, Senior Director of IT Service Delivery at Notre Dame, summarizes the essence of cloud maturity quite well: 

“One of the things we’ve learned along the way is the culture change that is needed to bring people along on that cloud journey and really transform the organization, not only convincing them that the technology is the right way to go, but winning over the hearts and minds of the team to completely change direction.”

Cloud maturity isn’t just about technology. Organizations need to balance a mix of people, process, and technology in a way that works in their unique context. Using a cloud maturity model does not mean achieving a completely cloud-native maturity level. Furthermore, there is no such thing as the correct cloud maturity model, and you should not treat the models like a recipe to follow. Take the most relevant aspects and apply them to improve your chance of success with cloud adoption.