“The hardest thing about getting started is getting started.” —  Guy Kawasaki

Executives are under increasing pressure to deliver Cloud transformation results quickly. Getting fully setup for success should not stop you from getting going, that said, understanding lessons learned from those who have gone before, saves time and money.

As an enterprise strategist for Amazon Web Services, I currently travel around the globe helping the largest companies in the world discover and unlock the power of AWS Cloud. Having lived the journey to cloud and worked with countless customers, executives are always keen to understand what journey lessons they can learn from those who have gone before.

With the benefit of hindsight here are 12 steps to get going when starting, that consistently deliver results : –

Step 1 — Don’t Over-Think It; Assign a Developer and start!

Just start. Focus on developing the skills and then delivering. All the help you’ll need is available. And all the answers to your questions have already been written. Start with one forward thinking Engineer or Developer and have them start using AWS through the Console, get to know the services and spin up an EC2 test instance. From my own journey we started with a very small team of forward leaning Engineers, the early lessons they harvested, compounded and continually informed our journey.

Step 2 — Empower a Single-Threaded Leader

In my experience, it can be fatal if you don’t have the support of a single-threaded executive leader during the transition. This leadership function simply can’t be delegated. The CIO, or, at the very least, a direct report of the CIO has to lead this effort and be visible each and every day to provide direction and remove roadblocks. And ensure inclusive executive alignment and air cover across the leadership spectrum to reinforce the profound benefits of moving to the public cloud across the spectrums of cost, security, and speed of product development speed.

Put another way, the single-threaded leader must be a rallying point for all change curves. They must listen well and bring a “can-do” attitude to the cloud transition. When I was acting in this capacity at Capital One UK, I used the tenet “All of your assumed constraints are debatable” this served as a forcing function so people looked at each perceived problem as an opportunity instead. Finally, the single-threaded leader must be responsible for establishing Step 3, which is crucial.

Step 3 — Create Your 2-Pizza Cloud Business Office

Amazon’s 2-pizza team concept means a team of around 8–10 people. And, in this case, I’m referring to the virtual leadership team, which needs to provide strategic oversight and tactical air cover for engineers and developers as you move to the public cloud. It’s essential that this cloud leadership team takes into account — and addresses — everybody’s fear (of the unknown).

The best Cloud Business Office teams include —

CIO or Direct Report with Single Threaded Ownership
Procurement or Vendor Management
Legal Lead
Chief Information Security Officer
Chief Financial Officer or Direct Report
Head of Infrastructure
Head of Delivery
Engineering or Product Manager of the first Cloud Engineering Team
Risk Leader (needed in most organizations, but especially regulated ones)
Audit Leader (needed in most organizations, but especially regulated ones)

These folks need to follow the Agile cadence established in your organization and meet at least weekly (if not daily), to review progress and remove roadblocks.

Step 4 — Establish Your Tenets (And Be Prepared to Amend Them as You Go)

Tenet — “a principle, belief, or doctrine generally held to be true; especially: one held in common by members of an organization, movement, or profession.” Common Tenets provide a common frame of reference for everyone to understand the ‘how’ questions that can arise. When creating them, seek feedback from a wide source, but strive for a small but powerful list. I’ve written and read a lot of cloud tenets over the past year; here are some of the best and things you should consider when creating yours:-

• Be Clear on your Business Goal — Are you reducing cost? Transforming to digital native? Reducing your app footprint? Or closing your data center? It’s challenging to do all this at the same time, so my advice is to go cloud first for all new, lift and shift the old, and then optimize and eliminate apps. Stephen Orban, the Global Head of Enterprise Strategy at AWS, has written a series of posts on this topic, which are well worth reading.
• Choose a Predominant Public Cloud Partner — This provides focus for your organization to get to an expert level with a predominant platform, avoiding the distractions that come with too many platforms, across people, process, and technology paradigms.
• Agree on Your Security Objectives. I recommend reading these excellent white papers and getting advice on this from AWS ProServe and working backwards from your regulators’ compliance bar, this enables wide adoption as engineers and developers will understand the ‘Why’ things need to be a certain way.
• Remember That the Team You Have Is the Team You Need. Recruiting new takes a very long time, so invest in the people in your organization. Training, hands-on management, and certification will make a significant difference.
• You Build It, You Support It — small 2 pizza teams that own what they build can be transformational for a business. Its one of the mechanisms Amazon uses to scale and innovate.
• Command and Control or Trust, But Verify approaches for your Engineers and Developers. Both have pros and cons, see step 12 for more.

Step 5 — Create Your Questions Parking Lot

The leadership team (everyone) will have lots of questions. Unfortunately, many hours will be wasted trying to answer them without the right folks in the room, and your progress could stall. Create a parking lot for these questions, and be sure to respect every single question on the list as you keep moving forward.

