Cloud Strategy

Organizations?with a cloud strategy — a concise viewpoint on the role of cloud computing as a component of their technological strategy— aligned with their desired business outcomes are more likely to achieve better outcomes from cloud computing than those without one. They have more-coherent approaches to cloud usage and anticipate and exploit the benefits and potential downsides.

Enterprise Architecture (EA) leaders can’t be fully prepared to meet the organization’s needs if they don’t have a common strategy to draw on and to consult for priorities. Likewise, their colleagues in the other subdisciplines of?IT?also need such a strategy.

Many of the top questions?in cloud computing revolve around the cloud strategy. And these questions are becoming more urgent. They range from “What is a cloud strategy and why do we need one?” to “How do we build a comprehensive cloud strategy?” Such questions lead to others about principles and prioritization.

IT leaders must align their cloud strategies with other strategies (for example, data center, security, and architecture). The organization’s cloud strategy should enable its digital transformation initiatives.

Although it’s best to craft a cloud strategy before adopting cloud computing, that’s rare. Most organizations devise their cloud strategies after gaining experience with the cloud. However, the sooner an organization establishes a cloud strategy, the more issues it’ll avoid. It’s never too late to develop a cloud strategy. If an organization doesn’t have one, today is the best time to start creating one.

Here, we see some steps common to all organizations.

Terminology

Eliminate confusion by agreeing on cloud computing definitions and using them consistently.?There are newer terms for cloud computing (e.g., cloud-native,?multi-cloud, and distributed cloud). However, the meanings of such terms aren’t as well-established. Who uses them should clarify their meaning. We should consider using other terms, such as pure cloud and cloud-inspired, to provide clarity. We should use existing terms, don’t reinvent them.

Creating?a cloud strategy?will enable us to populate a training and communication plan, both essentials to broadening cloud discussions.

Business Baseline and Goal

We need to summarize the top-level business strategy, desired business outcomes, and business transformation initiatives. We can use annual reports, speeches by senior management, and conversations with business leaders as sources.

We should look at the potential benefits and risks. These are mostly generic and aligned with bimodal IT principles. Know the goals (typically, cost-cutting/cost-efficiency or agility/innovation), and assess how cloud computing can help achieve those goals.

We need to use bimodal IT principles because the prioritization they enable is key to addressing business outcomes. We can group the potential cloud benefits into the two buckets in the figure below.?This prioritization involves the benefits, not workload priority, in moving to the cloud.

Then we must examine issues?unique to the organization. For example, explore:

? What the business is trying to accomplish in its industry and in its region

? Whether we need to align with a data center strategy

? Whether there are extenuating circumstances

? The impact of responding to uncertainties, such as the COVID-19 pandemic?or other similar events with far-reaching impacts

We should map business goals to the potential benefits of cloud computing, and explain how to overcome the?possible?challenges. We can state why the organization is interested in the cloud. We need to prioritize and begin focusing on the goals using the bimodal principles.

Brainstorming

This phase is fluid and should accommodate many discussion points. A service strategy and?financial considerations?make good discussion points when brainstorming the main principles that will drive a cloud strategy. We shoud document these to increase the understanding of those principles and how to use them.

Services Strategy

IT leaders shoud determine the services strategy by deciding when they’ll consume cloud services from a public cloud provider and when they’ll build — or at least continue to maintain — capabilities on-premises or elsewhere. IT leaders need to distinguish the use cases for infrastructure as a service (IaaS), platform as a service (PaaS) and software as a service (SaaS).

IT leaders need to address scenarios in which they may want to be a broker, and how to have a hybrid IT operating model in which they simultaneously consume services, act as a middleman and provide services.?They must ask?and answer the question, “how do we secure, manage and govern the resulting hybrid environment?”

We mustn't take the decision to build cloud services lightly. It’s a huge effort. Most organizations maintain some on-premises capabilities, we mustn't try to duplicate the functionality of hyperscale cloud providers. We need to examine the applicability of all potential roles in cloud computing — consumer, provider and broker (including governance).

Financial Considerations

IT leaders must?understand, at a high level, the financial implications of cloud computing. They need to examine issues such as cost transparency, visibility, budgeting and predictability.?Organizations typically fund cloud computing from operating expenditure (opex), rather than capital expenditure (capex). However, owning capital assets is a key part of the corporate financial strategy for some companies. If we change everything to opex, it could change the organization’s financial profile.?We must involve finance professionals, because they understand the implications of changes to corporate financial models.

