Cloud Enablement Engine: A Practical Guide

Cloud Enablement Engine: A

Practical Guide

Prescriptive Guidance for Establishing a Cloud Enablement

Engine

July 14, 2021

Notices

Customers are responsible for making their own independent assessment of the

information in this document. This document: (a) is for informational purposes only, (b)

represents current AWS product offerings and practices, which are subject to change

without notice, and (c) does not create any commitments or assurances from AWS and

its affiliates, suppliers or licensors. AWS products or services are provided “as is”

without warranties, representations, or conditions of any kind, whether express or

implied. The responsibilities and liabilities of AWS to its customers are controlled by

AWS agreements, and this document is not part of, nor does it modify, any agreement

between AWS and its customers.

Contents 
Introduction .......................................................................................................................... 1 
AWS CEE perspective on implementation ...................................................................... 1 
Build the team .................................................................................................................. 2 
Train and coach ................................................................................................................ 3 
Pilot projects ..................................................................................................................... 3 
Architect for the cloud ...................................................................................................... 4 
Operate in the cloud ......................................................................................................... 4 
Continuous improvement ................................................................................................. 4 
Getting started: Service offerings ........................................................................................ 5 
Core services.................................................................................................................... 5 
Additional services ........................................................................................................... 7 
Considerations ..................................................................................................................... 8 
Patterns for success ............................................................................................................ 8 
Executive leadership ........................................................................................................ 8 
Cloud Steering Committee ............................................................................................... 9 
Project Management Office (PMO) ................................................................................. 9 
Training ........................................................................................................................... 10 
Core CEE team dynamics .............................................................................................. 10 
Pragmatic and practical governance ............................................................................. 11 
Provide early value ......................................................................................................... 11 
Mandate AWS Well-Architected Reviews ..................................................................... 11 
Practice operations ........................................................................................................ 12 
Community of practice ................................................................................................... 12 
Anti-patterns – Actions to avoid ........................................................................................ 12 
Believe in build it and they will come ............................................................................. 12 
Underestimate the power of middle management ........................................................ 13 

Organizational and culture change ................................................................................ 13 
Mismatched guardrails ................................................................................................... 13 
Lack of or incomplete upskilling strategy ....................................................................... 14 
Cloud agnostic tool chains ............................................................................................. 14 
Build an ivory tower ........................................................................................................ 14 
Staffing the CEE with Enterprise Architects .................................................................. 14 
Personal credit card usage ............................................................................................ 14 
Keep the same processes and tools ............................................................................. 15 
Let the CEE become a blocker to cloud adoption ......................................................... 15 
Conclusion ......................................................................................................................... 15 
Contributors ....................................................................................................................... 16 
Document Revisions.......................................................................................................... 16 
Appendix A: Evolution of an Enterprise CEE.................................................................... 17 
Appendix B: The Amazon.com story ................................................................................ 17 
Appendix C: Two Pizza teams and Productization........................................................... 20 
Appendix D: Cloud Operating Model ................................................................................ 21 
Appendix E: Migration ....................................................................................................... 22 
AWS CSMatrix - Capability Assessment tool ................................................................ 22 
Migration Portfolio Assessment (MPA) for TCO and ROI ............................................. 22 
Experience Based Accelerators (EBA) .......................................................................... 22 
Appendix F: Prescriptive Guidance................................................................................... 23 
Appendix G: Operations KPIs ........................................................................................... 23 
 
   

Abstract

This paper is a practical playbook for defining, establishing, and implementing a Cloud

Enablement Engine (CEE). It collates and summarizes the lessons learned and anti-

patterns gathered from the CEE journeys successfully navigated at Amazon and other

large enterprise companies. Much has been written about the need to establish a CEE,

the benefits of moving to a productization mindset, and the business value of tribes,

guilds, and two-pizza teams. However, larger organizations are still struggling with a

CEE 30-60-90-day plan, and the essential components of the CEE during its first six

months in existence.

The prescriptive guidance in this document provides pragmatic and tactical advice for

establishing a Cloud Enablement Engine (CEE), also referred to as a Cloud Center of

Excellence (CCoE) or Cloud Enablement Team. This paper serves as a step-by-step

guide for the initial setup activities, and the top ten best practices that have been

extrapolated from working across a large number of customers.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Introduction

A key focus of the Cloud Enablement Engine (CEE) is transforming the information

technology (IT) organization from an on-premises operating model to a Cloud Operating

Model (COM). The transformation to COM and the charter of a CEE are highly

correlated and interconnected. During the nascent stage of the CEE, the focus of the

CEE is the infrastructure components of a COM. These components include the

operations, security and control, platform architecture and governance, and

infrastructure provisioning and configuration management functions. Amazon Web

Services (AWS) understands that enterprise (on-premises) operating models are based

on Information Technology Infrastructure Library (ITIL). The cloud transformation from

an on-premises operating model to a COM includes mapping ITIL to a cloud, agile, and

DevOps based capabilities and processes. ITIL 4.0 embraces DevOps, cloud, and agile.

First, the CEE must focus on the needs of business (line of business [LOB] and product

owners) and internal IT customers (development, operations, security, database, and

infrastructure teams). Establishing a CEE is not instantaneous or a single operation, it is

an iterative process. Organizational and cultural change takes leadership commitment

and time. Most customers begin with a landing zone, a lab environment, and three to

five re-hosted test applications, and scale out as they become more comfortable. The

first CEE results, in the form of production cloud adoption, can be achieved within three

months. To leverage the full benefits of cloud in terms of operations, management,

provisioning, and cloud native architectures, the process can take a year or more.

AWS CEE perspective on implementation

Philip Potloff, the Head of Enterprise Strategy at AWS, describes a CCoE (using the

traditional name of a CEE) in this Challenging Conventional Wisdom About How to Build

