Getting Started With the Cloud?

“The journey of a thousand miles begins with a single step.” — Lao Tzu

In my last post, I introduced a mental model called the “Stages of Adoption” (SofA), which describes the Journey that enterprises 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 is no one-size-fits-all answer, I hope that the SofA will be a useful model for executives to consider as they guide their organizations on their Journey.

This post focuses on the first SofA, which I call “Project,” and it elaborates on what I’ve seen within enterprises that are getting started with the cloud.

Not surprisingly, most enterprises start with a handful of projects that help them understand how they can leverage the cloud to meet a business need.

My First Enterprise Cloud Project

In 2012, while I was the CIO of Dow Jones, my boss (our CEO) had a hypothesis that we all felt was a great business opportunity: If the subscribers of the Wall Street Journal, Dow Jones’ flagship B2C product, had much of the world’s wealth, and the subscribers of Factiva and Dow Jones Newswires, Dow Jones’ B2B products, managed much of the world’s wealth, we could create a valuable platform by giving them a mechanism to connect and communicate with one another.

Dow Jones had never built anything like this before, and we were eager to move quickly. We assembled a very small team of engineers and designers to build out a proof of concept, and we gave them the freedom to choose whatever tools they thought would get the job done.

Six weeks later, with a little bit of AWS, automation, open source, and a lot of hard work, we had a highly-available and disaster-indifferent application up and running. Our newfound ability to deliver technology to the business quickly became our “hero” project, which helped encourage my team (many of whom became anxious until we trained them) and executive stakeholders to come on the Journey with us.

What Project Should You Start With?

Generally speaking, I like to see organizations start with a project that they can get results from in a few weeks. The days of multi-year IT projects are numbered, and the majority of executives I talk to are attracted to the cloud because of the agility it brings to their business.

Give your teams a hands-on, time-constrained opportunity to do something meaningful. My experience came in the form of net new development, which is a pattern I’ve seen many other enterprises follow. Modern web and mobile applications are ideal, particularly because the universe of use cases and reference architectures are well known. I’ve also seen enterprises start with an Amazon Workspaces deployment, a dev/test environment migration, or a modernization/migration of an existing application.

The complexity of migrating existing applications varies, depending on the architecture and existing licensing arrangements. If I think about the universe of applications to migrate on a spectrum of complexity, I’d put a virtualized, service-oriented architecture on the low-complexity end of the spectrum, and a monolithic mainframe at the high-complexity end of the spectrum. I suggest starting with something on the low-complexity end of the spectrum. I will cover these migration scenarios and patterns in much more detail in the “Migration” SofA stage.

What I’ve found most important is that organizations pick something that will deliver value to the business, but something that isn’t so important that there’s no appetite for learning. Avoid analysis paralysis, and use your early cloud projects as a way to start experimenting.

Unless there is a strong compelling reason to do so, I’d caution against a complete business transformation program with your first project. There is a rate at which organizations can handle change, and that rate will be unique to every organization. I’ve found that accelerating past that rate can lead to negative returns. I’ve often been described as a “cowboy,” a term I found endearing, until it became counterproductive. Someone once told me that “there’s no glory being alone at the finish line.” My stomach dropped once I heard this and realized just how cowboy-ish I had been, and I’ve had to learn to constantly repeat this phrase to myself as I try to strike the right balance.

Who Should Work On Your Early Cloud Projects? (Hint: Attitude Matters)

Regardless of where in your organization you get started, you should expect that your early cloud projects will make some people excited and some people uncomfortable.

Start to nurture the people who get excited and consider how you can turn them into your own cloud champions/evangelists. I’ve found that attitude is just as important as aptitude, and your early champions tend to be the curious type who aren’t afraid to experiment. Keep an eye on them as your projects evolve, as they may be good candidates to staff your cloud center of excellence, which we’ll explore in the next stage of adoption (“Foundation”).

Be empathetic to those that get uncomfortable, and provide them with the tools they need to come on the Journey with you. Computer science fundamentals have not changed, but to really take advantage of what the cloud has to offer many traditional functions need to think differently about how they accomplish their goals. Be sensitive to their concerns and check out some of my previous posts on bringing your staff along on your Journey: You Already Have the People You Need to Succeed with the Cloud and 11 Things to Consider When Educating Your Staff on the Cloud.

Where Are Early Projects Driven From?

Two or three years ago, it seemed like most cloud projects were driven by individual business units. In many cases, these projects were implemented as “shadow IT,” which is often the case when the business can’t get what it needs from a central IT function fast enough. While “shadow IT” has traditionally been a source of organizational tension, I’m increasingly seeing cloud center of excellence teams providing IT-approved cloud reference architectures to business units so that they can safely innovate on top of them in a secure, governed, and transparent way. This approach can liberate innovation within different business units while still affording central IT the guardrails it needs to enforce security, compliance, and consistency across a large IT footprint. AWS Service Catalog is aimed at helping enterprises do this at scale.

As cloud has become the new normal I’m increasingly seeing early cloud projects driven by central IT. Many financial services organizations, for example, are looking to cut out costs, and are looking toward the cloud to right size dev/test environments as they go through refresh cycles. Johnson & Johnson, in another example, implemented Amazon Workspaces as one of its early cloud projects.

What’s your early 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: “Project” is the first of four “Stages of Adoption” I’m writing about in the Journey to Cloud-First series. The other three stages are “Foundation,” “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.