We must understand pricing model trends to ensure that we meet expectations. For example, IaaS is mainly aligned with hardware costs, so the prices have tended to go down slowly (inflation may be changing this). IaaS can be purely a pay-as-you-go model. Contracts aren’t required for IaaS, but may be desirable in some scenarios (such as for pricing discounts). We must contrast that with SaaS for applications in which the prevalent model is subscription. SaaS contracts typically last three years and charge per user, per month. The price for SaaS tends to go up. And above all, we must not believe the biggest myth about the cloud — that we always save money by moving to it.

So, doing in this way the cloud strategy will give us an understanding of the many implications of the financial options available. It won’t give us a business case for or against cloud computing.

Principles

IT leaders need to decide which principles will determine their cloud strategy. Some should be non-negotiable — for example, a cloud strategy (unlike a data center strategy) is a workload-by-workload or application-by-application exercise (workloads are groupings of applications). Lift-and-shift migrations to the public cloud should be a last resort.

We generally don’t gain much from lift-and-shift migrations, although sometimes they’re?appropriate.?For example, if the data center strategy (or edict) is data center closure, we must align with it, which means we may have to find a home for things. However, we should not expect to gain huge cost savings or many agility benefits from lift and shift, unless the current situation is highly inefficient.?Such a migration may make sense for other reasons. For example, we may not want to change the application (to avoid potential disruptions in operations), and the application must be colocated with data or applications that have been moved to the cloud (for all the right reasons).?However, using lift and shift without a sound reason is rarely?wise.

We need to consider common principles, including:

? Cloud first, or variations (e.g., cloud smart)

? Buy before build (which, as related to the cloud, is often called “SaaS first”)

? Best of breed

? Multicloud

Some of these may be architectural principles, such as cloud-native or multicloud. These are likely to resurface during an exit strategy or when aligning with architectural principles.

Cloud first is a common principle guiding cloud strategies and adoption decisions. Some people dismiss it as a slogan. Although it’s more than that, it’s not a whole strategy.

Cloud first is often misunderstood, It doesn’t mean everything goes to the cloud. It means that, when you ask for an investment (for example, when you want to renew, enhance or build something), the default approach is to use the public cloud. Cloud first also means you should consider the cloud as the first option for any new technology or business initiative.

Inventory (An Assessment of Current Position)

If the cloud strategy is workload by workload, IT leaders must inventory those workloads. For each workload, they must have a set of information at their fingertips.

Some concepts help us decide what kinds of information to capture about each workload to help us make decisions. Is the goal to save money on this application? Or is the goal to be more agile? If the goal is to be more agile, it may cost more, which may be acceptable. Some tools, such as total cost of ownership (TCO) and?pace layering,?can be helpful.

The inventory effort can be substantial, and it is often spun off as a separate project or as part of adoption. What’s most important in the strategy phase is to specify what information should be collected about each workload. We should determine the scope and can start the effort in the strategy phase.

We must consider some basic information for each workload, including answers to the following questions:

? What’s the name of the workload?

? Who owns it?

? Who authored it (if you wrote it in-house)?

? Does it depend on other applications?

? Is a vendor involved?

? Is it a packaged application from a vendor? If so, what do we need to know about that? (For example, if we’re on the last on-premises version from this vendor and we want to upgrade, do we have to go to its SaaS version?)

? Is it virtualized?

? What are the security, governance, compliance and data requirements?

? Does it have?personally identifiable information?and security requirements?

? Does it have special integration or location requirements?

? What’s the goal: efficiency or agility? (This element is critical and isn’t found in most other application rationalization or asset management efforts, which can be a good starting point.)

When deciding whether we have a good candidate for the cloud, we should analyze performance characteristics. Using a spectrum is helpful:

? At one end of the spectrum?are unpredictable workloads. These are externally facing and difficult or impossible to predict demand for, such as a website, a mobile app or an API gateway. These are generally good candidates for public cloud.

? At the other end of the spectrum are well-behaved applications. For example, these could be typical enterprise applications that are already virtualized and running efficiently in the data center. They’re steady-state applications that don’t vary much and don’t have peak workloads. Such predictable workloads don’t typically benefit from cloud and aren’t the first choices to move.

? Things aren’t so clear cut in the middle of the spectrum. For example, we may have a classic, overprovisioned workload. Such a workload may have a peak for which we must overprovision.?Cloudbursting?has long been cited as a goal in cloud computing; however, it has limited applicability. We need to assess the merits of moving such a workload to the cloud.