a Cloud Center of Excellence. “The CCoE is a multi-disciplinary team that is assembled

to implement the governance, best practices, training, and architecture needed for cloud

adoption in a manner that provides repeatable patterns for the larger enterprise to

follow”, says Philip. This blog post focuses on the instantiation and composition of the

initial team, advising the team be a combination of cross functional team members that

have not worked closely together, and a group of A-team players that have a long track

record of close collaboration and success.

The building out of a CEE starts with one person, a Cloud Sponsor – an executive that

is accountable by success of CEE. This sponsor ensures that the CEE key performance

indicators (KPIs) and objectives are directly aligned to company business goals.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

As explained in Appendix A: Evolution of an Enterprise CEE, the CEE evolves over time

to be less centralized, and the services offered in the decentralized structure is

assumed by the lines of business. details the organizational, process, tools, and

architecture change that Amazon.com undertook during its transformation to service

orientated architectures (SOA), microservices, freedom from monolithic relational

databases (Oracle), two-pizza teams, and product operating model.

Five activities are required to start building out a CEE:

• Build the team

• Train and coach

• Pilot projects

• Architect for the cloud

• Operate in the cloud

Continuous improvement is an additional activity that should be kept in mind and will

become paramount after the CEE has been functioning for a year or more.

Build the team

The first activity is defining the roles and responsibilities, and identifying team members

through staff structure maps. An aspect of mapping team and staff structure involves

mapping traditional roles to cloud roles. This scenario includes mapping architecture,

infrastructure, operations, security, business and IT alignment, project management,

data, and applications on-premises roles. The necessary skills and competencies to

successfully fill the positions are critical.

This document does not provide details on CEE roles and responsibilities,

and the mapping of on-premises to cloud roles. For more detailed

information on this topic, contact your local AWS Professional Services

Advisory team.

It is important to indicate the initial roles that are crucial to the success of the

instantiation of the CEE. The initial team member should be knowledgeable across

AWS services, networking, security, operations, application development, migrations,

databases, and infrastructure. They should be passionate about technology, but also

have business acumen, the ability to internally evangelize technology and the value of

the CEE, and have enough internal political capital to directly access and communicate

Amazon Web Services Cloud Enablement Engine: A Practical Guide

to line of business (LOB) leaders. Organizations typically limit the initial CEE to 3-5

people. This models the Amazon two-pizza team approach, and ensures an agile team

that is empowered to make quick decisions.

The first resources include:

1. Infrastructure and operations person (such as a cloud architect)

2. Security and networking or migration specialist (depending on the CEE initial

focus)

3. Cloud Platform Engineering (such as a scripting SME)

4. CEE leader that is hands-on and a respected member of the IT organization.

Part of building the team involves identifying the core services that will be offered, and

setting the team goals, metrics, and KPIs. At the initial creation of the team, less is

more. We recommend keeping the list of services offerings and capabilities offered to

under six in the first 2 to 6 months.

Train and coach

The second activity is training and coaching. This activity should be conducted before

activities three through five. The training and coaching activity involves building a cloud

web portal (e.g. wiki, web site, etc.), identifying training gaps (LNA – Learning Needs

Analysis), creating a training plan, internally training and/or identifying partners, rolling

out the training, and getting people involved by running workshops, hackathons,

immersion days, lunch and learns, etc. The CEE is not responsible for delivering all the

training. The CEE will work with the internal corporate training team to do the following:

• create the learning paths

• identify certification training vendors (for example, Linux Academy, A Cloud

Guru)

• deliver initial training

• train the trainers in the corporate training team

Pilot projects

The third activity is Pilot Projects and enables the CEE team to get hands-on

experience with AWS. The team will experiment and play with some selected pilot

projects using a lab environment. This approach gives the team the fastest ramp-up of

Amazon Web Services  Cloud Enablement Engine: A Practical Guide 
  4 
skills and ability to build out knowledge in-house. The CCE team will be trained on AWS 
Well-Architected, and become familiar with AWS reference architectures, AWS Quick 
Starts, and AWS Solutions. The goals are to increase agility, document lessons learned, 
and develop best practice policies.     
Architect for the cloud 
The fourth activity is architecting for the cloud and involves defining the AWS end state 
architecture for development, test, performance testing, QA, and production 
environments. The cloud identity access control policies are set, and the AWS account 
structure and IAM roles are defined. The billing and financial management processes 
are configured using AWS tagging and billing. Governance policies are set for access 
request, security, and usage, and service limits are set. AWS offers solutions for many 
of the deliverables of this activity such as AWS Landing Zone and AWS Control Tower.   
Operate in the cloud 
The fifth activity is operating in the cloud and focuses on how a company should 
operate in the cloud using the Cloud Operating Model (COM). For more information, see 
Building a Cloud Operating Model. 
Operation capabilities include the following: infrastructure as code, code repositories 
and version control, monitoring, alerting, notifications and reporting, escalation policies, 
financial tracking and auditing, service deployment policies, and examination of 
opportunities for DevOps practices. This activity often involves creating an Operation 
Readiness Review (ORR) document and process, focused on infrastructure, to ensure 
new workloads moved to AWS are production ready. For more details on Cloud 
Operating Models, see Appendix D: Cloud Operating Model. 
Continuous improvement 
The sixth activity is continuous improvement and includes regular project reviews and 
post mortems, keeping up-to-date with latest technologies and innovations, automating 
everything (NoOps), tracking costs, KPI reviews through a KPI portal, monthly review 
meetings, and continuous training. It also involves using machine learning (ML) for 
operations, provisioning, alerting, and management.  

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Getting started: Service offerings

The primary function of the CEE team is to provide an enterprise ready AWS platform

that is easily consumable by end-users. The cloud team is responsible for overall

security hardening of the platform, which includes defining standard AWS Identity and