Top Tip — The very best way to answer a lot of questions quickly is to arrange an executive briefing centre session with AWS. These sessions, which are always fascinating, enlightening, and exciting, can be best held in Seattle or can potentially be arranged for the country where you are based. Speak to your account manager to arrange a session, and we’ll work with you to answer all your questions or ping me.

Step 6 — Create Your 2-Pizza Cloud Engineering Team

Creating your holistic cloud engineering team, which will be hands-on with the AWS cloud, is critical. The word holistic is very important here. This team must comprise a cross-section of multiple skills types, including —

· Infrastructure Engineers, who understand the existing IP addresses, boundary security (firewalls), routing, server build standards, and a whole host of things in between.

· Security Engineers, who will ensure that everything is built and coded to meet your company’s security objectives.

· Application Engineers, who will ensure that the coding logic of the product you’re building gets built.

· Operations Engineers, who will ensure that your ITIL elements can be adapted to benefit from the cloud.

· A Lead Architect, who has deep and broad domain experience. Ideally, this person will also have experience with infrastructure as code. A solid understanding of how to use AWS services and features in an optimal way will also greatly accelerate your cloud journey. This cloud engineering team should work together in one physical group. Remote working, while possible, isn’t optimal. And the team must be fully dedicated to your organization’s cloud journey, side of the desk just won’t work.

Step 7 — Bring in a Partner or AWS ProServe

The cloud engineering team will probably have valid opinions in terms of best approaches and best tools. And it will probably have strong feelings about which practices to keep from your data center and which to discard. To accelerate this process, bring in some experts who have been there and done it before.

Step 8 — Work Backwards From Your Security, Compliance and Availability Objectives

First and foremost, the AWS cloud is secure. Taking time to ensure that the Cloud Engineering Team and the Cloud Business Office understand the AWS Shared Responsibility Model is a crucial priority though. (Illustration below) Then, work with your AWS Solutions Architecture/ProServe resource to ensure that you’re using the Deep Security tools appropriately to meet your security objectives. There are a number of different configuration possibilities available, but my advice is to work backwards from your company’s external regulatory bar (PCIDSS, HIPAA) etc. You should also work with AWS to ensure that you’ve adopted the best practices that meet your compliance and security objectives. Once you agree on these, write them down, publish them, and make sure there’s a direct channel to the leadership team and single-threaded leader so people can cordially challenge them if they want.

Step 9 — Ship Something to Production That Is Important, But Not Critical

You need to get something that’s meaningful into production. When I was doing this at Capital One, getting the first micro service live was the team’s goal. Don’t set a deadline; instead, set a Minimum Viable Product (MVP) and have the Cloud Engineering Team stay focused on the product. Experience has shown that shipping something live in this way can take anywhere from a couple of days to 12 weeks. If it’s taking longer than 12 weeks, one of the earlier steps isn’t working, so have a retrospective and utilize the 5 Why’s to understand why.

Step 10 — Train, Gain Experience, and Certify Your Teams

The key role of the CCoE is to ensure that the people journey for everyone is managed positively and proactively. It’s also crucially important that you put in place the right training and certification programs to enable scaling. I cover this comprehensively here.

Step 11 — Start Migrating — “Plans Are Worthless, But Planning Is Everything” — Dwight D. Eisenhower

Once you have multiple teams you can really start thinking about migrating. And, as teams realize how easy it is to build on AWS, building new on Cloud becomes the default. But what about all the incumbent systems that still require a staggering amount of 24x7x365 maintenance and upgrades? This is a good place for the Cloud Business Office to work with AWS on using the AWS Migration Acceleration Program (MAP) which has been shaped by all the customers who have migrated to AWS. To shape your migration journey, use the 6 R’s, which is a simple looking, yet comprehensive decision guide on how best to migrate your apps. In its simplest guise, using 6 colours of Sticky Notes I have worked with leaders in a day, and have got to an 80% Straw Man Proposal that can help towards generating a Directional Business Case for MAP. The best programmes are continually planning to make the maximum use of Re-Host, some Re-Platforming and a little Re-Architecting to get there quickly alongside a MAP Partner.

Step 12 — Trust, But Verify

Finally, the question that many larger enterprises come back to time and time again is “How do I balance control (especially security) and innovation?” It’s a tough question to definitively answer. At Capital One, Cloud Custodian allows administrators and users to easily define policy rules for a well-managed cloud infrastructure that’s both secure and cost-optimized worked incredibly well. My good friend and ex-Capital One colleague Kapil Thangavelu talks here on the this great Open Source project for which he is the Product Manager. It was fascinating to hear 3M talk at re:invent 2017 about how they are leveraging the Cloud Custodian tool to help them with their Governance and get their setup just right.

Remember — “All of your assumed constraints are debatable.”

Jonathan Allen
@jonathanallen02
jnatall@amazon.co.uk
EMEA Enterprise Strategist and Evangelist