Cloud Strategy Integrates With Other Strategies

Cloud computing doesn’t exist in a vacuum, and neither should the cloud strategy. IT leaders must ensure that the cloud strategy aligns with existing strategies (such as those for security, data center, edge computing, and development and architecture). It shouldn’t reinvent or contradict them. They must communicate and negotiate with other groups to create a successful cloud strategy.

Security

It’s so important. IT leaders must approach security (including governance, compliance and privacy) and all the other supporting elements (such as technical architecture, infrastructure, staffing and procurement) by ensuring that they align. If they include something about security in the cloud strategy, they must ensure that it also goes in the security strategy and vice versa. Sometimes this may mean the security team has to modify the overall security strategy.

Security is a shared responsibility. We must understand the different roles and responsibilities in security to use the cloud securely.

We need to approach security with high standards using concepts such as tiering providers. We need to remember that anyone can claim to be a cloud provider and may have a far lower level of security capability than a top-tier provider.

The top-tier cloud providers generally do an excellent job of securing the services they provide, but they don’t secure the applications or data that we host there. We must lock down the data we put there appropriately. If we leave the data unprotected, then it’s not the provider’s fault.

Supporting Elements — Organizational and Staffing Issues

Just as we must align cloud security issues with the overall security strategy, so we must also align cloud staffing issues with the overall staffing strategy. Cloud computing will change the staffing requirements, depending on the level of cloud service adopted. We’ll need different mixes of skill sets. We’ll probably need fewer people who manage servers directly, but more people who do higher-level tasks, such as integration, network engineering, business analysis, vendor management and security. Growth opportunities will exist for some, and it’s important to involve the right people. That’s why we must include HR in this effort.

We should also discuss the cloud strategy council and cloud center of excellence (CCOE) constructs from an organizational perspective.

Exit Strategy

Cloud repatriation (moving workloads back from a public cloud) is rare. However, it’s vital to devise an exit strategy that describes dependencies and choices, even though we may never use it.?Awareness of possibilities and planning for them is an important part of strategic planning.?Several regulators, mainly in the European Union (EU) and focused on financial services, now mandate an exit strategy.

Organizations that do look at exit strategies often focus on contracts — aspects such as terms and conditions, and service-level agreements (SLAs). Although contracts are important, it’s just the beginning when it comes to an exit strategy. We must also examine such issues as:

Data ownership

? Backup

? Getting back your data

? Portability

We must include in the exit strategy both technical and business factors. And we must not forget all the supporting infrastructure for the cloud service, including networking, management tools, integration and third-party services.

We should make lock-in one of the main issues we discuss as part of the exit strategy. We can have lock-in in many different places:

? At the data level

? At the application level

? At the architecture level

? At the skills level

This may be what makes we examine?multicloud?and cloud-native issues. Many say they want to follow a?multicloud?approach, but note in their cloud strategy signals that they also want to be cloud native. These concepts can conflict if we take them to their logical extremes. If we want to follow a?multicloud?approach and not depend on a vendor, then we must be careful when using the native capabilities of a vendor. There are trade-offs. No simple answer exists, but we should handle these issues in the cloud strategy.

SaaS is part of cloud computing. And as we are taking an application-by-application approach, we must consider what choices are important to the organization. When we consider SaaS vendors, we must take into account that many vendors are becoming pure-play SaaS providers. Fewer traditional, on-premises offerings are available.

We need to focus the exit strategy on answering the “what” and “why” questions. We must cover the answers to the “how” questions in a more-detailed exit plan (often part of the adoption plan). We must make the exit plan workload-specific, and if it doesn’t work out as planned, then we must describe how you’ll get out of a particular cloud situation.

Put The Cloud Strategy Into Practice

For example, if we have decided to follow a cloud-first principle, when a request comes in to enhance an application, we’ll consult the inventory and apply the principles to the request. It becomes more complicated if the data center strategy is to close the data centers in two years. In that case, we must also start to build a cloud migration plan in which we find homes for everything. However, we must not go through all applications and move them unless we have that kind of edict.

This is where the connection with a data center strategy comes in, and where we move from strategy to execution. Data center and I&O-centric issues often drive the extenuating circumstances. However, other considerations — such as application modernization, mergers and acquisitions, new product development, business resilience and other strategies — may trigger mass migrations.

We need to decide what to do with a workload guided by the process of applying principles to the. Figure allow shows the different decisions we can make about a workload. We call these the “Rs.”