Cloud Operating Model
The big picture of the future-state operating model of Cloud
Disclaimer: This content is based on AWS’s Cloud Operating Model.
A Cloud Operating Model is defined as an abstract model of how an organization delivers value to its internal and external customers, through the use of cloud services.
Consider how your current central IT function may deliver its data center services to the various business units it supports today. This is a well defined operating model, which has been matured over a long period of time.
Now, as part of your cloud transformation, you must rethink your approach across people, process, and technology to achieve the benefits that cloud technology brings. To iterate in the cloud what’s been done in the data center is to either fail or gain little benefit.
The greater opportunities for cloud transformation lie in operational efficiencies and benefits to the business itself. Of course, substantial infrastructure savings, which is typically form only a small percentage of total IT spend. To truly transform, people and process models contribute significantly.
Strategy to building a Cloud Operating Model provides a big picture of what the future may look like across Business and IT domains. It brings everyone on the team to the common understanding to promote a sense of purpose and a common mission and shared values.
This white paper provides the fundamental constructs of a Cloud Operating Model with building blocks to define business architecture and technology architecture based on rich cloud transformation experiences. It allows you to create a roadmap for accelerating the realization of transformation benefits that cloud adoption can bring. AWS cloud is specifically referenced in this white paper. However, other cloud platforms can be adopted as well as it fits the needs of an organization.
Strategy to Cloud Operating Model
The Cloud Operating Model should define how the Business and IT align their capabilities, processes, and workforce to reach strategic business outcomes.
The strategy to define the Cloud Operating Model for your organization starts with the understating of your Business and IT Operating Models.
In most organizations, both the Business Operating Model and the IT Operating Model are not in strong alignment.
Consider this illustration:
The business tends to focus on the capabilities or products that it provides to customers. IT is focused on deploying technology capabilities that may have nothing to do with the Business.
They have completely different processes for how they accomplish their work. Their workforce usually sits in separate buildings and rarely talk to each other. This creates a misalignment in the outcomes that they are trying to achieve.
The Business may want to build new business capabilities or customer-facing products meanwhile IT may be focused on operational excellence. When you are building new experimental products you may not have the highest levels of stability or performance so these two things conflict.
The Business may be looking for increased speed and agility meanwhile IT may be looking to cut or optimize costs. Sometimes you have to go fast and to do so, you need to spend more money so at times these things are also in conflict.
Business is ultimately looking to deliver business and customer value. In other words, results. Meanwhile, IT may be laser-focused on security and compliance. This creates an environment that is so restrictive that it impairs the business’s ability to produce the expected results.
This lack of alignment is especially concerning in today’s business environment given that more and more of the products being produced by enterprises are digital products where alignment between the Business and IT is crucial to the success of those products in the market.
A great deal of this misalignment comes from the fact that both Business and IT are organized around activities or functions being performed where each owns a different piece of the end-to-end value stream that turns ideas in the business into value in the form of software-based products accessible to end-users.
This is because most Enterprises operate in an “activity-based” model
The below diagram illustrates this point. On the vertical axis, we have Infrastructure and Applications. On the horizontal axis, we have Engineering and Operations.
Applications refer to the business software that can be either custom developed or purchased.
Infrastructure is everything that supports those applications including physical or virtual infrastructure or software-based infrastructures like middleware and databases.
Engineering is the development, building, and testing of applications and infrastructure.
Operations provide the deployment and ongoing support of these applications and infrastructure.
In most organizations, each of functions of the quadrant is performed by a separate entity of the organization.
Application Engineering is done by a different team and Application Operations by different teams.
An Infrastructure Engineering work is done separately from work being done by the Infrastructure Operations team.
Work is passed between these teams via an IT Services Management (ITSM) Platform, passing work requests between teams through work queues and tickets.
A great deal of this misalignment comes from the fact that the organizations of both the Business and IT are structured around activities or functions being performed where each piece of the organization owns a different piece of the end-to-end value stream that turns ideas of the Business into value in the form of IT software-based products accessible to end-users.
In practice, these local optimizations cause the flow of work across the overall value stream to be sub-optimized as work is handed off from team to team. Bottlenecks and delays get created.
Cost is optimized by distributing accountability across pools of resources
Teams are incentivized to work quickly to maximize their throughput. But, in the process, they frequently create defects that are passed downstream resulting in rework. If the defects are caught early in the value stream, the rework may be minimal. But if a critical security defect is found late in the delivery process, it would cause rework to be done in design and engineering, causing the entire value stream to be exercised all over again.
Each hand-off and defect delays time to value which is the most pressing concern for modern digital enterprises.
To better align the Business and IT, it helps to consider and accept that no single approach to IT will support all areas of the Business. One approach is to consider three categories of operating models each aligned to desired outcomes.
Sustain: These are the areas of the Business that at one point may have been strategic but now either stagnated or in decline. Making deep investments in IT to support these areas of the Business does not usually make sense. Recommend optimizing cost doing the bare minimum to keep the lights. Or, even outsourcing or retiring these workloads may be a better way to go.
Optimize: These are the current core areas of the Business as it exists today providing or supporting significant revenue. Any disruption significantly impacts core business operations. Recommend making investments in resiliency, availability, security, scalability, and performance.
Grow: These are the areas of Business where priority is growth. Either by taking market share from competitors or creating net new differentiated digital products. Since uncertainty and ambiguity are high for these aspects of the business, the ability to iterate quickly to learn to hypothesize and experiment and to use continuous delivery and A/B testing is non-negotiable.
How does your operating model align with Business outcomes?
Let’s consider how each of the Business outcomes changes who is responsible for a given set of capabilities and processes within these three different operating models.
Think of this as traditional operations. This is nearly identical to the traditional activity-based model. Just as you lift and shift workloads in this model, you also lift and shift your traditional operating model.
Application Engineering is still done separately from Application Operations. We now have a Cloud Platform Engineering team instead of multiple Infrastructure teams. But, we have a separate Cloud Platform Operations team that is separate from Engineering.
Here we start to see the broadening of responsibilities for both the Application and Platform teams with activities turning into outcomes.
The Application Engineering team 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 that they provide to enable Applications team. This Cloud Platform Engineering team is now a DevOps team as well. This 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.
We refer to this as a Distributed DevOps model because the DevOps responsibilities are distributed between Application and Platform teams.
For teams that are on the cutting-edge of technology looking to consume the latest cloud services as soon as they are launched.
Application Engineering is responsible for their applications but to avoid stifling innovation for high-growth areas of the company, we also empower them to build out Platform capabilities that have not yet been standardized by the Cloud Platform Engineering team. Cloud Platform Engineering is still present but in a reduced capacity to provide standard accounts and security guardrails that prevent these cutting-edge application teams from configuring cloud services in a way that would expose the enterprise to inappropriate security, financial or operations risk.
We call this model Decentralized DevOps because the platform responsibilities have been decentralized away from the Cloud Platform engineering teams.
The three models do not imply levels of maturity. We see all three of these operating models present in most companies.
However, there is almost always a gravitational pull back to Optimize. Sustained workloads eventually get retired or outsourced and the platform services used to Grow workloads eventually becomes new enterprise standards. This allows even the most cutting-edge teams to ultimately be supported by the Cloud Platform Engineering team so that these Application teams can focus on adding new digital business value other than doing the undifferentiated heavy lifting of maintaining Platform capabilities.
Because building out an operating model can take considerable time and investment, it is recommended to channel the energy on more strategic and mission-critical optimize and grow workloads, and not on your legacy sustained workloads.
Cloud Managed Services, for example from AWS or from an AWS Partner, can be a valuable approach to help accelerate production-ready operations for the sustain workload portfolio allowing you to focus on building people and capabilities to support optimize and grow models longer-term.
The business’s desired outcomes may also impact how you decide to migrate your workloads to cloud.
6R’s framework defines different migration paths.
Rehost refers to moving your workloads as-is from your data center to AWS with minimal changes.
Replatform refers to moving components of a workloads architecture to AWS implementations. Examples would be moving an Oracle or SQL Server database to RDS versions, using Elastic Load Balancers instead of traditional Load Balancers, using Elastic File Service instead of SAN or NAS based implementation. The underlying architecture is intact but improved by AWS.
Repurchase refers to retiring the existing workload and either purchasing a new third-party solution through either packaged software or software-as-service.
Refactor refers to fundamentally re-architecting and rewriting the application to take advantage of more cloud-native services such as decomposing a legacy monolith into microservices that leverage AWS services such as Lambda, Dynamo DB, API Gateway, etc.
Retain refers to workloads that you may never move to AWS.
Retire refers to workloads that have reached the point where it no longer makes sense to maintain them on-premise or on a cloud.
Combining the three Cloud Operating Models with the 6R’s of Cloud Migration can help keep your migration strategy aligned with the outcomes that the Business wants to realize by migrating to cloud.
Sustain-Rehost-Traditional Operations model: Many organizations will migrate most of their workload using the rehost migration pattern and the traditional operations model. This is the fastest means of migrating. So, if an organization is looking to quickly exit a data center, this can be a strong starting point for the entire portfolio.
Optimize-Replatform/Repurchase-Distributed DevOps model: Replatforming is going to allow the business to continue to optimize in terms of resiliency, availability, security, scalability, and performance with minimal changes to its architecture. Repurchasing may allow them to reap these benefits without carrying the operational burdens associated with the existing solutions.
Grow-Refactor-Decentralized DevOps model: Some workloads may need to be refactored entirely to maximize the ability for their development teams to iterate quickly to test and learn to hypothesize, experiment and to use continuous delivery with A/B testing. This is the most invasive migration pattern but can be worth it for areas of high growth and differentiation. Decentralized DevOps would be the best fit at least initially for workloads using this migration pattern.
Pick the Cloud Migration & Cloud Operating Model that is strategic for your organization
The recommendation is, over time organizations should focus the energy on building operating models that support Optimize and Grow workloads. This means transitioning your Sustaining workloads either by retiring them, repurchasing them as SaaS-based solution or rearchitecting them to take advantage of one of the other operating model patterns.
We consider Optimize and Grow Operating Models to be strategic as they enable your teams and the organization to treat both Applications and Platform as Products-based Cloud Operating Models.
Continue to read:
A model that is designed to drive both customer-centric innovation as well as modernization. Amazon’s retail business is considered widely successful and the success is attributed to amazon.com being the most customer-centric company on the planet. Read the case study of amazon.com and how it has adopted the Product-based Operating Model.
The two platform components of the Product-based Operating Model are the Cloud Business Office and the Cloud Platform Engineering team. Together makes up the Cloud Enablement Engine for accelerated and sustained adoption of cloud.
Cloud Enablement Engine by AWS
People Model and Cloud Transformation by AWS
Target Cloud Operating Model by CloudReach