Assessing Your Organization’s Cloud Maturity Level

By Lee Atchison | May 16, 2022 | Cloud Adoption & Migration | Cloud

Operating successfully in the cloud is still a daunting challenge for many companies today. Too often, organizations have overly high expectations about the benefits of being in the cloud while underestimating the amount of work required to get there. An unfortunate result can be a vicious cycle of blame, finger pointing, and business leaders grasping for something—anything—that could be considered a victory.

When they find that small bit of success, organizations may decide they’ve had enough and stop the migration process before they can take full advantage of the cloud. But by putting off real reform, they will never realize the cost and innovation benefits that drove the cloud migration project in the first place. As migration costs balloon and promised features, functionalities, and applications fail to materialize, companies can end up seeing the cloud as little more than an expensive boondoggle.

What happened?

In many cases, the biggest error comes from thinking about the cloud in the wrong way. Most people think of cloud migration as a lift-and-shift operation—simply moving applications that are running in a company’s own data center into the cloud.

But real cloud success, at scale, requires much more than lift-and-shift. It demands successfully navigating the world of the dynamic cloud.

The dynamic cloud doesn’t just facilitate application scaling, it makes the process faster and easier. It also helps development teams respond to changes faster, and implement these changes more quickly. That’s not a luxury—it’s a necessity to ensure the availability of applications with highly dynamic scaling needs, which can include huge, unanticipated spikes.

To succeed in the dynamic cloud, however, takes a higher level of commitment than does lift-and-shift. Teams must move in a controlled manner and learn from their mistakes along the way. Most important, everything must be measured during a migration.

That’s because after a migration, the type of application and infrastructure visibility that is required changes. Many resources become dynamic, so keeping track of what resources are important for what purposes also becomes dynamic. Additionally, applications now run on an infrastructure outside of a team’s direct control. Unless an application is carefully monitored along with the cloud in which it runs, it can be impossible to tell if a particular problem is related to the application or the cloud service.

Fortunately, becoming proficient in the dynamic cloud does not have to be scary or dangerous. Adopting the cloud can be done safely and effectively, but is a continual learning experience. Organizations must be willing to learn and adapt cloud offerings to match their needs and expectations with the reality of what the cloud can provide.

The 6 levels of cloud maturity

Critically, you can’t expect to get there all at once. There are six basic maturity levels that organizations go through during their cloud adoption process:

Experimenting: What is the cloud?
Securing the cloud: Can we trust the cloud?
Enabling servers and SaaS: Lift-and-shift, confirmation the cloud works pretty well.
Enabling value added services: Dynamic cloud becomes a practice.
Enabling unique services: Dynamic cloud is deeply ingrained in the culture.
Mandating cloud usage: Why do we need our own data centers?

To be successful in moving to the cloud, it is important to realize that this continuum of cloud maturity exists and to understand the implications for an organization’s actions and processes. Moving from one level of maturity to the next isn’t always easy or fast, and the specific details differ for every organization. Often, application and infrastructure visibility are key elements missing from the cloud maturation strategy, and this can limit and block successful growth in adopting the cloud.

Finally, organizations sometimes settle on a level of cloud maturity that’s right for their culture and conditions—and that’s okay, even if it falls short of the highest maturity level.

Level 1: Experimenting with the cloud

This first, tentative step into the cloud relies on safe technologies—those technologies that apply in simple ways to applications and parts of applications that are typically less mission critical.

Level 1 involves using the cloud for a single, simple piece of an application to test how cloud services work. Often, the first service used is a storage solution such as Amazon Simple Storage Service (S3), because it’s easy to store some things in the cloud and avoid addressing the complex processes and servers an application relies on.

This level usually starts as a one-off experiment, where one or more teams conduct stand-alone migrations. No cloud policies are created at this point; instead it’s all about figuring out exactly what the cloud is.

Level 2: Securing the cloud

Level 2 is a critical evolution point in an organization’s cloud culture, as it begins to involve disciplines throughout the company—legal, finance, security, and so on.

This is when policies on how the cloud can be used within a company begin to be formed. The precise nature of these guidelines, from formal policies to ad hoc “company culture” understandings, don’t matter that much. What’s important is that the entire company is involved and all stakeholders have input.

This is also when application visibility and monitoring strategies should be conceived. The goal is to answer such questions as:

How do we monitor basic applications as they move to the cloud?
Can that monitoring strategy handle the dynamic changes coming with future cloud maturity growth?
Do we have the correct visibility into how our new cloud infrastructure functions?