Access Management (IAM) roles and policies, evaluating security, enabling AWS

services using IAM policies, and platform SSO/AD federation. In addition, the cloud

team is responsible for defining standard security groups (required backend systems),

company standard OS AMIs, and managing the following: accounts and account

strategy, billing and cost optimization, VPC builds, CI/CD toolchain (Jenkins, Ansible,

etc.), API platform, and application onboarding.

Core services

The CEE team should offer the following core services in the first six months after

becoming established.

FinOps

This service offers rigorous financial management processes for financial forecasting,

monitoring, reporting, optimization, and allocation. Evaluate architectural solutions for

cost efficiency in both architecture and infrastructure and recommend the most cost-

efficient solution. Continually optimize allocated vs. utilized cloud assets to maximize

utilization. Provide transparent reporting and forecasting through self-service

dashboards to internal customers and stakeholders to help them manage their budget

effectively. Analyze cloud invoices and allocate cost by internal customers and

stakeholders. Ensure that cloud cost is optimized to deliver maximum business value at

lowest possible cost by implementing the right financial controls.

Cloud Governance

This service refers to the decision-making processes, criteria, and policies involved in

the planning, architecture, acquisition, deployment, operation, and management of a

cloud computing capability. Cloud Governance covers a broad set of capabilities

including: setting Service Level Objectives, governance of AWS including account

strategy, security policies, account management, billing and cost controls (chargeback

and show back), setting and measuring metrics and KPIs, and workload compliance to

industry standards. The CEE team is responsible for updating, and implementing

policies and practices to support governance models required to enable the workloads

