AWS’s Cloud Operating Model Framework

We’ve discussed how Azure define a cloud operating model in our previous article. Azure have set the Cloud Operating Model (COM) as part of their Cloud Adoption Framework (CAF). The COM and CAF together have covered the three commonly agreed key components, i.e. people, process and technology. Let’s take a look at AWS’s approach in this article.

AWS’s Cloud Operating Model Definition

AWS’s approach on defining the cloud operating model is more from a practitioner’s angle. Instead of putting a conceptual definition on what is a cloud operating model, AWS have provided the following statements:

• “A successful cloud operating model (COM) enables organizations to operate applications reliably and securely in the cloud with a faster pace of innovation and value to the business“; and
• “A successful cloud operating model ensures that all components such as people, processes and tools, are set up to support one another effectively.“

It’s a bit like handling the question like “what is a car?” Instead of defining a car as a piece of metal that sits on top of four wheels, they say that a car is a machine that transports you from A to B. It focuses on selling the problem instead of the solution. And these statements seem to have covered the people, process and technology in a way as well. We’ll see how AWS support these statements in details.

AWS have highlighted two key cloud operating practices in their whitepaper, i.e. Product Based Approach and Cloud Enablement Engine (CEE). We’ll go through both of them and see how AWS associated them with the COM.

Product Based Approach

The product based approach AWS refer here is not a new concept. It’s also known as Product Oriented Delivery (POD). To understand POD, let’s start with a picture.

The vertical pillars here refer to the traditional model. In this model, business and IT, and different teams within IT are in a siloed structure. Under this structure, we often see requirements, tickets and approval requests flying among these pillars, which limits the agility and efficiency. In the on-prem age, it may not become the most pain point as it takes time for the hardware to be ready in the data centre anyway. But when provisioning or changing infrastructure can be done by a few clicks or even automated in the cloud, this siloed operating model will become a serious bottleneck.

To address this bottleneck, the POD model comes into the picture, as shown in the horizontal bars. A POD/product team is self-sufficient and cross-functional. It’s a group of people (e.g. a single 2-pizza team with 6-10 people) with different competencies who can work collaboratively to deliver a product based on the requirements. It converts the original team-to-team interactions into an in-house collaboration. It significantly reduced the lifecycle and time for delivering a product and business value.

AWS highlight this product based delivery of cloud as a key success factor and foundation for the cloud operating model. And their CEE is based on this product based approach. And AWS has provided six detailed transformational steps to help organizations form a product-model and CEE.

Cloud Enablement Engine (CEE)

AWS introduced CEE approach that is also known as Cloud Centre of Excellence (CCoE). Again, CCoE is not a new concept. It’s a known best-practice approach to drive cloud-enabled transformation. The six steps that organizations can follow to build out a successful CEE are:

• Work backwards from the customer
• Re-envision the world as products
• Organize teams around products
• Bring the work to the team
• Reduce risk through iteration
• Own your entire lifecycle

In a picture, the six steps look like below:

We can summarise these six steps as What (step 1 & 2), Who (step 3) and How (step 4, 5 and 6). Or if we take a look from the POD angle, step 1, 2 and 3 are about forming/transforming to a POD model, and step 3, 4 and 5 are about operating the POD. We won’t repeat the details of these steps here, as AWS has done a good job detailing them in Building a Cloud Operating Model. Instead, we’ll take a look at two common questions people have asked below.

CEE vs CCoE

People may ask why didn’t AWS just use the term CCoE but invented a new term as CEE instead? Well, AWS didn’t specifically explain why. Let’s see if the answer can be revealed through a few comparisons.

Firstly, let’s take a look at what a CEE contains, which AWS has clearly defined. A CEE consists of two functional domains: Cloud Business Office (CBO) and Cloud Platform Engineering (CPE). The CBO focuses on the business governance and people enablement, while the CPE takes care of brokering and building operational platforms with shared capabilities and controls.

When it comes to CCoE, there are many interpretations and definitions of what a CCoE should contain (maybe this is one of the reasons why AWS have created their CEE “canvas” for their “drawings”). Let’s say a CCoE should at least consist of the following resources:

• Cloud adoption (solution architects)
• Cloud strategy (the program and project managers)
• Cloud governance
• Cloud platform
• Cloud automation

Yes, to make this comparison interesting, we got the above list from Microsoft. We can fit all of them into CBO (covering cloud adoption, strategy and governance) and CPE (covering cloud platform and automation), as shown below.

Or if we use Gartner’s three pillars of a CCoE, i.e. Governance, Brokerage and Community to compare with the CEE, we can also match these three pillars in both CBO (covering governance and community) and CPE (covering brokerage). So from the components point of view, CEE does align with CCoE.

And from the objective aspect, both CEE and CCoE share the same purpose. It’s to enable and support a successful COM. Now we can probably reuse our car analogy here to answer the CEE vs CCoE question. If CCoE refers to a general concept of a “car”, then CEE is an AWS manufactured “car” that contains the AWS specified functions.

Product vs Application

In the six transformational steps we covered earlier, step 2 was talking about re-envisioning the world as products, but step 6 was talking about application in the lifecycle. So are these two terms referring to the same thing? The short answer is yes and no. We’ll explain why.

Let’s borrow the car analogy again. When we look at a car, we would think a car is a product. We wouldn’t think a tyre or a windscreen as a product. This is because we are wearing the end-user hat to interpret what is a product. If we wear the same hat to look at a cloud-based product, e.g. an online financial product, it may contain a number of applications in it. For such a product, a single 2-pizza team will never be able to manage it end-to-end.

So what is the product referring here? AWS has provided four key criteria when defining a product:

• Performing a constrained number of common tasks very well
• Having clearly defined inputs and outputs
• Being useful to multiple customers, and
• Continuously improved to meet the needs of those customers

AWS used their amazon.com as an example to explain how they moved to a product model. They used to have a large, Java-based e-commerce application. They’ve decoupled this application into multiple products, e.g. Home Page, Customer Account, Search, Shopping Cart, etc. Following the same definition guidance, a cloud platform can also be decoupled into Access Gateway, Search, Continuous Compliance, etc.

So the product we are talking about here is not specifically referring to an end-user facing product. Sometimes a small application can be treated as one product, but most of the time decoupling is required. A bit like transforming a monolithic application to microservices. But it’s not only limited to application, but also applied to cloud platform and services.

Now if we look back at step 6 again, the application teams and platform teams can both transform into product teams. How we define and decouple products may vary case by case. Using AWS’s four-point definition guidance is one way to define products. Or some times reverse engineering may also help. For example, if we are aiming to set up 2-pizza teams to manage products end-to-end, a product that can’t be handled by such size of teams will need to be further decoupled.

Summary

When we map AWS’s framework with the three common COM components, i.e. people, process and technology, we can see that AWS has put a lot focus on the people part. In our previous article, we can see that Azure have shed more lights on the technology part in their COM guidance instead. Still, there is no right or wrong. Both guidance have provided their own point of views and together they can help organization build their target COM. In our next article, we’ll take a look at Google’s approach.