Accelerating to the cloud: 4 important things to know 

In Accelerating Cloud Adoption: Optimizing the Enterprise for Speed and Agility, cloud expert Mike Kavis, a 30-year veteran in software development and architecture, offers a thorough explanation of why focusing solely on the technology aspect of a cloud adoption strategy isn't enough to accelerate business outcomes. The people and business processes are also vital in architecting an effective cloud strategy, he says.

As a community manager for a growing community of IT architects, developers, and thought leaders, I am learning to look at technology through a holistic lens. Because technology affects an entire organization, not only one area of a business, IT architects have to approach technology implementation using that same lens. Kavis has done just that in Accelerating Cloud Adoption. Here, I'll share a few of the great points he made in his book about an enterprise's journey to the cloud that I found compelling.

The datacenter mindset versus the cloud mindset

"Too many companies focus their cloud adoption strategy solely on the technology, with little to no consideration for redesigning their legacy operating models and business processes. They, too, find it difficult to realize the advantages of cloud as a utility."

Kavis compares today's large companies to the big businesses of the 19th and 20th centuries that hesitated to jump on the electric bandwagon started by Thomas Edison. Edison and his assistant, Samuel Insull, built the "business model that would commoditize electricity and make it available as a service." Today, that same business model is forcing many organizations to examine their legacy architectures.

In the days before Edison, companies created and managed their own electricity with waterwheel mills or hydraulic generators located near the assets that needed power. A group of skilled electricians and generator operators led by a vice president of electricity owned the power. Then along came the power grid, allowing companies of any size to access "the same power grid at the same cost" minus the overhead of purchasing and managing their power generators.

This shift in thinking, from a datacenter mindset to a cloud mindset—or more specifically, the impact on computing advances from the invention of mainframe computing in the mid-20th century to cloud computing today—lays the foundation for Kavis' insights throughout the book.

Kavis analogizes building in the public cloud to starting with a blank canvas. He advises leaving all your legacy datacenter tools, processes, and organizational structures in the past because they're "being deployed to a brand-new virtual environment that is radically different from the datacenter environments that people are used to." Reevaluate your "VP of electricity" way of thinking about the cloud as physical infrastructure and view it as the infrastructure-as-a-service (IaaS) model we see today.

Cloud architects must be masters of change, which makes this section of the book particularly compelling to me. Kavis presents a strong call to action for enterprise architects to move from legacy to modern architecture. Cloud adoption doesn't start with the cloud, he says. It starts with the datacenter and ends with infrastructure.

Cloud is more than just IT

Technology is the focus of the second part of the book. He starts by remarking that architects have more freedom to optimize their core enterprise IT services. These services can include database technologies, operating systems, programming languages, storage, and network technologies. However, this new freedom comes with a bit of a catch: The complexity of managing the underlying technologies increases substantially, Kavis says.

[ Are you keeping up with the pace of digital transformation? Download Cloud-native meets hybrid cloud: A strategy guide. ]

Yes, you have this awesome new way of managing data called "the cloud." Still, now you have all the new processes that come along with it, in addition to keeping all the siloed business domains that are heads-down delivering whatever part of the technology stack they're responsible for. On top of all this, adding new services to the existing operating model adds further complexity, often causing business units to seek external vendor options.

The cloud is a powerful thing. The only way you can prepare for it is to stay on top of its "arc of influence," as Kavis calls it, which reaches well beyond the IT department to every part of the organization. Kavis explains in great detail how departments outside IT are impacted during the cloud adoption journey, from finance shifting from capital expenditures (CAPEX) to operating expenditures (OPEX), all the way down to sales transitioning from shrink-wrapped products to always-on services.

The software development lifecycle

Instead of focusing on the entire software development lifecycle (SDLC), which would require its own separate book, Kavis discusses the Information Technology Infrastructure Library (ITIL) framework diagram. The ITIL diagram centers on service transition and service operations, which, he says, "require the most change to optimize for the cloud" because of their role in delivering software to cloud endpoints.

It takes a lot of time and a lot of processes to get software out the door. Knowing this, it makes sense to want to practice high levels of automation. But Kavis warns against this: You want to focus on reengineering legacy processes for the cloud to "optimize the flow of work," not automating "all of the bottlenecks and waste within them," he advises.

[ For more insight, read The 5 key practices of cloud architecture adoption every cloud architect should learn. ]

It's not uncommon for people without much understanding of the cloud to think of the cloud as "somebody else's datacenter," Kavis says as he concludes the section on SDLC and integrating security into your cloud processes. With that thought in mind, I found this bit of parting knowledge particularly compelling:

"When people say that phrase… there is a good chance they don't understand the differences between software architected for the cloud versus software architected to run on physical infrastructure in a center. In their mind, it's all the same except for the location of the 'datacenter.' If there is no difference, why change the way we deliver software when we go to the cloud?"

Cloud platform roles

In part one of Accelerating Cloud Adoption, Kavis describes how people, processes, and technology must work in tandem to optimize for the cloud. In part two, he focuses on cloud operating models—the heart of your cloud adoption strategy. But you can't build a model without first putting a talented team in place.

A cloud platform provides a core set of enterprise-class cloud services to be consumed by the various development teams, says Kavis. A cloud platform team:

"...provides a service catalog, with some level of self-service capabilities, to the cloud consumers (typically [business units]). The platform team is responsible for applying all relevant security policies and regulatory controls on top of what's provided by the cloud service provider or providers (CSPs)."

In other words, a cloud platform role can be fulfilled by an individual or a team of individuals who perform multiple roles. These roles, which can include a cloud platform owner, a cloud platform leader, governance, and more, act as an internal cloud service provider. This team will be the fuel to the fire of your cloud platform's operating model decision making.

A guide to the cloud for the entire enterprise

These are only a handful of Mike Kavis' powerful insights in this comprehensive yet easily digestible book. I hope these nuggets serve as a taste into the incredible scope of expert insight in Accelerating Cloud Adoption: Optimizing the Enterprise for Speed and Agility. Whether you're a cloud architect, a software architect, an engineer, or a non-technical user, this book has insights you can use.