4 Foundational Investments for Your Cloud Journey

“Good skin is the best foundation for your makeup” – Holland Rolland

In a recent post, I introduced a mental model called the “Stages of Adoption” (SofA), which describes the Journey that organizations travel as they become cloud-first. I’ve found this Journey to be more of a leadership and change management exercise than a technical exercise, and, while there are no one-size-fits-all answers, I hope that the SofA will be a useful model for executives to consider as they guide their organizations on their Journey.

My previous post focuses on the first SofA, which I call “Project,” and describes what I’ve seen in organizations that are getting started with the cloud.

It usually takes just a few projects for most organizations to start to realize how much faster they can deliver on the cloud. This post covers 4 areas I typically see organizations invest in so that they can scale this benefit across their organization; I call this the “Foundation” stage.

1. Create a Cloud Center of Excellence (CCoE) Team

I believe the creation of a CCoE is one of the most critical foundational investment an organization can make, particularly if you’re looking to evolve your culture. Many organizations I speak to are using their CCoE as a fulcrum to create change across their organization, a trend I captured in Your Enterprise’s Flywheel to the Cloud.

As I described in staffing a CCoE, I like to see organizations build a cross-functional team of people with a diverse set of perspectives. Traditional roles around system administration, database administration, network engineering, and operations often blend together as they are increasingly automated as code. I strongly believe you already have the people you need to succeed, and that anyone in these roles today who is eager to learn something new could be an ideal fit for your CCoE. You probably already know who those people are (and aren’t).

As you build your CCoE, consider how you want the various business units to engage with it, and how your organization will govern (centralize/decentralize) technology choices.

For example, when we built the CCoE team at Dow Jones, we named it DevOps, deliberately conflating it with a term that describes a run-what-you-build philosophy. Our goal was to have the DevOps team prescribe an operating model that embodied the best practices, governance, and guardrails that we preferred in our enterprise, while still giving each business unit the autonomy to make the decisions it needed to accomplish its goals in a timeframe it controlled. As the DevOps team matured, so did our reference architectures (see below), and we found that more business units wanted to use what the DevOps team offered because it made them faster and more effective, not because we forced them to.

2. Build Reference Architectures to Reuse Across Your Business

Encourage your teams to look for common patterns in the applications they own. If you find a reference architecture that meets the needs of several applications, create scripts that automate the construction of that reference architecture while baking in your security and operational controls. This could be as simple as creating a “golden image” for the various operating systems your teams use, or as complex as a blueprint that describes the architecture and operating model of all the websites you host.

Each reference architecture should consider how it will communicate back to your on-premises assets. As I said in a post about the myths of hybrid architectures, “I’ve spoken to many CIOs who want to migrate their infrastructure to the cloud as fast as possible, but realize that meaningful cloud adoption is a journey that takes time. Along that journey, companies need a way to keep their systems running and get the most out of their existing investments.” Some organizations create a handful of security groups that are allowed to communicate through their on-premises firewalls in a way that’s consistent with their existing controls, and then they reuse these security groups across different reference architectures.

Giving your CCoE visibility across your entire IT portfolio will make it easier for it to find and scale reference architectures. The AWS Service Catalog can help you store, permission, and distribute reference architectures across your organization as you scale.

3. Create a Culture of Experimentation and Evolve Your Operating Model

The cloud is the single biggest enabler of experimentation I’ve seen in my career, and many organizations use their cloud Journey as a forcing function to revisit their traditional IT operating models.

I’m increasingly seeing organizations revisit how much autonomy they give each business unit to make technology choices. At the same time, they’re thinking carefully about how roles and privileges are managed, who’s accountable for costs, what tools can/should be used for monitoring and logging, and who can influence changes in the environment.

At Amazon, for example, every service is owned by a “two-pizza team” that is wholly accountable for the service it provides to its customer. This includes what technologies are used, the service’s roadmap, and the service’s operations.

While this run-what-you-build mentality may make some people uncomfortable, I find that more organizations are moving toward it than away from it. Many organizations are pushing their CCoEs to define what an appropriate operating model looks like and bake it into the reference architectures and continuous integration tools they deliver to each business unit. When done with the proper guardrails, this can allow each business unit to release changes much more often.

When I was at Dow Jones, for example, our CCoE built a simple but effective continuous integration pipeline that allowed us to abolish our bi-weekly release windows in favor of pushing small changes whenever they were ready. And, when I left Dow Jones in September of 2014, our CCoE gave me a document describing the 600 releases they made to MarketWatch.com that month alone. It was the most rewarding parting gift I’ve ever received.

4. Educate Your Staff and Give Your Team a Chance to Learn

Education is the most effective mechanism I’ve found to get your team to come along with you. I’ve said all I have to say on this topic in the following posts, and I can’t stress enough how important this is for organizations to remain competitive in today’s talent marketplace.

• You Already Have the People You Need to Succeed with the Cloud
• 11 Things to Consider When Educating Your Staff on Cloud
• The Importance of Talent in Your Transformation

Capital One is, from my perspective, one the industry’s leading organizations on talent development. Drew Firment, Capital One’s Technology Director of Cloud Engineering, has shared his thought leadership on the topic in his post on how Talent Transformation Is Really the Hardest Part of Cloud Adoption.

In Closing …

Look at these foundational investments as something that will benefit your organization for many years to come. Don’t try to boil the ocean, and remember that you can iterate on and improve your foundation over time. It should be strong but flexible as you learn.

What’s your foundational experience been? I’d love to hear about it, and talk about posting it on my blog!

Keep building,
–Stephen
@stephenorban
orbans@amazon.com

Note: “Foundation” is the second of four “Stages of Adoption” I’m writing about in the Journey to Cloud-First series. The first stage is “Project,” and after “Foundation” come “Migration,” and “Reinvention.” This series follows the best practices I’ve outlined in An E-Book of Cloud Best Practices for Your Enterprise. Stay tuned for more stories posts covering each of these stages.