to be compliant with business operations (for example, PCI DSS, HIPAA, and

Amazon Web Services Cloud Enablement Engine: A Practical Guide

FedRAMP. The CEE will audit workloads from both a technical and a business

compliance perspective, and report the current status to the executives and the board.

Migrations

This service enables the CEE team to create the AWS migration strategy, define the

methodology, and develop and share migration best practices. This strategy includes

recommendations on migration tools, decisions on when to apply one of the “6-Res” to

an application (rehost, replace, rearchitect, re-platform, and re-engineer). The strategy

includes a portfolio assessment, architecture review, security review/strategy,

application migration planning, TCO analysis, application integration, deployment, and

on-going operations. The teams will use this experience as the foundation for best

practices and lessons learned focused on Migration, Modernization, and DC

Consolidation.

The CEE team should become familiar with the AWS Migration Portfolio Assessment

(MPA) tool, Experienced Based Accelerators (EBA) and Customer Success Matrix

(CSMatrix) framework (built and maintained by AWS Account Teams). The EBA is a

bank of interactive workshops that accelerates organizational change, portfolio

rationalization and application migrations to the cloud. AWS CSMatrix is a framework to

evaluate the current state of an organization's cloud capabilities with respect to six

perspectives. The Business, People, and Governance perspectives focus on business

capabilities and the Platform, Security, and Operations perspectives focus on technical

capabilities. For more information on the AWS MPA and CSMatrix, see Appendix E:

Migration.

Platform Configuration and Optimization

This service provides guidance to the company for the direction of the overall platform,

provisions initial AWS environments, creates golden-image AMIs, automates

infrastructure deployments through scripting, and optimizes the platform by deploying

reference architectures. Provisioning of the AWS environment includes the initial

account and billing structure, security, identity and assessment, logging, monitoring, and

network structure using AWS Landing Zones and AWS Control Tower. Provisioning

procedures help plan, implement, and maintain a stable technical infrastructure to

support the organization’s business processes. The CEE team will use the AWS Well-

Architected Framework to implement the latest AWS best practice advice and step-by-

step guidance to address any gaps and to drive architecture using data. The team will

continuously update reference architecture stacks and roadmaps based on business

priorities. The objective of platform architecture service is to build the most effective

Amazon Web Services Cloud Enablement Engine: A Practical Guide

architectural solutions for recurring architecture patterns and promote reuse with

appropriate customization required.

Operations

This service is offered for support, maintenance, monitoring, and incident management

of the cloud platform. The CEE supports integration of enterprise tools and assets with

cloud tools and assets. This service validates and orchestrates a business continuity

plan (BCP) and disaster recovery (DR) scenarios and works with cloud platform

engineering team to automate these scenarios. The team is responsible for establishing

how the support structure will work in the cloud, including working with existing

centralized support teams to establish the support model. The team also helps drive

automation and change to existing processes, such as automation to update change

records. The team also creates the initial application onboarding support, troubleshoots

issues, and helps drive crowd sourcing for addressing support issues.

Process and Organizational Change Management

Technology is just one component of a cloud transformation. People, process, and

organizational transformation are critical to a cloud transformation. Cloud drives

pervasive change, including automation, across many critical functions including

engineering, operations, security, compliance, finance, and more. The service also

creates opportunities to organize more efficiently by creating cross-functional DevOps

product teams. Change organization structure and relevant functions as appropriate to

take advantage of the efficiency that cloud use introduces.

This service drives change across the organization in a carefully orchestrated manner. It

assesses scope of change introduced by the cloud in various functions and works with

stakeholders to plan how the organization will roll out the changes across these

functions. It provides timely and targeted communication of change initiatives across the

organization as it undertakes them. The organization change management team goes

beyond the cloud technology initiatives to drive required changes to people and process

across the organization.

Additional services

The second phase of the CEE typically provides additional services such as DevOps

Engineering, Site Reliability Engineering (SRE), automated application deployment and

CI/CD tool chain specialist, Cloud Operational Readiness and Cloud Operational

Readiness Review (ORR) support, and pilot/proof-of-value support.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

A mature CEE should contain two distinct teams: Cloud Business Office (CBO) and

Cloud Platform Engineering (CPE). The CBO is focused on PMO, governance, process,

and organizational change management. It also aligns the solutions and best practices

delivered by the CPE team to the needs of the customers (Business, Development, and

Operations) and key stakeholders (Finance, HR, EA, and Security).

The CPE team provides the enterprise standards as self-service capabilities that enable

development teams to meet governance requirements while accelerating adoption.

They are the hands-on doers. In the initial creation of the CEE, there will be one CEE

organization.

Considerations

Establishing a CEE, identifying the correct resources, getting their time, identifying skill

gaps, filling those gaps, building a landing zone, creating services, training, and

integrating the CEE into your existing operations and accounting systems is a complex,

time consuming, and non-trivial exercise. It is usually iterative, typically starts small and

scales over time. Spending the time to build the correct foundation, processes,

experimenting, fixing, and training will accelerate the total process. Verifying that the

customers and senior managers have a clear understanding of the timeline and not

overcommitting are important. Define requirements, build, test, and review with key

stakeholders before committing to migration schedules or application go-live dates.

Patterns for success

Focus on these patterns for success in the first 90 to 100 days of CEE establishment.

Executive leadership

Executive leadership an essential prerequisite to secure the right level of organizational

support to establish a CEE. Create an Executive Steering Committee made up of C-

level executives. These executives are not part of CEE, but they serve as the North Star

for CEE. This team ensures that the CEE is creating value and aligned to corporate and

board level goals and objectives. The executive leadership provides guidance on course

correction and removes impediments.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Cloud Steering Committee

This steering committee helps to ensure progress, remove roadblocks, and help with

any critical decisions (that is, decisions around changing existing processes). The

steering committee should empower the cloud team to think differently and challenge

the status quo. At the beginning of the journey, when many of the critical decisions are

being made, the committee should meet on a weekly/biweekly basis. As the team and

processes mature, the cadence of the meetings can be reduced and eventually

eliminated.

Project Management Office (PMO)

The PMO typically consists of technical scrum masters/project managers that

coordinate work across all IT verticals, across the cloud team, and with application

teams. However, scrum and agile are the vision. Initially, the PMO communicates

executive updates, communications across all verticals, establishes cloud communities,

contributes to IT newsletters, coordinates lunch-n-learns, produces internal articles,

shares best practices, ensures technical/end-user documentation is in place, and

engages in issue resolution across all verticals.

A PMO office is critical to the long-term success, but should not be burdensome (over

engineer the communication and information sharing processes) when cloud usage is

low in the company. Communication is key when the CEE is in its infancy, and the goal

of the team should be communicate, communicate, and then communicate again. A

Cloud Manifesto or PR/FAQ are a great communication asset to start with, and has

been successfully used by AWS customers. The cloud manifesto includes the guiding

principles and tenets of the modernization and transformation to AWS. The manifesto

can be used to guide the decision making regarding the people transformation, process

changes, organizational change, cloud architecture, and cultural change. The Cloud

PMO can also make an impact facilitating and leading weekly cloud forum call.

Prescriptive guidance documents are another great mechanism for sharing best

practices and lessons learned in a specific domain such as hybrid cloud, application

modernization, and Operational Readiness. The Enterprise Transformation Community

of Practice has created prescriptive guidance documents discussing hybrid cloud on

AWS, application resiliency, migration acceleration, disaster recovery, and application

modernization. These documents can be used by customer CEEs and can be made

available to account teams with an NDA.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Training

The CEE team is responsible for collaborating with the internal training organization to

ensure the completion of training for corporate resources, CEE team members, and/or

core AWS resources. The CEE validates that the training requirements of the

organization cover all four spectrums of training and education: mass awareness,

certifications, custom workshops, and Just in Time (JIT) training. AWS 100 and 200

level webinars and lunch-and-learns can bring awareness of AWS and cloud concepts

to a majority of the company. A few examples can be found on the AWS Online Tech

Talks site.

AWS Solution Architect Associate and Professional certification training creates a

foundation of AWS knowledge, and is an important outcome to build strong delivery,

implementation, and managed services capability within the CEE and IT organizations.

Custom workshops for migrations, security, networking, AWS architecture

fundamentals, and operating AWS are all key foundational training opportunities. The

CEE members are the mentors, champions, and key enablers of AWS and cloud

awareness and knowledge. In addition to training the technical resources across the

company, training the executives is critical. Executives that are part of the steering

committee, in particular, need to understand cloud capabilities, services, processes,

tools, and methodologies so that they can provide effective support and guidance.

Core CEE team dynamics

CEEs are typically staffed by a team of open-minded change agents, tasked with

initiating and implementing a fundamental shift in how the organization functions. The

team comprises specialists across the spectrum of IT roles including networking,

security, database, application development, operations, and program

management. The individuals in the CEE are hands on, big picture thinkers who are

ready to lead business transformation by using cloud services, tools, and technologies.

CEE resources are typically structured from an organizational perspective into one of

the following configurations:

• centralized model, where one team reports into one leader

• decentralized model, where the team is embedded in the lines of business and

has a dotted line to the IT organization,

• federated model, where the organization shares characteristics of the centralized

and decentralized models

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Pragmatic and practical governance

Day one involves establishment of a tagging strategy. Next, establish and standardize

cost optimization through show back/chargeback, standardize cost management,

identify and measure metrics and KPIs (example incident response operation KPIs can

be found in Appendix G: Operations KPIs), and implement optimization tools such as

AWS Trusted Advisor, and partner solutions, such as CloudHealth, CloudCheckr, and

Cloudability.

Other initial governance tasks include:

• Identifying and documenting compliance through configuration management

• Managing software licenses

• Managing AWS accounts and billing

• Defining IAM policies

• Implementing processes for how to handle service limit increases across

accounts (service limit incidences can account for over 50% of support

incidences in customers new to AWS)

Provide early value

Demonstrate early value by delivering three to five small applications (Drupal, LAMP, or

AWS supported ISV SaaS application), delivering lift-and-shift migrations to AWS that

reduce run time and operational costs, or developing and delivering an infrastructure-

as-code system for AWS. The CEE must deliver two to three tangible results that drive

business value and outcomes in the first 90 days. Early value can also be demonstrated

through certifying a certain number of resources on AWS, or creating a FinOps model.

Gamification of these early accomplishments can help you drive success.

Mandate AWS Well-Architected Reviews

AWS Well-Architected Reviews should be mandatory for all applications running on

AWS. Well-Architected Reviews can be executed for on-premises workloads as well. In

fact, over 7000 (10% of all reviews) have been completed on on-premises workloads.

Performing these reviews on applications before they are moved to AWS can prepare

these applications and corresponding workloads for migration or modernization to AWS.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Practice operations

Use events such as AWS GameDay to practice incident response. AWS GameDay is

workshop that immerses teams into a fictitious scenario where they are challenged to

build and maintain highly available and highly scalable solutions. Netflix Chaos Monkey

is an open source tool that was inspired by AWS GameDay and is aimed at training

developers and operations resources in the management of production incidents.

Community of practice

In conjunction with the development of a CEE, AWS has observed that developing a

Community of Practice (CoP) is beneficial. The CoP identifies and shares best practices

and supports upskilling and crowdsourcing efforts. These efforts are helpful to evolve

the culture and federate expertise across different business units, teams, and roles.

These communities of practice provide safe zones where peers can help each other,

and share real-world issues. Sometimes, organizations that have not established CoPs

have had their adoption efforts stalled as the number of teams needing support exceeds

the capacity of the CEE. The CoP enables community members to help each other,

reducing the workload on the CEE. The CoP is analogous to a Guild in the Spotify

implementation of DevOps. Amazon and AWS have Technical Field/Feedback

Communities (TFCs).

Anti-patterns – Actions to avoid

These anti-patterns are focused on actions, strategies, and approaches taken by

enterprise CEEs that can have negatives consequences on the success of a CEE.

Believe in build it and they will come

The consumers of cloud are the customer. In the case of a CEE, the consumers of the

cloud are the line-of-business owners, product owners, finance, marketing, and the IT

teams; infrastructure, operations, application development, security, and database.

Understand their needs and provide the services and tools that support those needs.

The CEE needs to ensure CEE backlog is driven by the internal customer’s clearly

defined needs and requirements. Building the perfect AWS landing zone does not

ensure lines-of-business will move to the cloud. Developing a sophisticated cloud

monitoring platform does not mean lines-of-business nor operations will embrace this

new concept. For example, a global manufacturing company developed an AWS

monitoring platform. The CEE team went to roll out this platform and discovered that

Amazon Web Services Cloud Enablement Engine: A Practical Guide

one of the lines-of-business had developed their own monitoring platform that was

similar. The line-of-business, of course, chose to continue using the platform they

developed.

Underestimate the power of middle management

More so than talent mismatch, we have seen that the biggest blocker to change, and

therefore cloud adoption is buy-in from leaders one level down from executives. With

the previous global manufacturing company example, this company struggled for almost

three years to fully migrate to AWS (beyond the innovation group). Once they were able

to achieve cloud adoption across the company, they were able to successfully migrate

to AWS. Keep in mind that many decisions during a cloud transformation are (including

what to migrate first) made because of political reasons, not business outcomes or the

right technology.

Organizational and culture change

Although, organizational change doesn’t happen overnight and is one of the forced

multipliers of Amazon innovation formula (Charlie Bell; formula for innovation), many

cloud modernization, digital transformation, and cloud transformation efforts fail or stall

because a company attempts to change an organization, or move to DevOps, Agile, or

two pizza teams. The reality is organizational change is difficult and disruptive, and

cultural change (culture is essentially the unwritten, inexplicable way people make

decisions, interact with each other, and interface with partners and customers) isn’t in

the short term. The success of technology and process change influences

organizational and cultural change. Do not change your organizational structure without

launching cloud projects. For example, implement a CI/CD pipeline. This change will

force changes to tooling, architecture and technology, and processes, which will force

organizational structure and culture to change. It took Amazon over 10+ years to fully

change organizational structure and architecture/technology to move to cloud. Amazon

did not have as much legacy technical debt, had a defined culture of innovation

(leadership principles, two-way and one-way doors, etc.), and was only a 6+ years old

company when it started.

Mismatched guardrails

Mismatched guardrails refers to building too much security for workloads that don’t need

it; or, conversely, not building any. The guardrails should be appropriate for the portfolio

at the time. That said, there are minimal guardrails that must be established at the

beginning and are difficult to redo (one-way door).

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Lack of or incomplete upskilling strategy

Common anti-patterns can range from: Customers training everyone but don’t have a

plan to provide these individuals with hands on experience which leads to illusion of

expertise; Nobody is trained, so those that know get overwhelmed or frustrated with the

many that don’t; No formal way to share best practices. Connecting experts with

newbies via meetups, summits, and communities of practice is a way to slowly increase

the skill of the employees.

Cloud agnostic tool chains

In terms of actual implementation, enterprise customers have few actual production

systems that provide cloud brokerage, management, provisioning, and operations

across multi-clouds. Enterprises can spend an inordinate amount of time on CEE tools,

technologies, and processes that are cloud agnostic before getting one public cloud

implementation right. For example, a customer may iterate over various vendor

solutions that provided cloud portability for CI/CD, operations, and management space

and then finally decide to go on AWS first.

Build an ivory tower

The CEE should not be staffed with thought leaders and thinkers only. The CEE team

members should be builders with hands-on skills. All members of CEE team should

have direct access to their customers, listen to their needs and build CEE’s backlog

based on business requirements.

Staffing the CEE with Enterprise Architects

Correlated to point six, consider the amount of Enterprise Architects that are involved in

the cloud initiative. Studies have been done that show an inverse relationship between

the number of Enterprise Architects on a cloud initiative and the success of the cloud

initiative. Think of the “too many cooks in a kitchen” phrase.

Personal credit card usage

Personal credit card usage to create test, pilot, or development accounts create

irrevocable challenges in terms, of cost control, cost reduction, potential loss of

intellectual property (IP), or even loss of service. This is both a cost and an IP issue.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Keep the same processes and tools

Developers, operations, system administrators, application developers, and DBAs are

interested in keeping the same tools. Project managers, auditors, risk and compliance,

and governance teams desire to keep the same processes in place. It is the role of the

CEE to educate these individuals that without process change and new tooling, the full

benefit of the cloud cannot be realized, such as new pricing models, on-demand

compute, ephemeral and immutable architectures, agility, flexibility, and global

expansion. Part of this education is mapping current ITIL-based processes to new cloud

friendly capabilities and processes. The argument made for keeping the identical tools

and processes is that AWS, is just another co-lo facility. This perception will stifle the

process, cultural, and organizational change that will an enable a transformation from

an on-premises operating model to a COM.

Let the CEE become a blocker to cloud adoption

A CEE is intended to be an enabler of cloud adoption. However, if the CEE does not

produce results, retains the same on-premises operating model processes, or becomes

the single point of validation for all AWS deployments, the CEE will be perceived as an

impediment to cloud adoption.

Conclusion

A minimal viable product (MVP) approach should be taken to building the CEE team,

and its offerings. Although a fully automated infrastructure and application deployment

using CI/CD supported by DevOps engineers may be the ultimate objective, the CEE

needs to first establish a foundation architecture with the appropriate security, logging

and monitoring, AWS service tagging, infrastructure as code, and a resilient network in

place. The CEE needs to put guard rails in place for the operations of the AWS

environment, and establish and govern the metrics and KPIs used to ensure operational

excellence. The service level objectives (SLO) and service level indicators (SLIs) will

enable the portfolio companies to measure success, and establish a baseline for

continuous improvement. The CEE will learn, iterate, and provide more capabilities.

There is no compression algorithm for experience.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Contributors

Contributors to this document include:

• Tom Laszewski, Americas Private Equity Enterprise Technologist, AWS

• Andrei Savine, WW Enterprise Transformation Architect, AWS

Document Revisions

Date

Description

July 2021

Revisions for clarity.

August 2020

First publication

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Appendix A: Evolution of an Enterprise CEE

Amazon Web Services (AWS) has observed two high level approaches to a CEE –

prescriptive and advising.

In the prescriptive approach, the CEE directly oversees or implements all cloud projects.

Engaging with the CEE early in project implementation is a mandatory step for the

business unit or line of business. A common use case for when this approach is taken is

when an enterprise is undergoing a mass migration to AWS driven by data center

closure or an all-in strategy. A prescriptive CEE is usually temporary (1 to 3 years) and

provides a residence for cloud expertise until wider adoption is reached. This approach

is implemented by companies that start their cloud journeys.

In the advising approach, the CEE team members serve as internal SMEs for cloud

projects. This type of CEE performs an advising function, advising on architecture,

services available, and best practices. They provide standards, along with secure, and

repeatable solutions for teams to consume so they can be self-sufficient. The advisory

CEE accelerates cloud application projects implementation, but is not responsible for

implementing them. The primary use cases are new projects and application migrations

to AWS driven by business case or a tech refresh (cost avoidance) strategy. The

advisory approach is used by advanced cloud companies, such as Amazon.com.

Customers frequently begin with the prescriptive approach and move to an advising

approach as the adoption of cloud scales across an enterprise. This metamorphosis

from prescriptive to advising fits well with the evolution of enterprise IT from traditional

operations to the future-state of IT operating models (cloud operating models) that AWS

is adopting.

Appendix B: The Amazon.com story

In 2001, Amazon.com was a monolithic application with monolithic teams. The

monolithic application was written in Perl using an Oracle database as persistent

storage. The application contained all display, business, and database logic across all

business functionality. This included all the logic and functionality that Amazon

eventually became famous for: one-click ordering, similarities, and recommendations.

The first big milestone was the release across all of Amazon.com of a deployment

service called Apollo. This service become AWS CodeDeploy. In 2009, Amazon.com

conducted an internal study to find out where inefficiencies might still exist. What they

found was that many teams were still being slowed down by manual processes and

Amazon Web Services Cloud Enablement Engine: A Practical Guide

work flows. This was the reason around the Amazon development of a code pipeline

tool; this tool was the foundation for AWS CodePipeline. During the cultural,

organizational, technology, and process journey from 2001 to 2009, Amazon.com

moved from projects, centralized IT, and ITIL-based processes to productization, two

pizza teams, and implemented tools such as Apollo and code pipeline. The outcome

was the ability for Amazon.com to achieve 50 million deployments a year in 2016.

Werner Vogels discusses aspects of the Amazon.com business and technology

transformation in A Conversation with Werner Vogels: Learning from the Amazon

technology platform. Amazon.com migrated to Amazon Elastic Compute Cloud

(Amazon EC2) (lift and shift style) in 2012. On October 15, 2019 Amazon.com turned off

its final Oracle database, having migrated to open source relational databases: NoSQL

(Amazon DynamoDB), Amazon EMR, Amazon Redshift, and Amazon Simple Storage

Service (Amazon S3). Traditionally, the relational database has been the database

option for all data persistence use cases. The new world model is to use the database

that best supports the use case.

The guiding principles of the Amazon.com transformation were:

• design for failure (everything fails all the time)

• centralized monitoring and management

• automation is not a phase

• continuous improvement

• SSH into servers not allowed

• support agile SDLC

• promote best practices without being restrictive (guardrails)

• decentralized ownership (self-service)

• continually looking for horizontal concepts

Seven technology areas that the effort focused on were:

• APIs

• microservices management

• continuous integration/delivery

• technology agnostic

Amazon Web Services Cloud Enablement Engine: A Practical Guide

• infrastructure as code

• monitoring/metrics/logging/APM

• communication and collaboration (ChatOps)

The lessons learned were:

• shared culture matters as much as tools, technologies, process, and strategy.

• Teams need to be highly autonomous product-based.

• Products not projects.

• This organizational structure drives ownership.

• The product teams share toolchains; the best tools become the de facto

standard.

• There is no center of excellence, it is everywhere.

• A focus on cloud platform engineering, not a centralized CEE, is the best long-

term approach.

Another lesson Amazon learned during the transformation is that it’s not only the

technology aspect that was improved by using products accessed by APIs and

migrating to cloud. The development and operational process benefited from APIs,

CI/CD, and DevOps. The product model was a key enabler in creating innovate

solutions quickly with a strong customer focus. Each product team is completely

responsible for the product, from scoping out the functionality, to architecting it, to

building it, and operating it. Governance is achieved with thorough onboarding/training,

regular technical and business metrics reviews, regular sharing of new tools, services,

technologies, public sharing of correction of errors (COEs), and configuration

management and provisioning (CI/CD).

The implementation of AWS Identity and Access Management (IAM) utilizes managing

permissions in a centralized fashion at the API level and as an internal identity broker

service. Automation is achieved using automated deployment (AWS CodeDeploy),

continuous delivery (AWS CodePipeline), and infrastructure as code (AWS

CloudFormation). Continuous monitoring is implemented using Amazon CloudWatch,

alerting on business workflow in addition to on CPU or low-level infrastructure metrics,

monitoring web services (metrics on services), and AWS X-Ray (end to end monitoring).

Continuous improvement is achieved with narratives, PR/FAQs for new features,

products, business process improvements, new initiatives, and other ideas,

improvement Ninjas (centralized team that analyze current processes and makes

Amazon Web Services Cloud Enablement Engine: A Practical Guide

recommendations for improvement), COEs (Amazon mechanism where anyone can

raise a concern about a process or product), AWS – PFR (customers can submit

product feature requests), and an APIs first mentality. The user interface can be

continuously improved if it accessed via an API. The console can be continuously

improved if it is written using an open, REST-based API.

Appendix C: Two Pizza teams and

Productization

Amazon and Amazon Web Services (AWS) utilize a product mindset to ensure great

customer experiences. A product in this context is defined by: performing a constrained

number of common tasks very well; having clearly defined inputs and outputs; being

useful to multiple customers; and continuously improving to meet the needs of those

customers. For example, Amazon.com uses multiple product teams to run their

customer website. Product definition is important as it's the interrelationship between

products, the customers that use the products (consumers), and the teams that create

the products (suppliers). These interdependent relationships highlight where product

teams are both consumers and suppliers. This interdependency requires an additional

level of ownership, accountability, and scrutiny so that each team is incented to provide

higher quality products and services.

When organizations do not effectively define and operate their systems as products,

they often experience foundational failures that cross-product accountability would

inherently handle or avoid. With each product team fully functional from business to

operations, they are wholly accountable for all aspects of their services. Even shared

service providers are product owners and offer a service that other product teams can

choose to use (although, the products should be in demand or we should question their

existence). Regardless, the core outcome is the same. The product team owns

accountability and does not surrender this responsibility to any other product supplier.

Finally, owning the operation of a product all the way to the end customer

(internal/external) cultivates empathy with the customer's perspective. As product

owners choose to enter into contracts with other product owners, a supplier/consumer

relationship is created and trust is developed. Empowering product teams to make their

own choices on how they solve problems and which other products they use enables

the full and complete accountability for the product and how it is perceived by their

customers.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Appendix D: Cloud Operating Model

AWS Professional Services Advisory defines a Cloud Operating Model as the alignment

of IT and Business objectives through the formation of cross-functional empowered

Product Teams that are customer obsessed; able to iterate and deliver value quickly;

and optimize benefits from the Cloud. It is a best-practice prescriptive solution that

transforms the way technology and business relationships work. There are 17 key

operational domains of the cloud operating model:

• Strategy & Change

• Organization Design

• CBO: Platform Architecture & Governance

• CBO: Operational Reporting

• CBO: Vendor Management

• CBO: Product Management

• CBO: Financial Management

• CBO: Training & Onboarding

• Resource/Estate Management

• CPE: Provisioning & Configuration Management

• CPE: Availability & Continuity Management

• CPE: Capacity Management

• CPE: Lifecycle Management

• CPE: Core IT Processes

• CPE: Operational Health

• CPE: Security Management

• Data & Analytics

For more information, see Building a Cloud Operating Model

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Appendix E: Migration

AWS CSMatrix - Capability Assessment tool

The CSMatrix is a questionnaire to determine the current state of company’s

IT/engineering capabilities in terms of business, governance, people, security,

operations, and platform. This matrix is based on the AWS Cloud Adoption Framework

(AWS CAF).

CSMatrix consists of 192 questions equally divided among the six CAF business and

technical perspectives. Each question is assigned a rating from one to five that maps to

the cloud stages of adoption - project, foundation, acceleration and migration, optimize

and reinvention, and disrupt. A report including highlights and observations, CSMatrix

radar chart, key takeaways, a functional rating (one to five) with recommendations to

increase the rating across each of the six CAF perspectives is generated from the

assessment.

Migration Portfolio Assessment (MPA) for TCO and

ROI

The Migration Portfolio Assessment (MPA) tool is a migration cost and TCO tool. The

tool is based upon actually customer migrations, empirical customer data points, and

industry averages and assumptions. The tool generates reports for TCO (AWS run time

costs) analysis and ROI (cost savings - migration costs) report. The estimated time to

completion of the migration in months with the estimated number of resources is

generated. The tool also provides the migration person hours, including the migration

costs for AWS, customer resources, and a certified AWS migration partner.

The online tool can be run by AWS resources or AWS Partners participants.

For online APN training on Cloud Economics, see AWS Partner: Cloud Economics

Accreditation. This training requires you to be logged into APN prior to starting.

Experience Based Accelerators (EBA)

Through completing thousands of applications migrations, AWS has learned that there

is no substitute for hands on experience, repeatable pattern design and teamwork in the

early stages of cloud transformation. Both application teams and business organizations

find comfort in knowing they aren’t the first to experience large scale changes of people,

Amazon Web Services Cloud Enablement Engine: A Practical Guide

process and technology. As a result, AWS has developed the Experience Based

Acceleration program (EBA). The EBA was designed based on experience gained

through thousands of migrations and hundreds of customer transformations. During the

EBA, AWS brings experienced talent and methodology to work with and train customer

resources to develop the best possible migration scenarios based on individual

customer requirements. The EBA workshop is 4-5 days with preparations starting 3-4

weeks prior to the workshop.

Appendix F: Prescriptive Guidance

CEE created guidance, scoped to a specific technology or transformation topic. For

example, guidance for how to approach a hybrid solution with their existing on-premises

applications and assets, or how to effectively leverage the AWS Cloud in a disaster

recovery strategy. Points of View have been created by the Americas Enterprise

Technologist team that can be shared with partners and customer under NDA on

demand:

• Application Resiliency and Productization

• Hybrid Cloud

• Disaster Recovery (Business Continuity)

• Migration at speed

• Monolithic to microservices decision tree

Appendix G: Operations KPIs

Business value becomes an organization wide imperative when it creates organization

wide visibility of metrics that measure the business value. Metrics make business value

real, immediate, and important. C-level leaders typically build a benefits realization

workstream utilizing a Value Score card that measures key metrics relevant to their

business objectives (M&A, New Markets, Operational Efficiency, Competitive

Advantage). Therefore, it is important for the CEE to identify, measure, and report on

key performance indicators (KPIs) based upon the services being offered. It is advised

to start with no more than 10 metrics for each service. As metrics continue to turn

green, they can be deprioritized, and new metrics can be added based on prioritized

business objectives. The CEE should establish dashboards that report important

metrics, and make them available to employees as appropriate.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Align with Needs of Internal Customers

• Number of Target Teams Engaged: Number of features in product backlog

above watermark.

• Percentage of Target Teams Engaged: Number of target teams engaged / total

number of target teams.

• Percentage of Features Originating from Customers or Stakeholders:

Number of features in the product backlog from customers or stakeholders, and

total number of features.

Improve Cloud Literacy and Fluency

• Cloud Literacy in Target Teams: Percentage of employees with cloud literacy

in the target teams.

• Cloud Certification in Target Teams: Percentage of employees with cloud

certification in the target teams.

Build Effective Reusable Solutions

• Number of Solutions Available

• Number of Times Solutions Reused

• Times Solutions Are Reused: Number of times solutions Are reused / total

number of times requests received

Accelerate Customer Onboarding

• Time to Onboard Team: The time it takes to onboard a team with appropriate

credentials and provide required access

• Time to Provision Solution for Team

• Time to Train Team on Solution

• Number of Applications in Dev/Test

• Number of Applications in Production

• Number of Applications Migrated

• Number of Cloud Native Apps

Amazon Web Services Cloud Enablement Engine: A Practical Guide

Improve Effectiveness of Applications Team

• Deployment Frequency: Number of times software is deployed to production

during a time period

• Deployment Time: Time taken to deploy software to production after it’s

committed to version control

• Change Volume: Average volume of change in a deployment

• Deployment Failure: Number of times deployment leads to unexpected outages

or unplanned failures

• Mean Time to Detection: Average time to detect failure after a deployment

• Mean Time Between Failures: Average time between failures

• Mean Time to Recovery: Average time to recover from failures

Improve Security and Compliance

• Security Controls Implemented: Number of security controls in place

• Compliance Controls Implemented: Number of compliance controls in place

• Security Controls Automated: Number of security controls automated

• Compliance Controls Automated: Number of compliance controls automated

• Percentage of Security Controls Automated

• Percentage of Compliance Controls Automated

Operations

Incident Management Metrics

Incident Management (IM) is a critical service and the IM service can usually be broken

down into several sub-components:

• Service Desk

o Metrics: Time to answer call, time to create ticket, number of calls matched

against known error database.

• Log Generation

o Metrics: Number of production incidents with logs available, number

production systems recording logs, age of available records.

Amazon Web Services Cloud Enablement Engine: A Practical Guide

• Event Capture and alerting

o Number false positives, number false Negatives, number events raised via

alert vs manual, time taken to create tickets from automation alerts, uptime

of central incident API, average number of Sev 1/2/3 incidents in prior

month.

• Incident Triage and Classification

o Number production applications with agreed upon triage plan, number

incidents over/under classified, number of assigned resolver groups

unavailable, average time taken for resolver groups to respond.

• Incident Workflow

o RTO compliance, average time taken to close Sev 1/2/3 incidents.

• Critical Incident Management

o Number critical incidents, average resolution time for critical incidents,

number hours production business applications uptime lost during critical

outages.

• User Communications

o Number Incidents with communications released, average time to notify

affected users, time to release critical post-incident analysis.

Automation Metrics

• Percentage of operations activities automated in target functions

• Percentage of operations activities automated vs delivered manually in target

functions