Companies that don’t get past this point most likely won’t be fully successful in the cloud.

Level 3: Using servers and applications in the cloud

The third stage of cloud maturity comes when an organization begins to replace on-premises servers and other backend resources. These are still simple lift-and-shift applications, with a basic philosophy of “Let’s just move an application to the cloud and see what happens.”

The result of this level should be an understanding of how the cloud works from an entire application standpoint. Critically, this is the point at which the organization begins to enjoy actual advantages (lowered costs, increased flexibility, etc.) from using the cloud.

Level 3 is also when an organization’s application visibility and monitoring strategies being used in data centers get extended to the cloud. These monitoring and visibility strategies become a central component in making sure an application migration is successful.

Be warned, however: Level 3 can be a danger point. If organizations attempt to evaluate the value of running applications in the cloud at this stage, they may find they’re bearing the costs of the cloud without enjoying the corresponding benefits. That can cause companies to give up and regard their entire cloud effort as a failure.

Level 4: Enabling value-added managed services

Of course, the cloud is much more than just a place to host applications on servers outside of a company’s data centers. At Level 4, organizations begin to take advantage of some of the cloud’s value-added services.

A typical Level 4 conversation might go like this: “Okay, now that I have a database in the cloud, I still have to manage that database, but AWS and Microsoft Azure and everyone else offers managed databases. Why don’t I let them manage the database for me?”

This is when organizations take advantage of managed services in the cloud, including services like Amazon Relational Database Service (RDS) and Amazon Aurora. They may also look at services like Amazon Elastic Beanstalk and Amazon OpenSearch Service to provide even higher value services to their applications.

As the dynamic cloud starts taking effect here, the cloud’s biggest benefits kick in. This is also when companies commit to using the cloud for at least some of their strategic applications and services.

Level 5: Enabling cloud-unique services

Once a company becomes a cloud-enabled organization, it can look to leverage high-value, cloud-specific services. Uniquely available in cloud-based environments, these services are designed for the dynamic cloud. They include serverless computing (such as AWS Lambda), highly scalable schemaless databases (such as Amazon DynamoDB), data warehousing (Amazon Redshift), and other generalized services, such as queuing (Amazon Simple Queue Service, or SQS) and notification (Amazon Simple Notification Service, or SNS) services.

At Level 5, the concept of dynamic cloud becomes embedded in an organization’s application development and management processes. It is important at this time to make sure your monitoring strategy gives you the proper visibility you require into these highly dynamic applications.

These services are also tied to specific cloud providers. While many cloud providers offer serverless capabilities, each one does so in a slightly different manner. As organizations begin to use these higher-value, cloud-unique services, they not only become tied to the cloud, but also to specific cloud providers.

Level 6: Mandating the cloud

This is the ultimate maturity level of cloud adoption. When an organization reaches Level 6, the cloud is meeting most if not all of its data center needs, and also provides additional value-added services. This prompts many companies to ask the next obvious question: “Why do we need our own data centers? Why do we need to be in the business of running a data center at all?”

At the very least, at Level 6 new applications default to running in the cloud rather than running in a data center, and the organization must justify why they would need to be in a data center. The end goal, though, is to migrate all applications into the cloud so the organization can decommission its data centers.

This is especially common in cloud native companies, while more established enterprises may choose to retain their legacy data centers, at least for the time being. Nevertheless, more and more traditional enterprises are taking the cloud plunge and abandoning the business of managing data centers.

Reaching the cloud adoption sweet spot

The six cloud computing maturity levels apply to individual applications, organizations, or entire enterprises. But the cloud maturity level of a particular application may be higher or lower than that of the organization as a whole.

For example, early candidates for cloud migration include internal applications, because they present less risk of negatively impacting customers and the business itself. In fact, an internal application may jump to Level 6 while the overall enterprise may still sit at Level 1.

In certain cases, the interplay of application and enterprise maturity can create a cloud adoption sweet spot. This is the point in the maturity curve that many companies and many applications gravitate toward. Companies—and individual applications—tend to move quickly upwards toward this sweet spot, but then slow the migration process once they reach it.

Reaching the sweet spot is not necessarily good or bad; it’s simply a function of the fact that the early stages of cloud adoption may offer the highest return on investment. Moving beyond the sweet spot may or may not make sense, depending on application needs, company culture, business processes, and business needs.

To read more about this topic, check out my book Architecting for Scale, published by O’Reilly Media.

More articles by Lee Atchison:

Image by Mohamed Hassan from Pixabay.