Enhancing Your Cloud Strategy with a Cloud Maturity Model

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 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)

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.

FREE 15-MIN VIDEO: LEARN MODERN CLOUD GOVERNANCE BEST PRACTICES

Watch Now. No Forms

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)

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.

 
AI-powered Continuous Cloud Governance

Learn More

Platform

Provisioning Automation

Security Management

Cost Management

Regulatory Compliance

Powered by Artificial Intelligence

Native Hybrid Cloud Support

Azure Native Tools

 
 
 
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.

You May Also Like…

Inc. Magazine Ranks CoreStack No. 41 on List of the Pacific Region’s Fastest-Growing Private Companies

X
Share This