“I can’t change the direction of the wind, but I can adjust my sails to always reach my destination.”
In my last post, I introduced some patterns I’ve observed within large enterprises that have implemented cloud-first policies. These enterprises have reversed the burden of proof from “Why should we use cloud?” to “Why shouldn’t we use the cloud?” when implementing technology solutions for their business. This post kicks off a mini-series describing a pattern I’ve observed as some enterprises journey toward cloud-first. I call this pattern the four “Stages of Adoption.”
Different enterprises arrive at a cloud-first policy at different points in their journey. Some CIOs with confident instincts will declare cloud-first early in their journey; some create elaborate business cases to justify cloud-first before moving anything to the cloud; some have let cloud-first happen to their organization through opportunistic developers or shadow IT; and some have iterated toward a cloud-first posture by opportunistically implementing cloud projects one-by-one.
So, as much as I’d like to be able to articulate the right time for every enterprise to declare cloud-first, every business has its own unique set of opportunities and challenges that guide and constrain its decisions.
In addition, many enterprises view themselves as a collection of loosely coupled and independently managed business units (BUs). Depending on the enterprise, these BUs will have varying amounts of autonomy in how they make technology decisions. Some enterprises have a highly centralized model, where a central IT function selects and controls which technology should be adopted across the BUs; some enterprises give the individual BUs autonomy to make their own technology decisions; while most fall somewhere in between.
There is no right or wrong approach for structuring technology decision-making across an organization, but there are tradeoffs between centralization (efficiency, standardization) and autonomy (time to market, innovation). Increasingly, most of the executives I talk to favor the latter. Later on in this mini-series, I’ll touch upon this trend by pontificating on the technology organizational structure of the future, Amazon.com’s two-pizza team model, and how a cloud center of excellence fits in.
This kind of diversity makes it hard to prescribe what every organization’s cloud journey will look like, and equally hard to pinpoint exactly when every enterprise should make a cloud-first declaration. Having said that, I have observed a pattern in the types of activities that enterprises engage in on their journey toward cloud-first. While I present these “Stages of Adoption” as a sequential journey, I’ve also seen enterprises with many, often unrelated, BUs are in different stages at the same time, and it’s very possible that activities from any one stage are happening in parallel across the organization, ideally creating a flywheel effect for the broader organization.
Below is an introduction to these “Stages of Adoption,” which I’ll elaborate on over the course of my next several posts.
Not surprisingly, most enterprises start with a few projects to begin to understand how they can leverage the cloud to meet a business need. 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 way to start experimenting.
Once an enterprise has gained some benefit from the cloud through a few projects, it tends to make some foundational investments so it can scale that benefit across its organization. I recommend that this investment start with the establishment of a cloud center of excellence (CCoE) team that can own the development of these foundational elements. Common CCoE responsibilities typically include, but aren’t limited to--developing a hybrid architecture strategy; creating reference architectures as a blueprint to share across different applications and/or business units; focusing on identity and asset management; dealing with cost governance; and ushering in cloud training and education to others in the organization.
As the enterprise builds a cloud foundation and gains experience with more projects, it typically becomes easier and more compelling to migrate existing IT assets to the cloud. This often starts with an application discovery process and a business case, and is followed by individual application migrations across a number of different migration strategies. Many enterprises bias toward lift-and-shift to achieve some cost savings, while others prefer to refactor to take advantage of the features like autoscaling and global availability-that they can’t get in their own data centers.
As the gravity of an enterprise’s IT footprint moves from its own (or its MSPs) data centers to the cloud, it typically finds itself in a much better position to optimize both its IT footprint (costs) and its business capabilities (products and services). Many enterprises, including GE Oil & Gas, find that it’s easier to optimize their applications after they’ve migrated them to the cloud, because of the expertise they gained along the way.
As more enterprises travel journeys like this, and provide valuable lessons on how they did it, the earlier it seems other enterprises are establishing a cloud-first posture. When I was the CIO at Dow Jones, we didn’t declare cloud-first until we had built a few new digital products on the cloud, staffed a cloud center of excellence team we called DevOps, and migrated a data center that was coming off a lease to the cloud. We used that migration, which saved us more than 30% in costs, as the foundation for a cloud-first business case to migrate more than 50 data centers to the cloud over a three-year period. Organizations like GE Oil & Gas and Intuit are making these declarations much sooner.