How is a company’s cloud maturity determined? What is it actually good for, how can you assess it, and what stage of the maturity model are you at?
I want to describe an interesting issue that we are addressing first with the customers we are bringing to the cloud. Before we start working with a customer, we need to understand where their teams are mentally, process-wise and knowledge-wise. We are interested in the cloud maturity of the customer. What is it and how to do it?
Before I pick an apple, I look to see if it’s only red on one side. In the same way, we assess together with the customer (it’s partly a self-assessment!) various aspects of their capabilities and operation.
What does a company have to be like to be considered a mature cloud company in all respects?
Do we have to worry about the process?
The maturity assessment method we use is largely based on a process maturity assessment. And that’s the right thing to do. Because we are talking about IT services provided to the business, and in the operational model these consist mainly of processes. Functioning processes – please don’t show us the paper hidden deep in your document repository until the last thing.
There is a sophisticated general methodology for assessing process maturity. It is therefore not difficult to determine it by examining several parameters over the basic architectural, change and operational processes.
Do you feel now that the more procedural the customer, the more mature they are for us? Oh, no.
Do we have enough certified people?
I can hardly talk about cloud maturity when most of the team hasn’t touched the ball (i.e. the cloud) yet. Specifically, in 2021, a significant portion of IT operations professionals have already touched it, but often only in the locker room, not on the field.
Surprisingly many companies have teams that are trying out cloud services out of their own enthusiasm, personal initiative or shadow IT. But the lack of preparation will not allow them to learn how to operate and use the cloud properly in practice.
On the other hand, we have encountered companies that have been forced to consume cloud services by leaps and bounds. There we find a very good deep knowledge of often advanced services in people who “somehow haven’t had time” for AZ-104 or some AWS Practicioner.
So do you feel that the more certifications in the team, the more cloud mature the company will be? Also no.
Do we have a sophisticated IT strategy?
Using cloud services is usually a major IT outsourcing that a company must be prepared for. In addition, which fortunately customers who are affected by even more regulations than GDPR are well aware of, the company must internally process a quality analysis of the use of external cloud services in terms of regulation, data and process compliance.
A detailed study of the current IT strategy documents and compliance analysis is one of the first steps we take in the maturity assessment. We are interested in the company’s attitude to cloud services, how it treats outsourcing, how it wants to treat different types of data, how it wants to set rules for operation and more.
Does it seem to you that a well-developed cloud IT strategy points to a mature customer? It doesn’t have to be that way.
Do we have the tools we need?
Enough questions, even that’s not enough. The pile of tools implemented left and right rather shows how much power individual teams have to inflate the budget. It doesn’t have much to do with maturity.
So what is it then?
Let’s go back to the opening paragraph on why we care about any cloud maturity at all: “We need to understand where the customer’s teams are mentally, process-wise and knowledge-wise.”
- The right mental setup = I have it figured out and experienced.
- Ideal process setup = I do it the same way, auditable, recordable.
- Correct knowledge settings = I use the tools optimally.
WANT – this is the basic parameter. Do you have toxic individuals in your team talking about the dysfunctional unreliable expensive public cloud (which was mentioned in the previous article) or a bunch of people who want to have modern tools that remove all unnecessary routine? Those who want to work with the public cloud have the necessary mental setup. They have already adapted and mastered the processes and knowledge with us.
Once the above three things are working, the customer is able to run business applications in the cloud. We are happy to help him with the complexities of DevSecOps and automation in general, security, advanced monitoring, translating regulatory changes into compliance or creating cloud centers of excellence. And with my personal favorite – continuous cost optimization, preferably using a self-optimized coded infrastructure.
And if those three settings don’t work?
So we and the customer have a lot of work to do. But we’ll follow the beaten path.
Let’s see your maturity model!
OK, here it is. For convenience and some compatibility with other models, we use five maturity levels, which we call:
Which one do you find yourself in?
Ad-hoc approach – Resistant
- He’s piloting, trying his first e.g. test environment.
- He is delaying the move to the cloud because he understands that it is an investment with a long payback period.
- It expects a suitable business case in the application unit, which means a large investment in its own datacenter and easy launch in the public cloud.
Opportunistic approach – Explorer
- He has the first non-critical production workloads in the cloud.
- It tries to place suitable applications in the cloud, for example. the life cycle ends.
- Paired core ITSM processes to support cloud operations.
- They try to acquire adequate knowledge in teams.
- It is considering appropriate tools for monitoring its distributed infrastructure.
Repeatable Access – Player
- It operates in the cloud with clear operating principles.
- It also runs business-critical applications in the cloud.
- It has well-configured monitoring, backup and high availability.
- It addresses security and compliance in the cloud.
- It has set processes for budgeting and monitoring costs.
Controlled Access – Transformer
- They are changing their business thanks to IT.
- Applications are primarily hosted in the cloud, and when that’s not possible, they seek a hybrid cloud.
- On-premise remains a zoo application before transformation or shutdown.
- It regularly innovates and uses new services.
- The cloud application lifecycle is driven by a DevOps approach.
- It manages and effectively manages its capacity.
Optimised access – Disruptor
- For him, the cloud is an essential IT tool for developing business potential.
- It has full automation within the DevSecOps mentality.
- Automates meta-processes to control, monitor and improve processes.
- He has long-term experience in cost optimization.
- It uses the latest services and often works directly with the provider to develop them.
Cloud maturity: is the top tier the best?
All levels of maturity are correct as long as they are related to the needs of the business. Not bad to be at the beginning. It is wrong to think that I am at the end and not have worked all the necessary steps. Not having a strategy, compliance, ITSM processes, tools, knowledge, motivated team, sophisticated automation, exit scenarios, risk analysis, application criticality analysis, etc.
For us consultants, the most rewarding part is working with Explorer. And the biggest challenge is of course the Disruptor, who knows how to torment us well with his specific problems and deep knowledge of the subject.
Having a definition of what a customer’s cloud maturity is may be an exercise, but it is a necessary start for us to make a positive change. You can read about it in other articles in our Cloud Encyclopedia.
This is a machine translation. Please excuse any possible errors.