An Architect's guide to explaining cloud to your CEO

You have the CEO on your side. They buy into the idea of a modern, cloud-based enterprise architecture. They've told everyone in your organization to embrace the cloud. So why, then, is your adoption of cloud going slowly? That is the question asked by McKinsey here.

Established wisdom has it that any organization-wide change, like driving toward a cloud-native architecture, cannot succeed unless it's championed at the top by those with authority to convince and cajole individuals, teams, and departments. As McKinsey puts it: "Only CEOs can wield the baton."

But what if the problem isn't the absence of a baton-wielding CEO but—rather—a baton-wielding CEO who has different expectations from the rest of the C-suite about cloud and what it can deliver? You've got to make sure their view of cloud is aligned with reality.

This is an issue for 52% of organizations, according to Accenture here. Further, these are organizations that say they've failed to achieve the returns expected on cloud. According to Accenture, "It's not uncommon for CEOs to have markedly different impressions of cloud results and concerns than fellow C-suite leaders and high-ranking company officials."CEOs have a "higher level of confidence in the cloud's ability to help mitigate business risk and support sustainability."

These findings should alarm those attempting infrastructure re-architecture. To be effective, a clear set of business objectives and outcomes should drive an architecture. If you can't accurately ascertain what those objectives and outcomes are from the beginning because those on the business side are all on different pages, the odds are stacked against you successfully delivering your project. Those talking to Accenture placed "misalignment between IT and the business" in their top three barriers to cloud adoption and modernization.

Translating CEO talk

Accenture doesn't define "business risk" or "sustainability," but there is a plethora of work dissecting and analyzing CEOs' priorities across the decades. In our current age of uncertainty—where business and economic challenges are falling over themselves to get in the door—CEOs' current concerns reflect the anxieties of our time: A desire for growth, cost control, and tighter cybersecurity.

Thanks to its attributes and advantages, cloud has gone from an option to a necessity in any new business technology project intended to address these concerns. But, as Gartner's David Smith points out, cloud should be seen as a means to an end. The temptation, though, is to see cloud as a destination—an endpoint or a state. "For most people, this creates a scenario where 'in the cloud' means 'where the magic happens.' It should be no surprise that such an environment is rife with myths and misunderstandings," Smith says.

In the context of the CEO's triumvirate of priorities, how can cloud be misunderstood? There are three main ways:

Cloud is a way to save money: Cloud can be seen as a way to eliminate the expense of owning and operating on-prem data centers—paying for operations, hardware, software, and staff—by offloading onto a service provider. Seeing the cloud as a cost-cutting measure is wrong for two reasons: First, it overlooks cloud's elastic and on-demand capabilities that can help IT serve the business. Worse, however, is the fact that cloud can—and probably will—mean an increase in costs: Security, data privacy, and integration are key challenges that require investment. As such, a third of organizations have found cloud more expensive than the on-prem approach of buying software licenses and owning the hardware, according to Ecosystem here.

Cloud is not a euphemism for closing data centers. Rather, it requires the architect to re-think their organization's technology infrastructure, redesign it, and—ultimately—plan for cloud-native. That means, too, changing the processes to deliver and manage the many lifecycles of applications and services.

Cloud means vendor independence: Traditional data-center models lock organizations into vendors' hardware and software. This is costly and—from a strategic and technical point of view—risky. Signing up to the cloud is easy, so the perception is that it's therefore easy to change suppliers—to shop around and shift applications and workloads to achieve greater redundancy and resilience. This is reinforced by widespread awareness that containers and Kubernetes can work on public and private clouds. Lock-in, however, is just as much of a factor in the cloud. Proprietary APIs make it almost impossible to move applications and workloads between different platforms, while bandwidth limitations and network costs make it too expensive to shift data between suppliers.


The architect's response is simple: design an infrastructure that uses two or more clouds for specific workloads—say, one for compute and another for storage and data processing. The complexity comes in ensuring these clouds operate and can be managed like one infrastructure.

Cloud means security: Years of multi-million and billion-dollar data thefts and system breaches mean cybersecurity has become a CEO-level conversation. The CEO's concern is risk management and migration. Human error is the single biggest cause of IT breaches—failure to apply fixes to known vulnerabilities or the compromising of passwords or access rights. Cloud providers have dedicated security teams who are aware of new threats and who upgrade their systems, making cloud providers' platforms generally more secure than those on-prem.

Risk doesn't vanish with cloud—it evolves. Cloud is not secure by default; you must specify and configure a secure platform. You must define, select and roll out tools and processes to help monitor and manage systems and detect and respond to incidents in realtime.

Navigating the C-suite

What's the playbook for delivering your architecture project? You need a three-phased operation:

Move incrementally: Architecture projects are lost when they are built on weak foundations or lack a clear vision or value proposition. A big-bang architecture rollout is a high risk. The smart play is to proceed cautiously: uncover agreed objectives a step at a time and work towards a vision. Establish a handful of agreed goals and outcomes that you can deliver and build on.

Measure the right thing: Projects get a bad rap when they fail to deliver—and failure is certain if the C-suite is divided. Metrics provide an unambiguous means to ascertain whether your architecture is providing the agreed-upon business outcomes. Therefore, it's important that you work with the C-suite and others to establish those metrics based on the desired objectives and outcomes. Significantly, the results should be expressed in language the C-level understands.

Keep it growing: Moving incrementally plays well to Smith's point made above that cloud is a means to an end and not a destination. An effective architecture evolves, while a project that allows itself to be perceived as finished will inevitably become dated, lose relevance, and slowly slide into obsolescence. As you begin to make sense of the C-suite's objectives and expectations, help them appreciate your architecture is a work in progress. Describe how your program works, how it should be measured, and its value—again, using language they understand.

Conclusion

Executive buy-in is the first rule for enterprise IT architecture adoption, but CEOs can harbor expectations about the cloud that can slow down or even thwart a project's delivery. You might not be able to change the CEO's view with one push, but you can read the C-suite in such a way that lets you see past the differences and begin to establish the vision you want—and need.