Step 6. Own your own lifecycle - Building a Cloud Operating Model

Step 6. Own your own lifecycle

The cloud offers a great deal of opportunity to mitigate work arounds, sticking plaster and the ills of years of neglect and continuous addition. What starts out as a simple minimal viable product to deliver X, can rapidly turn into a desire to build the perfect datacenter in the cloud. The consequence being a multi-year initiative, minimal workloads live in the cloud, a trail of directional and resource changes with little or no business value or outcomes delivered.

Successful adopters take two key actions to help ensure they own their own lifecycle and deliver meaningful benefits. Firstly, they align the operating model delivery approach to the strategic value of the workload. While the Cloud Platform and the Engineering team should be adopting a DevOps (you build it, you run it) approach, don’t expect everyone else to immediately have the desire to make the same change to their delivery model. In our engagements with customers we have seen three broad approaches being adopted as shown below.

        Modernizing IT

Modernizing IT


This model takes on a Traditional Operations approach. This is nearly identical to the traditional, activity-based model we see in most organizations where engineering, operations, infrastructure and application teams and boundaries exist. This model works best for lift-and-shift workloads where there is little or no value in changing the operational approaches for the workload either because it rarely changes or has a limited lifespan left.


In this model Application Engineering is now also responsible for Application Operations. Think of this as DevOps for the application team, where they own the full outcome of delivering and operating their application. Similarly, Cloud Platform Engineering now owns engineering and operations of the platform services they provide to enable Application Teams. This approach implies a Shared Responsibility Model between the Application and Platform teams. Platform teams provide the codified enterprise standards and governance that enable Application teams to iterate quickly, without burdening them with knowing deep implementation details of the underlying platform.


For teams that are on the bleeding edge of technology, looking to consume the latest AWS services, we see this model being adopted. In this model application engineering is responsible for their applications, but in order to avoid stifling innovation for high-growth areas of the company, they are empowered to build out platform capabilities that have not yet been standardized by the Cloud Platform Engineering team. Cloud Platform Engineering still provide standard accounts and guard rails that prevent Application teams from configuring Services in a way that would expose the enterprise to inappropriate security, financial, or operational risk

The three models do not imply levels of maturity. In fact, we see all three of these operating models in most companies. That said, there is almost always a gravitational pull towards Optimize. Sustain workloads get retired or outsourced, and the platform services used by Grow workloads eventually become the new enterprise standards. This allows even the most cutting-edge teams to be supported by the Cloud Platform Engineering team, so that these application teams can focus on adding new digital business value, rather than doing the undifferentiated heavy lifting of maintaining platform capabilities.

Successful Cloud Operating Models and CEE’s establish a clear roadmap of delivering capabilities and processes that align and underpin the ability to establish production operations in an MVP and iterative approach. Many customers already have operational processes and procedures in place for IT delivery and change management. Some of these will be well documented and aligned to standards such as ITIL, others will be implemented through localized ways of working.

AWS established our Operational Integration Domain based blueprint model derived from assessing industry standards that were most applicable to cloud platforms and addressing the needs of our customers in establishing a cloud operating model and CEE. The AWS Operations Domains shown below represents a framework, based on best practices, that will enable IT (and business) organizations to transform their current ITIL (and other) based Operating Model towards a cloud-based architecture adapted model.

           Operational Domain Model

AWS Operational Domain Model

The domain model currently focuses on different aspects and highlights where they align into the CEE responsibilities. It is important to note that these domains continue to evolve through continuous improvement and should be considered as the 80/20 rule in covering most operational processes that a majority of customers will need. There may be additional operational processes unique to a customer’s organization or specialized industry that need to be taken into consideration.

The Domain model can be used to show and communicate the CEE operational capability roadmap across MVP cycles as shown below.

          Operational Capability Roadmap

Operational Capability Roadmap

It’s worth highlighting that ITIL and AWS Operations Domains are compatible. ITIL is a recognized Industry Standard, comparable to similar initiatives. The ITIL framework was built to improve and generalize a best practice in regards to implementing, maintaining and operating IT services. ITIL has a high number of certified practitioners, all over the world, but like all frameworks it is not perfect and has its set of criticisms. When hard-linked into systems (monitoring, ticketing, support services, etc.), ITIL processes can be complex to transform. The purpose of the domain model is to help the CEE own and establish its operating model roadmap.