What is a cloud operating model? When we ask this question, we probably will get many different answers. If we extend the question by asking, what does it contain? We will get various answers too. But we can find some commonalities shared in these answers, which are people, process and technology. There seems to be a common agreement that a cloud operating model should at least cover these three key components.
Under the spotlight of public cloud, Azure, AWS and Google Cloud (GCP) have given their answers to these two questions as well. We’ll take a look at how they define the cloud operating model, starting with Azure in this article.
Azure’s Cloud Operating Model Definition
Azure’s definition on what is a cloud operating model is: “A cloud operating model is the collection of processes and procedures that define how you want to operate technology in the cloud“.
This definition is under the context that Azure tries to describe the differences between the cloud based operating model and traditional on-prem based operating model. From on-prem to cloud, some key factors have changed (e.g. physical hardware management changed to cloud resource management, CAPEX changed to OPEX, etc), while the other factors remain the same (e.g. business strategy alignment, people, security and compliance, etc). The detail-level information are available at How’s a cloud operating model different?
Azure has also called out that operating models aren’t snowflakes. Instead, based on a business’s requirements and constraints, cloud operating models can be grouped into a number of common patterns. Let’s see what are these patterns.
Operating Model Patterns
Azure has summarised four common cloud operating models, Decentralized Operations, Centralized Operations, Enterprise Operations and Distributed Operations, as shown below:
Azure has done a good job by thoroughly comparing these patterns with detailed pros and cons. We won’t repeat them here. The detailed comparison information are available at Compare Common Cloud Operating Models.
We can see that Azure grouped these patterns more from the scope of technology aspect. In other words, we can interpret these patterns as independent workloads (decentralized), workloads in one Landing Zone (centralized), workloads in multiple Landing Zones (enterprise), and workloads in multiple patterns combined (distributed). These patterns together provide a good coverage from the angle of organizing and managing workloads.
However, let’s take a look at Azure’s definition again, i.e. “A cloud operating model is the collection of processes and procedures that define how you want to operate technology in the cloud“. There are not much process or procedures reflected here. And if we use the people, process and technology to measure the coverage, the people part is missing too. At least not from the pictures.
So if an organization wants to know how to organize their teams around their cloud operating models, these patterns aren’t shedding enough lights.
People and Process
People and Process are two critical components of a cloud operating model. Surely Azure won’t leave them out. So we have to take a step back and look at the parent level, i.e. the Cloud Adoption Framework (CAF).
When we lift the view angle a bit higher, we can see that Azure puts the cloud operating model as part of its CAF. Under this CAF, Azure provided eight methodologies and their guidance, as shown below:
- Strategy
- Plan
- Ready
- Migrate
- Innovate
- Govern
- Manage
- Organize
The cloud operating model patterns are put under the Ready section. In addition, the Strategy (especially the security strategy), Govern, Manage and Organize should also be used to shape the overall operating model. And these methods together caters for technology, security, compliance, processes, functions and people, which pretty much covers the two “missing” key components we talked about earlier.
So if we ask that people-related question again, i.e. how does an organization organize their teams around a particular cloud operating mode? The answer is in the Organize section. It has specifically covered the exercises including structure type, cloud functions, mature team structures and RACI matrix.
For the process part, Azure uses the Manage section to describe the exercises that organizations can follow to develop business and technical processes to support the cloud operations.
In addition to those three pillars, Azure also throw in the governance and security guidance. We will give Azure a thumb up on these additions. People, Process and Technology are key components of a cloud operating model. This has almost become a common sense. However, it doesn’t call out the governance and security specifically. These two components are equally important comparing with the first three. So it’s a practical approach to also give these two additional components dedicated sections.
Summary
From the user experience point of view, it’s a bit confusing initially to see a child’s toy in their parents’ pockets. Or in other words, putting the people and process parts outside the cloud operating model section. But once the view is opened to the CAF level, it becomes clearer.
There are different ways of defining a cloud operating model. We won’t call a particular way right or wrong. It’s like the car manufacturers. They have their own ways of designing and building cars. But they all share the same purpose as putting running cars on the road. Azure certainly have provided their view and approach to help organizations define their cloud operating models. We will go through AWS’s approach in the next article.
