Get Instant Access
to This Blueprint

Infrastructure Operations icon

Define Your Cloud Vision

Define your cloud vision before it defines you.

The cloud permeates the enterprise technology discussion. It can be difficult to separate the hype from the value. Should everything go to the cloud, or is that sentiment stoked by vendors looking to boost their bottom lines? Not everything should go to the cloud, but coming up with a systematic way to determine what belongs where is increasingly difficult as offerings get more complex.

Our Advice

Critical Insight

Don’t think about the cloud as an inevitable next step for all workloads. The cloud is merely another tool in the toolbox, ready to be used when appropriate and put away when it’s not needed. Cloud-first isn’t always the way to go.

Impact and Result

  • Evaluate workloads’ suitability for the cloud using Info-Tech’s methodology to select the optimal migration (or non-migration) path based on the value of cloud characteristics.
  • Codify risks tied to workloads’ cloud suitability and plan mitigations.
  • Build a roadmap of initiatives for actions by workload and risk mitigation.
  • Define a cloud vision to share with stakeholders.

Define Your Cloud Vision Research & Tools

1. Define Your Cloud Vision – a step-by-step guide to generating, validating, and formalizing your cloud vision.

The cloud vision storyboard walks readers through the process of generating, validating and formalizing a cloud vision, providing a framework and tools to assess workloads for their cloud suitability and risk.

2. Cloud Vision Executive Presentation – a document that captures the results of the exercises, articulating use cases for cloud/non-cloud, risks, challenges, and high-level initiative items.

The executive summary captures the results of the vision exercise, including decision criteria for moving to the cloud, risks, roadblocks, and mitigations.

3. Cloud Vision Workbook – a tool that facilitates the assessment of workloads for appropriate service model, delivery model, support model, and risks and roadblocks.

The cloud vision workbook comprises several assessments that will help you understand what service model, delivery model, support model, and risks and roadblocks you can expect to encounter at the workload level.


Member Testimonials

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve. See our top member experiences for this blueprint and what our clients have to say.

9.5/10


Overall Impact

$235,512


Average $ Saved

31


Average Days Saved

Client

Experience

Impact

$ Saved

Days Saved

University of South Australia

Guided Implementation

8/10

$62,999

20

Sharonview Federal Credit Union

Workshop

10/10

$25,829

5

Oneida Nation

Workshop

10/10

N/A

10

County of Los Alamos

Guided Implementation

10/10

$2,519

5

Cobb EMC

Workshop

10/10

$62,999

23

Collier County Board of County Commissioners

Workshop

9/10

$377K

90

Stockman Bank

Workshop

10/10

$69,299

23

Washington Technology Solutions

Guided Implementation

7/10

N/A

N/A

Health Canada

Guided Implementation

10/10

$4,000

20

Monroe #1 BOCES

Workshop

10/10

$125K

50

ENERGYUNITED ELECTRIC MEMBERSHIP CORPORATION

Workshop

10/10

$1.26M

90

Denver Water

Workshop

10/10

$503K

50

Canadian Blood Services

Workshop

8/10

$95,000

23

National Cooperative Bank NA

Workshop

10/10

N/A

10

University of Kansas Hospital Authority

Workshop

10/10

N/A

20

State of Delaware, Department of Technology & Information

Guided Implementation

9/10

N/A

N/A

City of Virginia Beach

Guided Implementation

10/10

N/A

20


Workshop: Define Your Cloud Vision

Workshops offer an easy way to accelerate your project. If you are unable to do the project yourself, and a Guided Implementation isn't enough, we offer low-cost delivery of our project workshops. We take you through every phase of your project and ensure that you have a roadmap in place to complete your project successfully.

Module 1: Understand the Cloud

The Purpose

Align organizational goals to cloud characteristics.

Key Benefits Achieved

An understanding of how the characteristics particular to cloud can support organizational goals.

Activities

Outputs

1.1

Generate corporate goals and cloud drivers.

1.2

Identify success indicators.

1.3

Explore cloud characteristics.

1.4

Explore cloud service and delivery models.

1.5

Define cloud support models and strategy components.

1.6

Create state summaries for the different service and delivery models.

1.7

Select workloads for further analysis.

  • Corporate cloud goals and drivers
  • Success indicators
  • Current state summaries
  • List of workloads for further analysis

Module 2: Assess Workloads

The Purpose

Evaluate workloads for cloud value and action plan.

Key Benefits Achieved

Action plan for each workload.

Activities

Outputs

2.1

Conduct workload assessment using the Cloud Strategy Workbook tool.

2.2

Discuss assessments and make preliminary determinations about the workloads.

  • Completed workload assessments
  • Workload summary statements

Module 3: Identify and Mitigate Risks

The Purpose

Identify and plan to mitigate potential risks in the cloud project.

Key Benefits Achieved

A list of potential risks and plans to mitigate them.

Activities

Outputs

3.1

Generate a list of risks and potential roadblocks associated with the cloud.

3.2

Sort risks and roadblocks and define categories.

3.3

Identify mitigations for each identified risk and roadblock

3.4

Generate initiatives from the mitigations.

  • List of risks and roadblocks, categorized
  • List of mitigations
  • List of initiatives

Module 4: Bridge the Gap and Create the Strategy

The Purpose

Clarify your vision of how the organization can best make use of cloud and build a project roadmap.

Key Benefits Achieved

A clear vision and a concrete action plan to move forward with the project.

Activities

Outputs

4.1

Review and assign work items.

4.2

Finalize the decision framework for each of the following areas: service model, delivery model, and support model.

  • Cloud roadmap
4.3

Create a cloud vision statement

  • Finalized task list
  • Formal cloud decision rubric
  • Cloud vision statement

Module 5: Next Steps and Wrap-Up

The Purpose

Complete your cloud vision by building a compelling executive-facing presentation.

Key Benefits Achieved

Simple, straightforward communication of your cloud vision to key stakeholders.

Activities

Outputs

5.1

Build the Cloud Vision Executive Presentation

  • Completed cloud strategy executive presentation
  • Completed Cloud Vision Workbook.

Define Your Cloud Vision

Define your cloud vision before it defines you

Analyst perspective

Use the cloud’s strengths. Mitigate its weaknesses.

The cloud isn’t magic. It’s not necessarily cheaper, better, or even available for the thing you want it to do. It’s not mysterious or a cure-all, and it does take a bit of effort to systematize your approach and make consistent, defensible decisions about your cloud services. That’s where this blueprint comes in.

Your cloud vision is the culmination of this effort all boiled down into a single statement: “This is how we want to use the cloud.” That simple statement should, of course, be representative of – and built from – a broader, contextual strategy discussion that answers the following questions: What should go to the cloud? What kind of cloud makes sense? Should the cloud deployment be public, private, or hybrid? What does a migration look like? What risks and roadblocks need to be considered when exploring your cloud migration options? What are the “day 2” activities that you will need to undertake after you’ve gotten the ball rolling?

Taken as a whole, answering these questions is difficult task. But with the framework provided here, it’s as easy as – well, let’s just say it’s easier.

Jeremy Roberts

Research Director, Infrastructure and Operations

Info-Tech Research Group

Executive Summary

Your Challenge

  • You are both extrinsically motivated to move to the cloud (e.g. by vendors) and intrinsically motivated by internal digital transformation initiatives.
  • You need to define the cloud’s true value proposition for your organization without assuming it is an outsourcing opportunity or will save you money.
  • Your industry, once cloud-averse, is now normalizing the use of cloud services, but you have not established a basic cloud vision from which to develop a strategy at a later point.

Common Obstacles

  • Organizations jump to the cloud before defining their cloud vision and without any clear plan for realizing the cloud’s benefits.
  • Many organizations have a foot in the cloud already, but these decisions have been made in an ad hoc rather than systematic fashion.
  • You lack a consistent framework to assess your workloads’ suitability for the cloud.

Info-Tech's Approach

  • Evaluate workloads’ suitability for the cloud using Info-Tech’s methodology to select the optimal migration (or non-migration) path based on the value of cloud characteristics.
  • Codify risks tied to workloads’ cloud suitability and plan mitigations.
  • Build a roadmap of initiatives for actions by workload and risk mitigation.
  • Define a cloud vision to share with stakeholders.

Info-Tech Insight: 1) Base migration decisions on cloud characteristics. If your justification for the migration is simply getting your workload out of the data center, think again. 2) Address the risks up front in your migration plan. 3) The cloud changes roles and calls for different skill sets, but Ops is here to stay.

Your challenge

This research is designed to help organizations who need to:

  • Identify workloads that are good candidates for the cloud.
  • Develop a consistent, cost-effective approach to cloud services.
  • Outline and mitigate risks.
  • Define your organization’s cloud archetype.
  • Map initiatives on a roadmap.
  • Communicate your cloud vision to stakeholders so they can understand the reasons behind a cloud decision and differentiate between different cloud service and deployment models.
  • Understand the risks, roadblocks, and limitations of the cloud.

“Now we’re moving from a world where companies like Oracle and Microsoft and HP and Dell are all critically important to a world where Microsoft is still important, but Amazon is really important. Google is important. So not just the technology changed, but all the major vendors they’re betting their business on have also changed. And that’s super hard for people.” –David Chappell, Author and Speaker

Common obstacles

These barriers make this challenge difficult to address for many organizations:

  • Organizations jump to the cloud before defining their cloud vision and without any clear plan for realizing the cloud’s benefits.
  • Many organizations already have a foot in the cloud, but the choice to explore these solutions was made in an ad hoc rather than systematic fashion. The cloud just sort of happened.
  • The lack of a consistent assessment framework means that some workloads that probably belong in the cloud are kept on premises or with hosted services providers – and vice versa.
  • Securing cloud expertise is remarkably difficult – especially in a labor market roiled by the global pandemic and the increasing importance of cloud services.

Standard cloud challenges

30% of all cloud spend is self-reported as waste. Many workloads that end up in the cloud don’t belong there. Many workloads that do belong in the cloud aren’t properly migrated. (Flexera, 2021)

44% of respondents report themselves as under-skilled in the cloud management space. (Pluralsight, 2021)

Info-Tech’s approach

Goals and drivers

  • Service model
    • What type of cloud makes the most sense for workload archetypes? When does it make sense to pick SaaS over IaaS, for example?
  • Delivery model
    • Will services be delivered over the public cloud, a private cloud, or a hybrid cloud? What challenges accompany this decision?
  • Migration Path
    • What does the migration path look like? What does the transition to the cloud look like, and how much effort will be required? Amazon’s 6Rs framework captures migration options: rehosting, repurchasing, replatforming, and refactoring, along with retaining and retiring. Each workload should be assessed for its suitability for one or more of these paths.
  • Support model
    • How will services be provided? Will staff be trained, new staff hired, a service provider retained for ongoing operations, or will a consultant with cloud expertise be brought on board for a defined period? The appropriate support model is highly dependent on goals along with expected outcomes for different workloads.

Highlight risks and roadblocks

Formalize cloud vision

Document your cloud strategy

The Info-Tech difference:

  1. Determine the hypothesized value of cloud for your organization.
  2. Evaluate workloads with 6Rs framework.
  3. Identify and mitigate risks.
  4. Identify cloud archetype.
  5. Plot initiatives on a roadmap.
  6. Write action plan statement and goal statement.

What is the cloud, how is it deployed, and how is service provided?

Cloud Characteristics

  1. On-demand self-service: the ability to access reosurces instantly without vendor interaction
  2. Broad network access: all services delivered over the network
  3. Resource pooling: multi-tenant environment (shared)
  4. Rapid elasticity: the ability to expand and retract capabilities as needed
  5. Measured service: transparent metering

Service Model:

  1. Software-as-a-Service: all but the most minor configuration is done by the vendor
  2. Platform-as-a-Service: customer builds the application using tools provided by the provider
  3. Infrastructure-as-a-Service: the customer manages OS, storage, and the application

Delivery Model

  1. Public cloud: accessible to anyone over the internet; multi-tenant environment
  2. Private cloud: provisioned for a single organization with multiple units
  3. Hybrid cloud: two or more connected clouds; data is portage across them
  4. Community cloud: provisioned for a specific group of organizations

(National Institute of Standards and Technology)

A workload-first approach will allow you to take full advantage of the cloud’s strengths

  • Under all but the most exceptional circumstances, good cloud strategies will incorporate different service models. Very few organizations are “IaaS shops” or “SaaS shops,” even if they lean heavily in one direction.
  • These different service models (including non-cloud options like colocation and on-premises infrastructure) each have different strengths. Part of your cloud strategy should involve determining which of the services makes the most sense for you.
  • Own the cloud by understanding which cloud (or non-cloud!) offering makes the most sense for you given your unique context.

Migration paths

In a 2016 blog post, Amazon introduced a framework for understanding cloud migration strategies. The framework presented here is slightly modified – including a “relocate” component rather than a “retire” component – but otherwise hews close to the standard.

These migration paths reflect organizational capabilities and desired outcomes in terms of service models – cloud or otherwise. Retention means keeping the workload where it is, in a datacenter or a colocation service, or relocating to a colocation or hosted software environment. These represent the “non-cloud” migration paths.

In the graphic on the right, the paths within the red box lead to the cloud. Rehosting means lifting and shifting to an infrastructure environment. Migrating a virtual machine from your VMware environment on premises to Azure Virtual machines is a quick way to realize some benefits from the cloud. Migrating from SQL Server on premises to a cloud-based SQL solution looks a bit more like changing platforms (replatforming). It involves basic infrastructure modification without a substantial architectural component.

Refactoring is the most expensive of the options and involves engaging the software development lifecycle to build a custom solution, fundamentally rewriting the solution to be cloud native and take advantage of cloud-native architectures. This can result in a PaaS or an IaaS solution.

Finally, repurchasing means simply going to market and procuring a new solution. This may involve migrating data, but it does not require the migration of components.

Migration Paths

Retain (Revisit)

  • Keep the application in its current form, at least for now. This doesn’t preclude revisiting it in the future.

Relocate

  • Move the workload between datacenters or to a hosted software/colocation provider.

Rehost

  • Move the application to the cloud (IaaS) and continue to run it in more or less the same form as it currently runs.

Replatform

  • Move the application to the cloud and perform a few changes for cloud optimizations.

Refactor

  • Rewrite the application, taking advantage of cloud-native architectures.

Repurchase

  • Replace with an alternative, cloud-native application and migrate the data.

Support model

Support models by characteristic

Duration of engagement Specialization Flexibility
Internal IT Indefinite Varies based on nature of business Fixed, permanent staff
Managed Service Provider Contractually defined General, some specialization Standard offering
Consultant Project-based Specific, domain-based Entirely negotiable

IT services, including cloud services, can be delivered and managed in multiple ways depending on the nature of the workload and the organization’s intended path forward. Three high-level options are presented here and may be more or less valuable based on the duration of the expected engagement with the service (temporary or permanent), the skills specialization required, and the flexibility necessary to complete the job.

By way of example, a highly technical, short-term project with significant flexibility requirements might be a good fit for an expensive consultant, whereas post-implementation maintenance of a cloud email system requires relatively little specialization and flexibility and would therefore be a better fit for internal management.

There is no universally applicable rule here, but there are some workloads that are generally a good fit for the cloud and others that are not as effective, with that fit being conditional on the appropriate support model being employed.

Risks, roadblocks, and strategy components

No two cloud strategies are exactly alike, but all should address 14 key areas. A key step in defining your cloud vision is an assessment of these strategy components. Lower maturity does not preclude an aggressive cloud strategy, but it does indicate that higher effort will be required to make the transition.

Component Description Component Description
Monitoring What will system owners/administrators need visibility into? How will they achieve this? Vendor Management What practices must change to ensure effective management of cloud vendors?
Provisioning Who will be responsible for deploying cloud workloads? What governance will this process be subject to? Finance Management How will costs be managed with the transition away from capital expenditure?
Migration How will cloud migrations be conducted? What best practices/standards must be employed? Security What steps must be taken to ensure that cloud services meet security requirements?
Operations management What is the process for managing operations as they change in the cloud? Data Controls How will data residency, compliance, and protection requirements be met in the cloud?
Architecture What general principles must apply in the cloud environment? Skills and roles What skills become necessary in the cloud? What steps must be taken to acquire those skills?
Integration and interoperability How will services be integrated? What standards must apply? Culture and adoption Is there a cultural aversion to the cloud? What steps must be taken to ensure broad cloud acceptance?
Portfolio Management Who will be responsible for managing the growth of the cloud portfolio? Governing bodies What formal governance must be put in place? Who will be responsible for setting standards?

Cloud archetypes – a cloud vision component

Once you understand the value of the cloud, your workloads’ general suitability for cloud, and your proposed risks and mitigations, the next step is to define your cloud archetype.

Your organization’s cloud archetype is the strategic posture that IT adopts to best support the organization’s goals. Info-Tech’s model recognizes seven archetypes, divided into three high-level archetypes.

After consultation with your stakeholders, and based on the results of the suitability and risk assessment activities, define your archetype. The archetype feeds into the overall cloud vision and provides simple insight into the cloud future state for all stakeholders.

The cloud vision itself is captured in a “vision statement,” a short summary of the overall approach that includes the overall cloud archetype.

We can best support the organization's goals by:

More Cloud

Less Cloud

Cloud Focused Cloud-Centric Providing all workloads through cloud delivery.
Cloud-First Using the cloud as our default deployment model. For each workload, we should ask “why NOT cloud?”
Cloud Opportunistic Hybrid Enabling the ability to transition seamlessly between on-premises and cloud resources for many workloads.
Integrated Combining cloud and traditional infrastructure resources, integrating data and applications through APIs or middleware.
Split Using the cloud for some workloads and traditional infrastructure resources for others.
Cloud Averse Cloud-Light Using traditional infrastructure resources and limiting our use of the cloud to when it is absolutely necessary.
Anti-Cloud Using traditional infrastructure resources and avoiding use of the cloud wherever possible.

Info-Tech’s methodology for defining your cloud vision

1. Understand the Cloud 2. Assess Workloads 3. Identify and Mitigate Risks 4. Bridge the Gap and Create the Vision
Phase Steps
  1. Generate goals and drivers
  2. Explore cloud characteristics
  3. Create a current state summary
  4. Select workloads for analysis
  1. Conduct workload assessments
  2. Determine workload future state
  1. Generate risks and roadblocks
  2. Mitigate risks and roadblocks
  3. Define roadmap initiatives
  1. Review and assign work items
  2. Finalize cloud decision framework
  3. Create cloud vision
Phase Outcomes
  1. List of goals and drivers
  2. Shared understanding of cloud terms
  3. Current state of cloud in the organization
  4. List of workloads to be assessed
  1. Completed workload assessments
  2. Defined workload future state
  1. List of risks and roadblocks
  2. List of mitigations
  3. Defined roadmap initiatives
  1. Cloud roadmap
  2. Cloud decision framework
  3. Completed Cloud Vision Executive Presentation

Insight summary

The cloud may not be right for you – and that’s okay!

Don’t think about the cloud as an inevitable next step for all workloads. The cloud is merely another tool in the toolbox, ready to be used when appropriate and put away when it’s not needed. Cloud first isn’t always the way to go.

Not all clouds are equal

It’s not “should I go to the cloud?” but “what service and delivery models make sense based on my needs and risk tolerance?” Thinking about the cloud as a binary can force workloads into the cloud that don’t belong (and vice versa).

Bottom-up is best

A workload assessment is the only way to truly understand the cloud’s value. Work from the bottom up, not the top down, understand what characteristics make a workload cloud suitable, and strategize on that basis.

Your accountability doesn’t change

You are still accountable for maintaining available, secure, functional applications and services. Cloud providers share some responsibility, but the buck stops where it always has: with you.

Don’t customize for the sake of customization

SaaS providers make money selling the same thing to everyone. When migrating a workload to SaaS, work with stakeholders to pursue standardization around a selected platform and avoid customization where possible.

Best of both worlds, worst of both worlds

Hybrid clouds are in fashion, but true hybridity comes with additional cost, administration, and other constraints. A convoy moves at the speed of its slowest member.

The journey matters as much as the destination

How you get there is as important as what “there” actually is. Any strategy that focuses solely on the destination misses out on a key part of the value conversation: the migration strategy.

Blueprint benefits

Cloud Vision Executive Presentation

This presentation captures the results of the exercises and presents a complete vision to stakeholders including a desired target state, a rubric for decision making, the results of the workload assessments, and an overall risk profile.

Cloud Vision Workbook

This workbook includes the standard cloud workload assessment questionnaire along with the results of the assessment. It also includes the milestone timeline for the implementation of the cloud vision.

Blueprint benefits

IT Benefits

  • A consistent approach to the cloud takes the guesswork out of deployment decisions and makes it easier for IT to move on to the execution stage.
  • When properly incorporated, cloud services come with many benefits, including automation, elasticity, and alternative architectures (micro-services, containers). The cloud vision project will help IT readers articulate expected benefits and work towards achieving them.
  • A clear framework for incorporating organizational goals into cloud plans.

Business benefits

  • Simple, well-governed access to high-quality IT resources.
  • Access to the latest and greatest in technology to facilitate remote work.
  • Framework for cost management in the cloud that incorporates OpEx and chargebacks/showbacks. A clear understanding of expected changes to cost modeling is also a benefit of a cloud vision.
  • Clarity for stakeholders about IT’s response (and contribution to) IT strategic initiatives.

Measure the value of this blueprint

Don’t take our word for it:

  • The cloud vision material in various forms has been offered for several years, and members have generally benefited substantially, both from cloud vision workshops and from guided implementations led by analysts.
  • After each engagement, we send a survey that asks members how they benefited from the experience. Of 30 responses, the cloud vision research has received an average score of 9.8/10. Real members have found significant value in the process.
  • Additionally, members reported saving between 2 and 120 days (for an average of 17), and financial savings ranged from $1,920 all the way up to $1.27 million, for an average of $170,577.90! If we drop outliers on both ends, the average reported value of a cloud vision engagement is $37, 613.
  • Measure the value by calculating the time saved from using Info-Tech’s framework vs. a home-brewed cloud strategy alternative and by comparing the overall cost of a guided implementation or workshop with the equivalent offering from another firm. We’re confident you’ll come out ahead.

9.8/10 Average reported satisfaction

17 Days Average reported time savings

$37, 613 Average cost savings (adj.)

Executive Brief Case Study

Industry: Financial

Source: Info-Tech workshop

Anonymous financial institution

A small East Coast financial institution was required to develop a cloud strategy. This strategy had to meet several important requirements, including alignment with strategic priorities and best practices, along with regulatory compliance, including with the Office of the Comptroller of the Currency.

The bank already had a significant cloud footprint and was looking to organize and formalize the strategy going forward.

Leadership needed a comprehensive strategy that touched on key areas including the delivery model, service models, individual workload assessments, cost management, risk management and governance. The output had to be consumable by a variety of audiences with varying levels of technical expertise and had to speak to IT’s role in the broader strategic goals articulated earlier in the year.

Results

The bank engaged Info-Tech for a cloud vision workshop and worked through four days of exercises with various IT team members. The bank ultimately decided on a multi-cloud strategy that prioritized SaaS while also allowing for PaaS and IaaS solutions, along with some non-cloud hosted solutions, based on organizational circumstances.

Bank cloud vision

[Bank] will provide innovative financial and related services by taking advantage of the multiplicity of best-of-breed solutions available in the cloud. These solutions make it possible to benefit from industry-level innovations, while ensuring efficiency, redundancy, and enhanced security.

Bank cloud decision workflow

  • SaaS
    • Platform?
      • Yes
        • PaaS
      • No
        • Hosted
      • IaaS
        • Other

Non-cloud

Cloud

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

"Our team has already made this crticial project a priority, and we have the time and capability, but some guidance along the way would be helpful."

Guided Implementation

"Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track."

Workshop

"We need to hit the ground running and get this project kicked off imediately. Our team has the ability to take this over once we get a framework and strategy in place."

Consulting

"Our team does not have the time or the knowledge the take this project on. We need assistance through the entirety of this project."

Diagnostics and consistent frameworks are used throughout all four options.

Guided Implementation

What does a typical GI on this topic look like?

A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our best practices in your organization.

A typical GI is between 8 to 12 calls over the course of 4 to 6 months.

Phase 1

  • Call #1: Discuss current state, challenges, etc.
  • Call #2: Goals, drivers, and current state.

Phase 2

  • Call #3: Conduct cloud suitability assessment for selected workloads.

Phase 3

  • Call #4: Generate and categorize risks.
  • Call #5: Begin the risk mitigation conversation.

Phase 4

  • Call #6: Complete the risk mitigation process
  • Call #7: Finalize vision statement and cloud decision framework.

Workshop Overview

Contact your account representative for more information.

workshops@infotech.com 1-888-670-8889

Day 1 Day 2 Day 3 Day 4 Offsite day
Understand the cloud Assess workloads Identify and mitigate risks Bridge the gap and create the strategy Next steps and wrap-up (offsite)
Activities

1.1 Introduction

1.2 Generate corporate goals and cloud drivers

1.3 Identify success indicators

1.4 Explore cloud characteristics

1.5 Explore cloud service and delivery models

1.6 Define cloud support models and strategy components

1.7 Create current state summaries for the different service and delivery models

1.8 Select workloads for further analysis

2.1 Conduct workload assessments using the cloud strategy workbook tool

2.2 Discuss assessments and make preliminary determinations about workloads

3.1 Generate a list of risks and potential roadblocks associated with the cloud

3.2 Sort risks and roadblocks and define categories

3.3 Identify mitigations for each identified risk and roadblock

3.4 Generate initiatives from the mitigations

4.1 Review and assign work items

4.2 Finalize the decision framework for each of the following areas:

  • Service model
  • Delivery model
  • Support model

4.3 Create a cloud vision statement

5.1 Build the Cloud Vision Executive Presentation
Deliverables
  1. Corporate goals and cloud drivers
  2. Success indicators
  3. Current state summaries
  4. List of workloads for further analysis
  1. Completed workload assessments
  2. Workload summary statements
  1. List of risks and roadblocks, categorized
  2. List of mitigations
  3. List of initiatives
  1. Finalized task list
  2. Formal cloud decision rubric
  3. Cloud vision statement
  1. Completed cloud strategy executive presentation
  2. Completed cloud vision workbook

Understand the cloud

Build the foundations of your cloud vision

Phase 1

Phase 1

Understand the Cloud

Phase 1

1.1 Generate goals and drivers

1.2 Explore cloud characteristics

1.3 Create a current state summary

1.4 Select workloads for analysis

Phase 2

2.1 Conduct workload assessments

2.2 Determine workload future states

Phase 3

3.1 Generate risks and roadblocks

3.2 Mitigate risks and roadblocks

3.3 Define roadmap initiatives

Phase 4

4.1 Review and assign work items

4.2 Finalize cloud decision framework

4.3 Create cloud vision

This phase will walk you through the following activities:

1.1.1 Generate organizational goals

1.1.2 Define cloud drivers

1.1.3 Define success indicators

1.3.1 Record your current state

1.4.1 Select workloads for further assessment

This phase involves the following participants:

IT management, the core working group, security, infrastructure, operations, architecture, engineering, applications, non-IT stakeholders.

It starts with shared understanding

Stakeholders must agree on overall goals and what “cloud” means

The cloud is a nebulous term that can reasonably describe services ranging from infrastructure as a service as delivered by providers like Amazon Web Services and Microsoft through its Azure platform, right up to software as a service solutions like Jira or Salesforce. These solutions solve different problems – just because your CRM would be a good fit for a migration to Salesforce doesn’t mean the same system would make sense in Azure or AWS.

This is important because the language we use to talk about the cloud can color our approach to cloud services. A “cloud-first” strategy will mean something different to a CEO with a concept of the cloud rooted in Salesforce than it will to a system administrator who interprets it to mean a transition to cloud-hosted virtual machines.

Add to this the fact that not all cloud services are hosted externally by providers (public clouds) and the fact that multiple delivery models can be engaged at once through hybrid or multi-cloud approaches, and it’s apparent that a shared understanding of the cloud is necessary for a coherent strategy to take form.

This phase proceeds in four steps, each governed by the principle of shared understanding. The first requires a shared understanding of corporate goals and drivers. Step 2 involves coming to a shared understanding of the cloud’s unique characteristics. Step 3 requires a review of the current state. Finally, in Step 4, participants will identify workloads that are suitable for analysis as candidates for the cloud.

Step 1.1

Generate goals and drivers

Activities

1.1.1 Define organizational goals

1.1.2 Define cloud drivers

1.1.3 Define success indicators

Generate goals and drivers

Explore cloud characteristics

Create a current state summary

Select workloads for analysis

This step involves the following participants:

  • IT management
  • Core working group
  • Security
  • Applications
  • Infrastructure
  • Service management
  • Leadership

Outcomes of this step

  • List of organizational goals
  • List of cloud drivers
  • Defined success indicators

What can the cloud do for you?

The cloud is not valuable for its own sake, and not all users derive the same value

  • The cloud is characterized by on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Any or all of those characteristics might be enough to make the cloud appealing, but in most cases, there is an overriding driver.
  • Multiple paths may lead to the cloud. Consider an organization with a need to control costs by showing back to business units, or perhaps by reducing capital expenditure – the cloud may be the most appropriate way to effect these changes. Conversely, an organization expanding rapidly and with a need to access the latest and greatest technology might benefit from the elasticity and pooled resources that major cloud providers can offer.
  • In these cases, the destination might be the same (a cloud solution) but the delivery model – public, private, or hybrid – and the decisions made around the key strategy components, including architecture, provisioning, and cost management, will almost certainly be different.
  • Defining goals, understanding cloud drivers, and – crucially – understanding what success means, are all therefore essential elements of the cloud vision process.

1.1.1 Generate organizational goals

1-3 hours

Input

  • Strategy documentation

Output

  • Organizational goals

Materials

  • Whiteboard (digital/physical)

Participants

  • IT leadership
  • Infrastructure
  • Applications
  • Security
  1. As a group, brainstorm organizational goals, ideally based on existing documentation
    • Review relevant corporate and IT strategies.
    • If you do not have access to internal documentation, review the standard goals on the next slide and select those that are most relevant for you.
  2. Record the most important business goals in the Cloud Vision Executive Presentation. Include descriptions where possible to ensure wide readability.
  3. Make note of these goals. They should inform the answers to prompts offered in the Cloud Vision Workbook and should be a consistent presence in the remainder of the visioning exercise. If you’re conducting the session in person, leave the goals up on a whiteboard and make reference to them throughout the workshop.

Cloud Vision Executive Presentation

Standard COBIT 19 enterprise goals

  1. Portfolio of competitive products and services
  2. Managed business risk
  3. Compliance with external laws and regulations
  4. Quality of financial information
  5. Customer-oriented service culture
  6. Business service continuity and availability
  7. Quality of management information
  8. Optimization of internal business process functionality
  9. Optimization of business process costs
  10. Staff skills, motivation, and productivity
  11. Compliance with internal policies
  12. Managed digital transformation programs
  13. Product and business innovation

1.1.2 Define cloud drivers

30-60 minutes

Input

  • Organizational goals
  • Strategy documentation
  • Management/staff perspective

Output

  • List of cloud drivers

Materials

  • Sticky notes
  • Whiteboard
  • Markers

Participants

  • IT leadership
  • Infrastructure
  • Applications
  • Security
  1. Cloud drivers sit at a level of abstraction below organizational goals. Keeping your organizational goals in mind, have each participant in the session write down how they expect to benefit from the cloud on a sticky note.
  2. Solicit input one at a time and group similar responses. Encourage participants to bring forward their cloud goals even if similar goals have been mentioned previously. The number of mentions is a useful way to gauge the relative weight of the drivers.
  3. Once this is done, you should have a few groups of similar drivers. Work with the group to name each category. This name will be the driver reported in the documentation.
  4. Input the results of the exercise into the Cloud Vision Executive Presentation, and include descriptions based on the constituent drivers. For example, if a driver is titled “do more valuable work,” the constituent drivers might be “build cloud skills,” “focus on core products,” and “avoid administration work where possible.” The description would be based on these components.

Cloud Vision Executive Presentation

1.1.3 Define success indicators

1 hour

Input

  • Cloud drivers
  • Organizational goals

Output

  • List of cloud driver success indicators

Materials

  • Whiteboard
  • Markers

Participants

  • IT leadership
  • Infrastructure
  • Applications
  • Security
  1. On a whiteboard, draw a table with each of the cloud drivers (identified in 1.1.2) across the top.
  2. Work collectively to generate success indicators for each cloud driver. In this case, a success indicator is some way you can report your progress with the stated driver. It is a real-world proxy for the sometimes abstract phenomena that make up your drivers. Think about what would be true if your driver was realized.
    1. For example, if your driver is “faster access to resources,” you might consider indicators like developer satisfaction, project completion time, average time to provision, etc.
  3. Once you are satisfied with your list of indicators, populate the slide in the Cloud Vision Executive Presentation for validation from stakeholders.

Cloud Vision Executive Presentation

Step 1.2

Explore cloud characteristics

Activities

Understand the value of the cloud:

  • Review delivery models
  • Review support models
  • Review service models
  • Review migration paths

Understand the Cloud

Generate goals and drivers

Explore cloud characteristics

Create a current state summary

Select workloads for analysis

This step involves the following participants:

  • Core working group
  • Architecture
  • Engineering
  • Security

Outcomes of this step

  • Understanding of cloud service models and value

Defining the cloud

Per NIST, the cloud has five fundamental characteristics. All clouds have these characteristics, even if they are executed in somewhat different ways between delivery models, service models, and even individual providers.

Cloud characteristics

On-demand self-service

Cloud customers are capable of provisioning cloud resources without human interaction (e.g. contacting sales), generally through a web console.

Broad network access

Capabilities are designed to be delivered over a network and are generally intended for access by a wide variety of platform types (cloud services are generally device-agnostic).

Resource pooling

Multiple customers (internal, in the case of private clouds) make use of a highly abstracted shared infrastructure managed by the cloud provider.

Rapid elasticity

Customers are capable of provisioning additional resources as required, pulling from a functionally infinite pool of capacity. Cloud resources can be spun-down when no longer needed.

Measured service

Consumption is metered based on an appropriate unit of analysis (number of licenses, storage used, compute cycles, etc.) and billing is transparent and granular.

Cloud delivery models

The NIST definition of cloud computing outlines four cloud delivery models: public, private, hybrid, and community clouds. A community cloud is like a private cloud, but it is provisioned for the exclusive use of a like-minded group of organizations, usually in a mutually beneficial, non-competitive arrangement. Universities and hospitals are examples of organizations that can pool their resources in this way without impacting competitiveness. The Info-Tech model covers three key delivery models – public, private, and hybrid, and an overarching model (multi-cloud) that can comprise more than one of the other models – public + public, public + hybrid, etc.

Public

The cloud service is provisioned for access by the general public (customers).

Private

A private cloud has the five key characteristics, but is provisioned for use by a single entity, like a company or organization.

Hybrid

Hybridity essentially refers to interoperability between multiple cloud delivery models (public +private).

Multi

A multi-cloud deployment requires only that multiple clouds are used without any necessary interoperability (Nutanix, 2019).

Public cloud

This is what people generally think about when they talk about cloud

  • The public cloud is, well, public! Anyone can make use of its resources, and in the case of the major providers, capacity is functionally unlimited. Need to store exabytes of data in the cloud? No problem! Amazon will drive a modified shipping container to your datacenter, load it up, and “migrate” it to a datacenter.
  • Public clouds offer significant variety on the infrastructure side. Major IaaS providers, like Microsoft and Amazon, offer dozens of services across many different categories including compute, networking, and storage, but also identity, containers, machine learning, virtual desktops, and much, much more. (See a list from Microsoft here, and Amazon here)
  • There are undoubtedly strengths to the public cloud model. Providers offer the “latest and greatest” and customers need not worry about the details, including managing infrastructure and physical locations. Providers offer built-in redundancy, multi-regional deployments, automation tools, management and governance solutions, and a variety of leading-edge technologies that would not be feasible for organizations to run in-house, like high performance compute, blockchain, or quantum computing.
  • Of course, the public cloud is not all sunshine and rainbows – there are downsides as well. It can be expensive; it can introduce regulatory complications to have to trust another entity with your key information. Additionally, there can be performance hiccups, and with SaaS products, it can be difficult to monitor at the appropriate (per-transaction) level.

Prominent examples include:

AWS

Microsoft

Azure

Salesforce.com

Workday

SAP

Private cloud

A lower-risk cloud for cloud-averse customers?

  • A cloud is a cloud, no matter how small. Some IT shops deploy private clouds that make use of the five key cloud characteristics but provisioned for the exclusive use of a single entity, like a corporation.
  • Private clouds have numerous benefits. Some potential cloud customers might be uncomfortable with the shared responsibility that is inherent in the public cloud. Private clouds allow customers to deliver flexible, measured services without having to surrender control, but they require significant overhead, capital expenditure, administrative effort, and technical expertise.
  • According to the 2021 State of the Cloud Report, private cloud use is common, and the most frequently cited toolset is VMware vSphere, followed by Azure Stack, OpenStack, and AWS Outposts. Private cloud deployments are more common in larger organizations, which makes sense given the overhead required to manage such an environment.

Private cloud adoption

The images shows a graph titled Private Cloud Adoption for Enterprises. It is a horizontal bar graph, with three segments in each bar: dark blue marking currently use; mid blue marking experimenting; and light blue marking plan to use.

VMware and Microsoft lead the pack among private cloud customers, with Amazon and Red Hat also substantially present across private cloud environments.

Hybrid cloud

The best of both worlds?

Hybrid cloud architectures combine multiple cloud delivery models and facilitate some level of interoperability. NIST suggests bursting and load balancing as examples of hybrid cloud use cases. Note: it is not sufficient to simply have multiple clouds running in parallel – there must be a toolset that allows for an element of cross-cloud functionality.

This delivery model is attractive because it allows users to take advantage of the strengths of multiple service models using a single management pane. Bursting across clouds to take advantage of additional capacity or disaster recovery capabilities are two obvious use cases that appeal to hybrid cloud users.

But while hybridity is all the rage (especially given the impact Covid-19 has had on the workplace), the reality is that any hybrid cloud user must take the good with the bad. Multiple clouds and a management layer can be technically complex, expensive, and require maintaining a physical infrastructure that is not especially valuable (“I thought we were moving to the cloud to get out of the datacenter!”).

Before selecting a hybrid approach through services like VMware Cloud on AWS or Microsoft’s Azure Stack, consider the cost, complexity, and actual expected benefit.

Amazon, Microsoft, and Google dominate public cloud IaaS, but IBM is betting big on hybrid cloud:

The image is a screencap of a tweet from IBM News. The tweet reads: IBM CEO Ginni Rometty: Hybrid cloud is a trillion dollar market and we'll be number one #Think2019.

With its acquisition of Red Hat in 2019 for $34 billion, Big Blue put its money where its mouth is and acquired a substantial hybrid cloud business. At the time of the acquisition, Red Hat’s CEO, Jim Whitehurst, spoke about the benefit IBM expected to receive:

“Joining forces with IBM gives Red Hat the opportunity to bring more open source innovation to an even broader range of organizations and will enable us to scale to meet the need for hybrid cloud solutions that deliver true choice and agility” (Red Hat, 2019).

Multi-cloud

For most organizations, the multi-cloud is the most realistic option.

Multi-cloud is popular!

The image shows a graph titled Multi-Cloud Architectures Used, % of all Respondents. The largest percentage is Apps siloed on different clouds, followed by DAta integration between clouds.

Multi-cloud solutions exist at a different layer of abstraction from public, private, and even hybrid cloud delivery models. A multi-cloud architecture, as the name suggests, requires the user to be a customer of more than one cloud provider, and it can certainly include a hybrid cloud deployment, but it is not bound by the same rules of interoperability.

Many organizations – especially those with fewer resources or a lack of a use case for a private cloud – rely on a multi-cloud architecture to build applications where they belong, and they manage each environment separately (or occasionally with the help of cloud management platforms).

If your data team wants to work in AWS and your enterprise services run on basic virtual machines in Azure, that might be the most effective architecture. As the Flexera 2021 State of the Cloud Report suggests, this architecture is far more common than the more complicated bursting or brokering architectures characteristic of hybrid clouds.

NIST cloud service models

Software as a service

SaaS has exploded in popularity with consumers who wish to avail themselves of the cloud’s benefits without having to manage underlying infrastructure components. SaaS is simple, generally billed per-user per-month, and is almost entirely provider-managed.

Platform as a service

PaaS providers offer a toolset for their customers to run custom applications and services without the requirement to manage underlying infrastructure components. This service model is ideal for custom applications/services that don’t benefit from highly granular infrastructure control.

Infrastructure as a service

IaaS represents the sale of components. Instead of a service, IaaS providers sell access to components, like compute, storage, and networking, allowing for customers to build anything they want on top of the providers’ infrastructure.

Cloud service models

  • This research focuses on five key service models, each of which has its own strengths and weaknesses. Moving right from “on-prem,” customers gradually give up more control over their environments to cloud service providers.
  • An entirely premises-based environment means that the customer is responsible for everything ranging from the dirt under the datacenter to application-level configurations. Conversely, in a SaaS environment, the provider is responsible for everything but those top-level application configurations.
  • A managed service provider or other third party can manage any or of the components of the infrastructure stack. A service provider may, for example, build a SaaS solution on top of another provider’s IaaS, or might offer configuration assistance with a commercially available SaaS.

Info-Tech Insight

Not all workloads fit well in the cloud. Many environments will mix service models (e.g. SaaS for some workloads, some in IaaS, some on-premises), and this can be perfectly effective. It must be consistent and intentional, however.

On-prem Co-Lo IaaS PaaS SaaS
Application Application Application Application Application
Database Database Database Database Database
Runtime/ Middleware Runtime/ Middleware Runtime/ Middleware Runtime/ Middleware Runtime/ Middleware
OS OS OS OS OS
Hypervisor Hypervisor Hypervisor Hypervisor Hypervisor
Server Network Storage Server Network Storage Server Network Storage Server Network Storage Server Network Storage
Facilities Facilities Facilities Facilities Facilities

Organization has control

Organization or vendor may control

Vendor has control

Analytics folly

SaaS is good, but it’s not a panacea

Industry: Healthcare

Source: Info-Tech workshop

Situation

A healthcare analytics provider had already moved a significant number of “non-core workloads” to the cloud, including email, HRIS, and related services.

The company CEO was satisfied with the reduced effort required by IT to manage SaaS-based workloads and sought to extend the same benefits to the core analytics platform where there was an opportunity to reduce overhead.

Complication

Many components of the health analytics service were designed to run specifically in a datacenter and were not ready to be migrated to the cloud without significant effort/refactoring. SaaS was not an option because this was a core platform – a SaaS provider would have been the competition.

That left IaaS, which was expensive and would not bring the expected benefits (reduced overhead).

Results

The organization determined that there were no short-term gains from migrating to the cloud. Due to the nature of the application (its extensive customization, the fact that it was a core product sold by the company) any steps to reduce operational overhead were not feasible.

The CEO recognized that the analytics platform was not a good candidate for the cloud and what distinguished the analytics platform from more suitable workloads.

Migration paths

In a 2016 blog post, Amazon Web Services articulated a framework for cloud migration that incorporates elements of the journey as well as the destination. If workload owners do not choose to retain or retire their workloads, there are four alternatives. These alternatives all stack up differently along five key dimensions:

  1. Value: does the workload stand to benefit from unique cloud characteristics? To what degree?
  2. Effort: how much work would be required to make the transition?
  3. Cost: how much money is the migration expected to cost?
  4. Time: how long will the migration take?
  5. Skills: what skills must be brought to bear to complete the migration?

Not all migration paths can lead to all destinations. Rehosting generally means IaaS, while repurchasing leads to SaaS. Refactoring and replatforming have some variety of outcomes, and it becomes possible to take advantage of new IaaS architectures or migrate workloads over fully to SaaS.

As part of the workload assessment process, use the five dimensions (expanded upon on the next slide) to determine what migration path makes sense. Preferred migration paths form an important part of the overall cloud vision process.

Retain (Revisit)

  • Keep the application in its current form, at least for now. This doesn’t preclude revisiting it in the future.

Retire

  • Get rid of the application completely.

Rehost

  • Move the application to the cloud (IaaS) and continue to run it in more or less the same form as it currently runs.

Replatform

  • Move the application to the cloud and perform a few changes for cloud optimizations.

Refactor

  • Rewrite the application, taking advantage of cloud native architectures.

Repurchase

  • Replace with an alternative, cloud-native application and migrate the data.

Migration paths – relative value

Migration path Value Effort Cost Time Skills
Retain No real change in the absolute value of the workload if it is retained. No effort beyond ongoing workload maintenance. No immediate hard dollar costs, but opportunity costs and technical debt abound. No time required! (At least not right away…) Retaining requires the same skills it has always required (which may be more difficult to acquire in the future).
Rehire A retired workload can provide no value, but it is not a drain! Spinning a service down requires engaging that part of the lifecycle. N/A Retiring the service may be simple or complicated depending on its current role. N/A
Rehost Some value comes with rehosting, but generally components stay the same (VM here vs. a VM there). Minimal effort required, especially with automated tools. The effort will depend on the environment being migrated. Relatively cheap compared to other options. Rehosting infrastructure is the simplest cloud migration path and is useful for anyone in a hurry. Rehosting is the simplest cloud migration path for most workloads, but it does require basic familiarity with cloud IaaS.

Replatform

Replatformed workloads can take advantage of cloud-native services (SQL vs. SQLaaS). Replatforming is more effortful than rehosting, but less effortful than refactoring. Moderate cost – does not require fundamental rearchitecture, just some tweaking. Relatively more complicated than a simple rehost, but less demanding than a refactor. Platform and workload expertise is required; more substantial than a simple rehost.
Refactor A fully formed, customized cloud-based workload that can take advantage of cloud-native architectures is generally quite valuable. Significant effort required based on the requirement to engage the full SDLC. Significant cost required to engage SDLC and rebuild the application/service. The most complicated and time-consuming. The most complicated and time-consuming.
Repurchase Repurchasing is the quickest way to achieve cloud-native value. There are compromises, however (high cost, vendor-lock-in). Repurchasing is the quickest way to achieve cloud-native value. There are compromises, however (high cost, vendor-lock-in). Repurchasing is the quickest way to achieve cloud-native value. There are compromises, however (high cost, vendor-lock-in). Configuration – especially for massive projects – can be time consuming, but in general repurchasing can be quite fast. Buying software does require knowledge of requirements and integrations, but is otherwise quite simple.

Where should you get your cloud skills?

Cloud skills are certainly top of mind right now. With the great upheaval in both work patterns and in the labor market more generally, expertise in cloud-related areas is simultaneously more valuable and more difficult to procure. According to Pluralsight’s 2021 “State of Upskilling” report, 44% of respondents report themselves under-skilled in the cloud management area, making cloud management the most significant skill gap reported on the survey.

Everyone left the office. Work as we know it is fundamentally altered for a generation or more. Cloud services shot up in popularity by enabling the transition. And yet there is a gap – a prominent gap – in skilling up for this critically important future. What is the cloud manager to do?

Per the framework presented here, that manager has three essential options. They may take somewhat different forms depending on specific requirements and the quirks of the local market, but the options are:

  1. Train or hire internal resources: This might be easier said than done, especially for more niche skills, but makes sense for workloads that are critical to operations for the long term.
  2. Engage a managed service provider: MSPs are often engaged to manage services where internal IT lacks bandwidth or expertise.
  3. Hire a consultant: Consultants are great for time-bound implementation projects where highly specific expertise is required, such as a migration or implementation project.

Each model makes sense to some degree. When evaluating individual workloads for cloud suitability, it is critical to consider the support model – both immediate and long term. What makes sense from a value perspective?

Cloud decisions – summary

A key component of the Info-Tech cloud vision model is that it is multi-layered. Not every decision must be made at every level. At the workload level, it makes sense to select service models that make sense, but each workload does not need its own defined vision. Workload-level decisions should be guided by an overall strategy but applied tactically, based on individual workload characteristics and circumstances.

Conversely, some decisions will inevitably be applied at the environment level. With some exceptions, it is unlikely that cloud customers will build an entire private/hybrid cloud environment around a single solution; instead, they will define a broader strategy and fit individual workloads into that strategy.

Some considerations exist at both the workload and environment levels. Risks and roadblocks, as well as the preferred support model, are concerns that exist at both the environment level and at the workload level.

The image is a Venn diagram, with the left side titled Workload level, and the right side titled Environment Level. In the left section are: service model and migration path. On the right section are: Overall vision and Delivery model. In the centre section are: support model and Risks and roadblocks.

Step 1.3

Create a current state summary

Activities

1.3.1 Record your current state

Understand the Cloud

Generate goals and drivers

Explore cloud characteristics

Create a current state summary

Select workloads for analysis

This step involves the following participants: Core working group

Outcomes of this step

  • Current state summary of cloud solutions

1.3.1 Record your current state

30 minutes

Input

  • Knowledge of existing cloud workloads

Output

  • Current state cloud summary for service, delivery, and support models

Materials

  • Whiteboard

Participants

  • Core working group
  • Infrastructure team
  • Service owners
  1. On a whiteboard (real or virtual) draw a table with each of the cloud service models across the top. Leave a cell below each to list examples.
  2. Under each service model, record examples present in your environment. The purpose of the exercise is to illustrate the existence of cloud services in your environment or the lack thereof, so there is no need to be exhaustive. Complete this in turn for each service model until you are satisfied that you have created an effective picture of your current cloud SaaS state, IaaS state, etc.
  3. Input the results into their own slide titled “current state summary” in the Cloud Vision Executive Presentation.
  4. Repeat for the cloud delivery models and support models and include the results of those exercises as well.
  5. Create a short summary statement (“We are primarily a public cloud consumer with a large SaaS footprint and minimal presence in PaaS and IaaS. We retain an MSP to manage our hosted telephony solution; otherwise, everything is handled in house.”

Cloud Vision Executive Presentation

Step 1.4

Select workloads for current analysis

Activities

1.4.1 Select workloads for assessment

This step involves the following participants:

  • Core working group

Outcomes of this step

  • List of workloads for assessment

Understand the cloud

Generate goals and drivers

Explore cloud characteristics

Create a current state summary

Select workloads for analysis

1.4.1 Select workloads for assessment

30 minutes

Input

  • Knowledge of existing cloud workloads

Output

  • List of workloads to be assessed

Materials

  • Whiteboard
  • Cloud Vision Workbook

Participants

  • Core working group
  • IT management
  1. In many cases, the cloud project is inspired by a desire to move a particular workload or set of workloads. Solicit feedback from the core working group about what these workloads might be. Ask everyone in the meeting to suggest a workload and record each one on a sticky note or white board (virtual or physical).
  2. Discuss the results with the group and begin grouping similar workloads together. They will be subject to the assessments in the Cloud Vision Workbook, so try to avoid selecting too many workloads that will produce similar answers. It might not be obvious, but try to think about workloads that have similar usage patterns, risk levels, and performance requirements, and select a representative group.
  3. You should embrace counterintuition by selecting a workload that you think is unlikely to be a good fit for the cloud if you can and subjecting it to the assessment as well for validation purposes.
  4. When you have a list of 4-6 workloads, record them on tab 2 of the Cloud Vision Workbook.

Cloud Vision Workbook

Assess your cloud workloads

Build the foundations of your cloud vision

Phase 2

Phase 2

Evaluate Cloud Workloads

Phase 1

1.1 Generate goals and drivers

1.2 Explore cloud characteristics

1.3 Create a current state summary

1.4 Select workloads for analysis

Phase 2

2.1 Conduct workload assessments

2.2 Determine workload future states

Phase 3

3.1 Generate risks and roadblocks

3.2 Mitigate risks and roadblocks

3.3 Define roadmap initiatives

Phase 4

4.1 Review and assign work items

4.2 Finalize cloud decision framework

4.3 Create cloud vision

This phase will walk you through the following activities:

  • Conduct workload assessments
  • Determine workload future state

This phase involves the following participants:

  • Subject matter experts
  • Core working group
  • IT management

Define Your Cloud Vision

Work from the bottom up and assess your workloads

A workload-first approach will help you create a realistic vision.

The concept of a cloud vision should unquestionably be informed by the nature of the workloads that IT is expected to provide for the wider organization. The overall cloud vision is no greater than the sum of its parts. You cannot migrate to the cloud in the abstract. Workloads need to go – and not all workloads are equally suitable for the transition.

It is therefore imperative to understand which workloads are a good fit for the cloud, which cloud service models make the most sense, how to execute the migration, what support should look like, and what risks and roadblocks you are likely to encounter as part of the process.

That’s where the Cloud Vision Workbook comes into play. You can use this tool to assess as many workloads as you’d like – most people get the idea after about four – and by the end of the exercise, you should have a pretty good idea about where your workloads belong, and you’ll have a tool to assess any net new or previously unconsidered workloads.

It’s not so much about the results of the assessment – though these are undeniably important – but about the learnings gleaned from the collaborative assessment exercise. While you can certainly fill out the assessment without any additional input, this exercise is most effective when completed as part of a group.

Introducing the Cloud Vision Workbook

  • The Cloud Vision Workbook is an Excel tool that answers the age old question: “What should I do with my workloads?”
  • It is divided into eight tabs, each of which offers unique value. Start by reading the introduction and inputting your list of workloads. Work your way through tabs 3-6, completing the suitability, migration, management, and risk and roadblock assessments, and review the results on tab 7.
  • If you choose to go through the full battery of assessments for each workload, expect to answer and weight 111 unique questions across the four assessments. This is an intensive exercise, so carefully consider which assessments are valuable to you, and what workloads you have time to assess.
  • Tab 8 hosts the milestone timeline and captures the results of the phase 3 risk and mitigation exercise.

Understand Cloud Vision Workbook outputs

The image shows a graphic with several graphs and lists on it, with sections highlighted with notes. At the top, there's the title Database with the note Workload title (populated from tab 2). Below that, there is a graph with the note Relative suitability of the five service models. The Risks and roadblocks section includes the note: The strategy components – the risks and roadblocks – are captured relative to one another to highlight key focus areas. To the left of that, there is a Notes section with the note Notes populated based on post-assessment discussion. At the bottom, there is a section titled Where should skills be procured?, with the note The radar diagram captures the recommended support model relative to the others (MSP, consultant, internal IT). To the right of that, there is a section titled Migration path, with the note that Ordered list of migration paths. Note: a disconnect here with the suggested service model may indicate an unrealistic goal state.

Step 2.1

Conduct workload assessments

Activities

2.1.1 Conduct workload assessments

2.1.2 Interpret your results

Phase Title

Conduct workload assessments

Determine workload future state

This step involves the following participants:

  • Core working group
  • Workload subject matter experts

Outcomes of this step

  • Completed workload assessments

2.1.1 Conduct workload assessments

2 hours per workload

Input

  • List of workloads to be assessed

Output

  • Completed cloud vision assessments

Materials

  • Cloud Vision Workbook

Participants

  • Core working group
  • Service owners/workload SMEs
  1. The Cloud Vision Workbook is your one stop shop for all things workload assessment. Open the tool to tab 2 and review the workloads you identified at the end of phase 1. Ensure that these are correct. Once satisfied, project the tool (virtually, if necessary) so that all participants can see the assessment questions.
  2. Work through tabs 3-6, answering the questions and assigning a multiplier for each one. A higher multiplier increases the relative weight of the question, giving it a greater impact on the overall outcome.
  3. Do your best to induce participants to offer opinions. Consensus is not absolutely necessary, but it is a good goal. Ask your participants if they agree with initial responses and occasionally take the opposite position (“I’m surprised you said agree – I would have thought we didn’t care about CapEx vs. OpEx”). Stimulate discussion.
  4. Highlight any questions that you will need to return to or run by someone not present. Include a placeholder answer, as the tool requires all cells to be filled for computation.

Cloud Vision Workbook

2.1.2 Interpret your results

10 minutes

Input

  • Completed cloud vision assessments

Output

  • Shared understanding of implications

Materials

  • Cloud Vision Workbook

Participants

  • Core working group
  • Service owners/workload SMEs
  1. Once you’ve completed all 111 questions for each workload, you can review your results on tab 7. On tab 7, you will see four populated graphics: cloud suitability, migration path, “where should skills be procured?”, and risks and roadblocks. These represent the components of the overall cloud vision that you will present to stakeholders.
  2. The “cloud suitability” chart captures the service model that the assessment judges to be most suitable for the workload. Ask those present if any are surprised by the output. If there is any disagreement, discuss the source of the surprise and what a more realistic outcome would be. Revisit the assessment if necessary.
  3. Conduct a similar exercise with each of the other outputs. Does it make sense to refactor the workload based on its cloud suitability? Does the fact that we scored so highly on the “consultant” support model indicate something about how we handle upskilling internally? Does the profile of risks and roadblocks identified here align with expectations? What should be ranked higher? What about lower?
  4. Once everyone is generally satisfied with the results, close the tool and take a break! You’ve earned it.

Cloud Vision Workbook

Understand the cloud strategy components

Each cloud strategy will take a slightly different form, but all should contain echoes of each of these components. This process will help you define your vision and direction, but you will need to take steps to execute on that vision. The remainder of the cloud strategy, covered in the related blueprint Document Your Cloud Strategy comprises these fourteen topics divided across three categories: people, governance, and technology. The workload assessment covers these under risks and roadblocks and highlights areas that may require specific additional attention. When interpreting the results, think of these areas as comprising things that you will need to do to make your vision a reality.

People

  • Skills and roles
  • Culture and adoption
  • Governing bodies

Governance

  • Architecture
  • Integration and interoperability
  • Operations management
  • Cloud portfolio management
  • Cloud vendor management
  • Finance management
  • Security
  • Data controls

Technology

  • Monitoring
  • Provisioning
  • Migration

Strategy component: People

People form the core of any good strategy. As part of your cloud vision, you will need to understand the implications a cloud transition will have on your staff and users, whether those users are internal or external.

Component Description Challenges
Skills and roles The move to the cloud will require staff to learn how to handle new technology and new operational processes. The cloud is a different way of procuring IT resources and may require the definition of new roles to handle things like cost management and provisioning. Staff may not have the necessary experience to migrate to a cloud environment or to effectively manage resources once the cloud transition is made. Cloud skills are difficult to hire for, and with the ever-changing nature of the platforms themselves, this shows no sign of abating. Redefining roles can also be politically challenging and should be done with due care and consideration.
Culture and adoption If you build it, they will come…right? It is not always the case that a new service immediately attracts users. Ensuring that organizational culture aligns with the cloud vision is a critical success factor. Equally important is ensuring that cloud resources are used as intended. Those unfamiliar with cloud resources may be less willing to learn to use them. If alternatives exist (e.g. a legacy service that has not been shut down), or if those detractors are influential, this resistance may impede your cloud execution. Also, if the cloud transition involves significant effort or a fundamental rework (e.g. a DevOps transition) this role redefinition could cause some internal turmoil.
Governing bodies A large-scale cloud deployment requires formal governance. Formal governance requires a governing body that is ultimately responsible for designing the said governance. This could take the form of a “center of excellence” or may rest with a single cloud architect in a smaller, less complicated environment. Governance is difficult. Defining responsibilities in a way that includes all relevant stakeholders without paralyzing the decision-making process is difficult. Implementing suggestions is a challenge. Navigating the changing nature of service provision (who can provision their own instances or assign licenses?) can be difficult as well. All these concerns must be addressed in a cloud strategy.

Strategy component: Governance

Without guardrails, the cloud deployment will grow organically. This has strengths (people tend to adopt solutions that they select and deploy themselves), but these are more than balanced out by the drawbacks that come with inconsistency, poor administration, duplication of services, suboptimal costing, and any number of other unique challenges. The solution is to develop and deploy governance. The following list captures some of the necessary governance-related components of a cloud strategy.

Component Description Challenges
Architecture Enterprise architecture is an important function in any environment with more than one interacting workload component (read: any environment). The cloud strategy should include an approach to defining and implementing a standard cloud architecture and should assign responsibility to an individual or group. Sometimes the cloud transition is inspired by the desire to rearchitect. The necessary skills and knowledge may not be readily available to design and transition to a microservices-based environment, for example, vs. a traditional monolithic application architecture. The appropriateness of a serverless environment may not be well understood, and it may be the case that architects are unfamiliar with cloud best practices and reference architectures.
Integration and interoperability Many services are only highly functional when integrated with other services. What is a database without its front-end? What is an analytics platform without its data lake? For the cloud vision to be properly implemented, a strategy for handling integration and interoperability must be developed. It may be as simple as “all SaaS apps must be compatible with Okta” but it must be there. Migration to the cloud may require a fundamentally new approach to integration, moving away from a point-to-point integrations and towards an ESB or data lake. In many cases, this is easier said than done. Centralization of management may be appealing, but legacy applications – or those acquired informally in a one-off fashion – might not be so easy to integrate into a central management platform.
Operations management Service management (ITIL processes) must be aligned with your overall cloud strategy. Migrating to the cloud (where applicable) will require refining these processes, including incident, problem, request, change, and configuration management, to make them more suitable for the cloud environment. Operations management doesn’t go away in the cloud, but it does change in line with the transition to shared responsibility. Responding to incidents may be more difficult on the cloud when troubleshooting is a vendor’s responsibility. Change management in a SaaS environment may be more receptive than staff are used to as cloud providers push changes out that cannot be rolled back.

Strategy component: Governance (cont.)

Component Description Challenges
Cloud portfolio management This component refers to the act of managing the portfolio of cloud services that is available to IT and to business users. What requirements must a SaaS service meet to be onboarded into the environment? How do we account for exceptions to our IaaS policy? What about services that are only available from a certain provider? Rationalizing services offers administrative benefits, but may make some tasks more difficult for end users who have learned things a certain way or rely on niche toolsets. Managing access through a service catalog can also be challenging based on buy-in and ongoing administration. It is necessary to develop and implement policy.
Cloud vendor management Who owns the vendor management function, and what do their duties entail? What contract language must be standard? What does due diligence look like? How should negotiations be conducted? What does a severing of the relationship look like? Cloud service models are generally different from traditional hosted software and even from each other (e.g. SaaS vs. PaaS). There is a bit of a learning curve when it comes to dealing with vendors. Also relevant: the skills that it takes to build and maintain a system are not necessarily the same as those required to coherently interact with a cloud vendor.
Finance management Cloud services are, by definition, subject to a kind of granular, operational billing that many shops might not be used to. Someone will need to accurately project and allocate costs, while ensuring that services are monitored for cost abnormalities. Cloud cost challenges often relate to overall expense (“the cloud is more expensive than an alternative solution”), expense variability (“I don’t know what my budget needs to be this quarter”), and cost complexity (“I don’t understand what I’m paying for – what’s an Elastic Beanstalk?”).
Security The cloud is not inherently more or less secure than a premises-based alternative, though the risk profile can be different. Applying appropriate security governance to ensure workloads are compliant with security requirements is an essential component of the strategy.

Technical security architecture can be a challenge, as well as navigating the shared responsibility that comes with a cloud transition. There are also a plethora of cloud-specific security tools like cloud access security brokers (CASBs), cloud security posture management (CSPM) solutions, and even secure access services edge (SASE) technology.

Data controls Data residency, classification, quality, and protection are important considerations for any cloud strategy. With cloud providers taking on outsized responsibility, understanding and governing data is essential. Cloud providers like to abstract away from the end user, and while some may be able to guarantee residency, others may not. Additionally, regulations may prevent some data from going to the cloud, and you may need to develop a new organizational backup strategy to account for the cloud.

Strategy component: Technology

Good technology will never replace good people and effective process, but it remains important in its own right. A migration that neglects the undeniable technical components of a solid cloud strategy is doomed to mediocrity at best and failure at worst. Understanding the technical implications of the cloud vision – particularly in terms of monitoring, provisioning, and migration – makes all the difference. You can interpret the results of the cloud workload assessments by reviewing the details presented here.

Component Description Challenges
Monitoring The cloud must be monitored in line with performance requirements. Staff must ensure that appropriate tools are in place to properly monitor cloud workloads and that they are capturing adequate and relevant data. Defining requirements for monitoring a potentially unfamiliar environment can be difficult, as can consolidating on a monitoring solution that both meets requirements and covers all relevant areas. There may be some upskilling and integration work required to ensure that monitoring works as required.
Provisioning How will provisioning be done? Who will be responsible for ensuring the right people have access to the right resources? What tooling must be deployed to support provisioning goals? What technical steps must be taken to ensure that the provisioning is as seamless as possible? There is the inevitable challenge of assigning responsibility and accountability in a changing infrastructure and operations environment, especially if the changes are substantial (e.g. a fundamental operating model shift, reoriented around the cloud). Staff may also need to familiarize themselves with cloud-based provisioning tools like Ansible, Terraform, or even CloudFormation.
Migration The act of migrating is important as well. In some cases, the migration is as simple as configuring the new environment and turning it up (e.g. with a net new SaaS service). In other cases, the migration itself can be a substantial undertaking, involving large amounts of data, a complicated replatforming/refactoring, and/or a significant configuration exercise.

Not all migration journeys are created equal, and challenges include a general lack of understanding of the requirements of a migration, the techniques that might be necessary to migrate to a particular cloud (there are many) and the disruption/risk associated with moving large amounts of data. All of these challenges must be considered as part of the overall cloud strategy, whether in terms of architectural principles or skill acquisition (or both!).

Step 2.2

Determine workload future state

Activities

2.2.1 Determine workload future state

Conduct workload assessments

Determine workload future state

This step involves the following participants:

  • IT management
  • Core working group

Outcomes of this step

  • Completed workload assessments
  • Defined workload future state

2.2.1 Determine workload future state

1-3 hours

Input

  • Completed workload assessments

Output

  • Preliminary future state outputs

Materials

  • Cloud Vision Workbook
  • Cloud Vision Executive Presentation

Participants

  • Core working group
  • Service owners
  • IT management
  1. After you’ve had a chance to validate your results, refer to tab 7 of the tool, where you will find a blank notes section.
  2. With the working group, capture your answers to each of the following questions:
    1. What service model is the most suitable for the workload? Why?
    2. How will we conduct the migration? Which of the six models makes the most sense? Do we have a backup plan if our primary plan doesn’t work out?
    3. What should the support model look like?
    4. What are some workload-specific risks and considerations that must be taken into account for the workload?
  3. Once you’ve got answers to each of these questions for each of the workloads, include your summary in the “notes” section of tab 7.

Cloud Vision Executive Presentation

Paste the output into the Cloud Vision Executive Presentation

  • The Cloud Vision Workbook output is a compact, consumable summary of each workload’s planned future state. Paste each assessment in as necessary.
  • There is no absolutely correct way to present the information, but the output is a good place to start. Do note that, while the presentation is designed to lead with the vision statement, because the process is workload-first, the assessments are populated prior to the overall vision in a bottom-up manner.
  • Be sure to anticipate the questions you are likely to receive from any stakeholders. You may consider preparing for questions like: “What other workloads fit this profile?” “What do we expect the impact on the budget to be?” “How long will this take?” Keep these and other questions in mind as you progress through the vision definition process.

The image shows the Cloud Vision Workbook output, which was described in an annotated version in an earlier section.

Info-Tech Insight

Keep your audience in mind. You may want to include some additional context in the presentation if the results are going to be presented to non-technical stakeholders or those who are not familiar with the terms or how to interpret the outputs.

Identify and Mitigate Risks

Build the foundations of your cloud vision

PHASE 3

Phase 3

Identify and Mitigate Risks

Phase 1

1.1 Generate goals and drivers

1.2 Explore cloud characteristics

1.3 Create a current state summary

1.4 Select workloads for analysis

Phase 2

2.1 Conduct workload assessments

2.2 Determine workload future states

Phase 3

3.1 Generate risks and roadblocks

3.2 Mitigate risks and roadblocks

3.3 Define roadmap initiatives

Phase 4

4.1 Review and assign work items

4.2 Finalize cloud decision framework

4.3 Create cloud vision

This phase will walk you through the following activities:

  • Generate risks and roadblocks
  • Mitigate risks and roadblocks
  • Define roadmap initiatives

This phase involves the following participants:

  • Core working group
  • Workload subject matter experts

You know what you want to do, but what do you have to do?

What questions remain unanswered?

There are workload-level risks and roadblocks, and there are environment-level risks. This phase is focused primarily on environment-level risks and roadblocks, or those that are likely to span multiple workloads (but this is not hard and fast rule – anything that you deem worth discussing is worth discussing). The framework here calls for an open forum where all stakeholders – technical and non-technical, pro-cloud and anti-cloud, management and individual contributor – have an opportunity to articulate their concerns, however specific or general, and receive feedback and possible mitigation.

Start by soliciting feedback. You can do this over time or in a single session. Encourage anyone with an opinion to share it. Focus on those who are likely to have a perspective that will become relevant at some point during the creation of the cloud strategy and the execution of any migration. Explain the preliminary direction; highlight any major changes that you foresee. Remind participants that you are not looking for solutions (yet), but that you want to make sure you hear any and every concern as early as possible. You will get feedback and it will all be valuable.

Before cutting your participants loose, remind them that, as with all business decisions, the cloud comes with trade-offs. Not everyone will have every wish fulfilled, and in some cases, significant effort may be needed to get around a roadblock, risks may need to be accepted, and workloads that looked like promising candidates for one service model or another may not be able to realize that potential. This is a normal and expected part of the cloud vision process.

Once the risks and roadblocks conversation is complete, it is the core working group’s job to propose and validate mitigations. Not every risk can be completely resolved, but the cloud has been around for decades – chances are someone else has faced a similar challenge and made it through relatively unscathed. That work will inevitably result in initiatives for immediate execution. Those initiatives will form the core of the initiative roadmap that accompanies the completed Cloud Vision Executive Presentation.

Step 3.1

Generate risks and roadblocks

Activities

3.1.1 Generate risks and roadblocks

3.1.2 Generate mitigations

Identify and mitigate risks

Generate risks and roadblocks

Mitigate risks and roadblocks

Define roadmap initiatives

This step involves the following participants:

  • Core working group
  • IT management
  • Infrastructure
  • Applications
  • Security
  • Architecture

Outcomes of this step

  • List of risks and roadblocks

Understand risks and roadblocks

Risk

  • Something that could potentially go wrong.
  • You can respond to risks by mitigating them:
    • Eliminate: take action to prevent the risk from causing issues.
    • Reduce: take action to minimize the likelihood/severity of the risk.
    • Transfer: shift responsibility for the risk away from IT, towards another division of the company.
    • Accept: where the likelihood or severity is low, it may be prudent to accept that the risk could come to fruition.

Roadblock

  • There are things that aren’t “risks” that we care about when migrating to the cloud.
  • We know, for example, that a complicated integration situation will create work items for any migration – this is not an “unknown.”
  • We respond to roadblocks by generating work items.

3.1.1 Generate risks and roadblocks

1.5 hours

Input

  • Completed cloud vision assessments

Output

  • List of risks and roadblocks

Materials

  • Whiteboard
  • Sticky notes

Participants

  • Core working group
  • Service owners/workload SMEs
  • Anyone with concerns about the cloud
  1. Gather your core working group – and really anyone with an intelligent opinion on the cloud – into a single meeting space. Give the group 5-10 minutes to list anything they think could present a difficulty in transitioning workloads to the cloud. Write each risk/roadblock on its own sticky note. You will never be 100% exhaustive, but don’t let anything your users care about go unaddressed.
  2. Once everyone has had time to write down their risks and roadblocks, have everyone share one by one. Make sure you get them all. Overlap in risks and roadblocks is okay! Group similar concerns together to give a sort of heat map of what your participants are concerned about. (This is called “affinity diagramming.”)
  3. Assign names to these categories. Many of these categories will align with the strategy components discussed in the previous phase (governance, security, etc.) but some will be specific whether by nature or by degree.
  4. Sort each of the individual risks into its respective category, collapsing any exact duplicates, and leaving room for notes and mitigations (see the next slide for a visual).

Understand risks and roadblocks

The image is two columns--on the left, the column is titled Affinity Diagramming. Below the title, there are many colored blocks, randomly arranged. There is an arrow pointing right, to the same coloured blocks, now sorted by colour. In the right column--titled Categorization--each colour has been assigned a category, with subcategories.

Step 3.2

Mitigate risks and roadblocks

Activities

3.2.1 Generate mitigations

Identify and mitigate risks

Generate risks and roadblocks

Mitigate risks and roadblocks

Define roadmap initiatives

This step involves the following participants:

  • Core working group

Outcomes of this step

  • List of mitigations

Is the public cloud less secure?

This is the key risk-related question that most cloud customers will have to answer at some point: does migrating to the cloud for some services increase their exposure and create a security problem?

As with all good questions, the answer is “it depends.” But what does it depend on? Consider these cloud risks and potential mitigations:

  1. Misconfiguration: An error grants access to unauthorized parties (as happened to Capital One in 2019). This can be mitigated by careful configuration management and third-party tooling.
  2. Unauthorized access by cloud provider/partner employees: Though rare, it is possible that a cloud provider or partner can be a vector for a breach. Careful contract language, choosing to own your own encryption keys, and a hybrid approach (storing data on-premises) are some possible ways to address this problem.
  3. Unauthorized access to systems: Cloud services are designed to be accessed from anywhere and may be accessed by malicious actors. Possible mitigations include risk-based conditional access, careful identity access management, and logging and detection.

“The cloud is definitely more secure in that you have much more control, you have much more security tooling, much more visibility, and much more automation. So it is more secure. The caveat is that there is more risk. It is easier to accidentally expose data in the cloud than it is on-premises, but, especially for security, the amount of tooling and visibility you get in cloud is much more than anything we’ve had in our careers on-premises, and that’s why I think cloud in general is more secure.” –Abdul Kittana, Founder, ASecureCloud

Breach bests bank

No cloud provider can protect against every misconfiguration

Industry: Finance

Source: The New York Times, CNET

Background

Capital One is a major Amazon Web Services customer and is even featured on Amazon’s site as a case study. That case study emphasizes the bank’s commitment to the cloud and highlights how central security and compliance were. From the CTO: “Before we moved a single workload, we engaged groups from across the company to build a risk framework for the cloud that met the same high bar for security and compliance that we meet in our on-premises environments. AWS worked with us every step of the way.”

Complication

The cloud migration was humming along until July 2019, when the bank suffered a serious breach at the hands of a hacker. That hacker was able to steal millions of credit card applications and hundreds of thousands of Social Security numbers, bank account numbers, and Canadian social insurance numbers.

According to investigators and to AWS, the breach was caused by an open reverse proxy attack against a misconfigured web app firewall, not by an underlying vulnerability in the cloud infrastructure.

Results

Capital One reported that the breach was expected to cost it $150 million, and AWS fervently denied any blame. The US Senate got involved, as did national media, and Capital One’s CEO issued a public apology, writing, “I sincerely apologize for the understandable worry this incident must be causing those affected, and I am committed to making it right.”

It was a bad few months for IT at Capital One.

3.2.1 Generate mitigations

3-4.5 hours

Input

  • Completed cloud vision assessments

Output

  • List of risks and roadblocks

Materials

  • Whiteboard
  • Sticky notes

Participants

  • Core working group
  • Service owners/workload SMEs
  • Anyone with concerns about the cloud
  1. Recall the four mitigation strategies: eliminate, reduce, transfer, or accept. Keep these in mind as you work through the list of risks and roadblocks with the core working group. For every individual risk or roadblock raised in the initial generation session, suggest a specific mitigation. If the concern is “SaaS providers having access to confidential information,” a mitigation might be encryption, specific contract language, or proof of certifications (or all the above).
  2. Work through this for each of the risks and roadblocks, identifying the steps you need to take that would satisfy your requirements as you understand them.
  3. Once you have gone through the whole list – ideally with input from SMEs in particular areas like security, engineering, and compliance/legal – populate the Cloud Vision Workbook (tab 8) with the risks, roadblocks, and mitigations (sorted by category). Review tab 8 for an example of the output of this exercise.

Cloud Vision Workbook

Cloud Vision Workbook – mitigations

The image shows a large chart titled Risks, roadblocks, and mitigations, which has been annotated with notes.

Step 3.3

Define roadmap initiatives

Activities

3.3.1 Generate roadmap initiatives

Identify and mitigate risks

Generate risks and roadblocks

Mitigate risks and roadblocks

Define roadmap initiatives

This step involves the following participants:

  • Core working group

Outcomes of this step

  • Defined roadmap initiatives

3.3.1 Generate roadmap initiatives

1 hour

Input

  • List of risk and roadblock mitigations

Output

  • List of cloud initiatives

Materials

  • Cloud Vision Workbook

Participants

  • Core working group
  1. Executing on your cloud vision will likely require you to undertake some key initiatives, many of which have already been identified as part of your mitigation exercise. On tab 8 of the Cloud Vision Workbook, review the mitigations you created in response to the risks and roadblocks identified. Initiatives should generally be assignable to a party and should have a defined scope/duration. For example, “assess all net new applications for cloud suitability” might not be counted as an initiative, but “design a cloud application assessment” would likely be.
  2. Design a timeline appropriate for your specific needs. Generally short-term (less than 3 months), medium-term (3-6 months), and long-term (greater than 6 months) will work, but this is entirely based on preference.
  3. Review and validate the parameters with the working group. Consider creating additional color-coding (highlighting certain tasks that might be dependent on a decision or have ongoing components).

Cloud Vision Workbook

Bridge the gap and create the vision

Build the foundations of your cloud vision

Phase 4

Phase 4

Bridge the Gap and Create the Vision

Phase 1

1.1 Generate goals and drivers

1.2 Explore cloud characteristics

1.3 Create a current state summary

1.4 Select workloads for analysis

Phase 2

2.1 Conduct workload assessments

2.2 Determine workload future states

Phase 3

3.1 Generate risks and roadblocks

3.2 Mitigate risks and roadblocks

3.3 Define roadmap initiatives

Phase 4

4.1 Review and assign work items

4.2 Finalize cloud decision framework

4.3 Create cloud vision

This phase will walk you through the following activities:

  • Assign initiatives and propose timelines
  • Build a delivery model rubric
  • Build a service model rubric
  • Built a support model rubric
  • Create a cloud vision statement
  • Map cloud workloads
  • Complete the Cloud Vision presentation

This phase involves the following participants:

  • IT management, the core working group, security, infrastructure, operations, architecture, engineering, applications, non-IT stakeholders

Step 4.1

Review and assign work items

Activities

4.1.1 Assign initiatives and propose timelines

Bridge the gap and create the vision

Review and assign work items

Finalize cloud decision framework

Create cloud vision

This step involves the following participants:

  • Core working group
  • IT management

Outcomes of this step

  • Populated cloud vision roadmap

4.1.1 Assign initiatives and propose timelines

1 hour

Input

  • List of cloud initiatives

Output

  • Initiatives assigned by responsibility and timeline

Materials

  • Cloud Vision Workbook

Participants

  • Core working group
  1. Once the list is populated, begin assigning responsibility for execution. This is not a RACI exercise, so focus on the functional responsibility. Once you have determined who is responsible, assign a timeline and include any notes. This will form the basis of a more formal project plan.
  2. To assign the initiative to a party, consider 1) who will be responsible for execution and 2) if that responsibility will be shared. Be as specific as possible, but be sure to be consistent to make it easier for you to sort responsibility later on.
  3. When assigning timelines, we suggest including the end date (when you expect the project to be complete) rather than the start date, though whatever you choose, be sure to be consistent. Make use of the notes column to record anything that you think any other readers will need to be aware of in the future, or details that may not be possible to commit to memory.

Cloud Vision Workbook

Step 4.2

Finalize cloud decision framework

Activities

4.2.1 Build a delivery model rubric

4.2.2 Build a service model rubric

4.2.3 Build a support model rubric

Bridge the gap and create the vision

Review and assign work items

Finalize cloud decision framework

Create cloud vision

This step involves the following participants:

  • Core working group

Outcomes of this step

  • Cloud decision framework

4.2.1 Build a delivery model rubric

1 hour

Input

  • List of cloud initiatives

Output

  • Initiatives assigned by responsibility and timeline

Materials

Participants

  • Core working group
  1. Now that we have a good understanding of the cloud’s key characteristics, the relative suitability of different workloads for the cloud, and a good understanding of some of the risks and roadblocks that may need to be overcome if a cloud transition is to take place, it is time to formalize a delivery model rubric. Start by listing the delivery models on a white board vertically – public, private, hybrid, and multi-cloud. Include a community cloud option as well if that is feasible for you. Strike any models that do not figure into your vision.
  2. Create a table style rubric for each delivery model. Confer with the working group to determine what characteristics best define workloads suitable for each model. If you have a hybrid cloud option, you may consider workloads that are highly dynamic; a private cloud hosted on-premises may be more suitable for workloads that have extensive regulatory requirements.
  3. Once the table is complete, include it in the Cloud Vision Executive Presentation.

Cloud Vision Executive Presentation

Vision for the cloud future state (example)

Delivery model Decision criteria
Public cloud
  • Public cloud is the primary destination for all workloads as the goal is to eliminate facilities and infrastructure management
  • Offers features, broad accessibility, and managed updates along with provider-managed facilities and hardware
Legacy datacenter
  • Any workload that is not a good fit for the public cloud
  • Dependency (like a USB key for license validation)
  • Performance requirements (e.g. workloads highly sensitive to transaction thresholds)
  • Local infrastructure components (firewall, switches, NVR)

Summary statement: Everything must go! Public cloud is a top priority. Anything that is not compatible (for whatever reason) with a public cloud deployment will be retained in a premises-based server closet (downgraded from a full datacenter). The private cloud does not align with the overall organizational vision, nor does a hybrid solution.

4.2.2 Build a service model rubric

1 hour

Input

  • Output of workload assessments
  • Output of risk and mitigation exercise

Output

  • Service model rubric

Materials

  • Whiteboard
  • Cloud Vision Executive Presentation

Participants

  • Core working group
  1. This next activity is like the delivery model activity, but covers the relevant cloud service models. On a whiteboard, make a vertical list of the cloud service models (SaaS, PaaS, IaaS, etc.) that will be considered for workloads. If you have an order of preference, place your most preferred at the top, your least preferred at the bottom.
  2. Describe the circumstances under which you would select each service model. Do your best to focus on differentiators. If a decision criterion appears for multiple service models, consider refining or excluding it. (For additional information, check out Info-Tech’s Reimagine IT Operations for a Cloud-First World blueprint.)
  3. Create a summary statement to capture your overall service model position. See the next slide for an example. Note: this can be incorporated into your cloud vision statement, so be sure that it reflects your genuine cloud preferences.
  4. Record the results in the Cloud Vision Executive Presentation.

Cloud Vision Executive Presentation

Vision for the cloud future state (example)

Service model Decision criteria
SaaS

SaaS first; opt for SaaS when:

  • A SaaS option exists that meets all key business requirements
  • There is a strong desire to have someone else (the vendor) manage infrastructure components/the platform
  • Not particularly sensitive to performance thresholds
  • The goal is to transition management of the workload outside of IT
  • SaaS is the only feasible way to consume the desired service
PaaS
  • Highly customized service/workload – SaaS not feasible
  • Still preferable to offload as much management as possible to third parties
  • Customization required, but not at the platform level
  • The workload is built using a standard framework
  • We have the time/resources to replatform
IaaS
  • Service needs to be lifted and shifted out of the datacenter quickly
  • Customization is required at the platform level/there is value in managing components
  • There is no need to manage facilities
  • Performance is not impacted by hosting the workload offsite
  • There is value in right-sizing the workload over time
On-premises Anything that does not fit in the cloud for performance or other reasons (e.g. licensing key)

Summary statement: SaaS will be the primary service model. All workloads will migrate to the public cloud where possible. Anything that cannot be migrated to SaaS will be migrated to PaaS. IaaS is a transitory step.

4.2.3 Build a support model rubric

1 hour

Input

  • Results of the cloud workload assessments

Output

  • Support model rubric

Materials

  • Whiteboard
  • Cloud Vision Executive Presentation

Participants

  • Core working group
  1. The final rubric covered here is that for the support model. Where will you procure the skills necessary to ensure the vision’s proper execution? Much like the other rubric activities, write the three support models vertically (in order of preference, if you have one) on a whiteboard.
  2. Next to each model, describe the circumstances under which you would select each support model. Focus on the dimensions: the duration of the engagement, specialization required, and flexibility required. If you have existing rules/practices around hiring consultants/MSPs, consider those as well.
  3. Once you have a good list of decision criteria, form a summary statement. This should encapsulate your position on support models and should mention any notable criteria that will contribute to most decisions.
  4. Record the results in the Cloud Vision Executive Presentation.

Cloud Vision Executive Presentation

Vision for the cloud future state (example)

Support model Decision criteria
Internal IT

The primary support model will be internal IT going forward

  • Chosen where the primary work required is administrative
  • Where existing staff can manage the service in the cloud easily and effectively
  • Where the chosen solution fits the SaaS service model
Consultant
  • Where the work required is time-bound (e.g. a migration/refactoring exercise)
  • Where the skills do not exist in house, and where the skills cannot easily be procured (specific technical expertise required in areas of the cloud unfamiliar to staff)
  • Where opportunities for staff to learn from consultant SMEs are valuable
  • Where ongoing management and maintenance can be handled in house
MSP
  • Where an ongoing relationship is valued
  • Where ongoing administration and maintenance are disproportionately burdensome on IT staff (or where this administration and maintenance is likely to be burdensome)
  • Where the managed services model has already been proven out
  • Where specific expertise in an area of technology is required but this does not rise to the need to hire an FTE (e.g. telephony)

Summary statement: Most workloads will be managed in house. A consultant will be employed to facilitate the transition to micro-services in a cloud container environment, but this will be transitioned to in-house staff. An MSP will continue to manage backups and telephony.

Step 4.3

Create cloud vision

Activities

4.3.1 Create a cloud vision statement

4.3.2 Map cloud workloads

4.3.3 Complete the Cloud Vision Presentation

Review and assign work items

Finalize cloud decision framework

Create cloud vision

This step involves the following participants:

  • Core working group
  • IT management

Outcomes of this step

Completed Cloud Vision Executive Presentation

4.3.1 Create a cloud vision statement

1 hour

Input

  • List of cloud initiatives

Output

  • Initiatives assigned by responsibility and timeline

Materials

  • Cloud Vision Workbook

Participants

  • Core working group
  1. Now that you know what service models are appropriate, it’s time to summarize your cloud vision in a succinct, consumable way. A good vision statement should have three components:
    • Scope: Which parts of the organization will the strategy impact?
    • Goal: What is the strategy intended to accomplish?
    • Key differentiator: What makes the new strategy special?
  2. On a whiteboard, make a chart with three columns (one column for each of the features of a good mission statement). Have the group generate a list of words to describe each of the categories. Ideally, the group will produce multiple answers for each category.
  3. Once you’ve gathered a few different responses for each category, have the team put their heads down and generate pithy mission statements that capture the sentiments underlying each category.
  4. Have participants read their vision statements in front of the group. Use the rest of the session to produce a final statement. Record the results in the Cloud Strategy Executive Presentation.

Example vision statement outputs

“IT at ACME Corp. hereby commits to providing clients and end users with an unparalleled, productivity-enabling technology experience, leveraging, insofar as it is possible and practical, cloud-based services.”

“At ACME Corp. our employees and customers are our first priority. Using new, agile cloud services, IT is devoted to eliminating inefficiency, providing cutting-edge solutions for a fast-paced world, and making a positive difference in the lives of our colleagues and the people we serve.”

As a global leader in technology, ACME Corp. is committed to taking full advantage of new cloud services, looking first to agile cloud options to optimize internal processes wherever efficiency gaps exist. Improved efficiency will allow associates to spend more time on ACME’s core mission: providing an unrivalled customer experience.”

Scope

Goal

Key differentiator

4.3.2 Map cloud workloads

1 hour

Input

  • List of workloads
  • List of acceptable service models
  • List of acceptable migration paths

Output

  • Workloads mapped by service model/migration path

Materials

  • Whiteboard
  • Sticky notes

Participants

  • Core working group
  1. Now that you have defined your overall cloud vision as well as your service model options, consider aligning your service model preferences with your migration path preferences. Draw a table with your expected migration strategies across the top (retain, retire, rehost, replatform, refactor, repurchase, or some of these) and your expected service models across the side.
  2. On individual sticky notes, write a list of workloads in your environment. In a smaller environment, this list can be exhaustive. Otherwise take advantage of the list you created as part of phase 1 along with any additional workloads that warrant discussion.
  3. As a group, go through the list, placing the sticky notes first in the appropriate row based on their characteristics and the decision criteria that have already been defined, and then in the appropriate column based on the appropriate migration path. (See the next slide for an example of what this looks like.)
  4. Record the results in the Cloud Vision Executive Presentation. Note: not every cell will be filled; some migration path/service model combinations are impossible or otherwise undesirable.

Cloud Vision Executive Presentation

Example cloud workload map

Repurchase Replatform Rehost Retain
SaaS

Office suite

AD

PaaS SQL Database
IaaS File Storage DR environment
Other

CCTV

Door access

4.3.3 Complete the Cloud Vision Presentation

1 hour

Input

  • List of cloud initiatives

Output

  • Initiatives assigned by responsibility and timeline

Materials

  • Cloud Vision Workbook

Participants

  • Core working group
  1. Open the Cloud Vision Executive Presentation to the second slide and review the templated executive brief. This comprises several sections (see the next slide). Populate each one:
    • Summary of the exercise
    • The cloud vision statement
    • Key cloud drivers
    • Risks and roadblocks
    • Top initiatives and next steps
  2. Review the remainder of the presentation. Be sure to elaborate on any significant initiatives and changes (where applicable) and to delete any slides that you no longer require.

Cloud Vision Workbook

Sample cloud vision executive summary

  • From [date to date], a cross-functional group representing IT and its constituents met to discuss the cloud.
  • Over the course of the week, the group identified drivers for cloud computing and developed a shared vision, evaluated several workloads through an assessment framework, identified risks, roadblocks, and mitigations, and finally generated initiatives and next steps.
  • From the process, the group produced a summary and a cloud suitability assessment framework that can be applied at the level of the workload.

Cloud Vision Statement

[Organization] will leverage public cloud solutions and retire existing datacenter and colocation facilities. This transition will simplify infrastructure administration, support, and security, while modernizing legacy infrastructure and reducing the need for additional capital expenditure.

Cloud Drivers Retire the datacenter Do more valuable work
Right-size the environment Reduce CapEx
Facilitate ease of mgmt. Work from anywhere
Reduce capital expenditure Take advantage of elasticity
Performance and availability Governance Risks and roadblocks
Security Rationalization
Cost Skills
Migration Remaining premises resources
BC, backup, and DR Control

Initiatives and next steps

  • Close the datacenter and colocation site in favor of a SaaS-first cloud approach.
  • Some workloads will migrate to infrastructure-as-a-service in the short term with the assistance of third-party consultants.

Document your cloud strategy

You did it!

Congratulations! If you’ve made it this far, you’ve successfully articulated a cloud vision, assessed workloads, developed an understanding (shared with your team and stakeholders) of cloud concepts, and mitigated risks and roadblocks that you may encounter along your cloud journey. From this exercise, you should understand your mission and vision, how your cloud plans will interact with any other relevant strategic plans, and what successful execution looks like, as well as developing a good understanding of overall guiding principles. These are several components of your overall strategy, but they do not comprise the strategy in its entirety.

How do you fix this?

First, validate the results of the vision exercise with your stakeholders. Socialize it and collect feedback. Make changes where you think changes should be made. This will become a key foundational piece. The next step is to formally document your cloud strategy. This is a separate project and is covered in the Info-Tech blueprint Document Your Cloud Strategy.

The vision exercise tells you where you want to go and offers some clues as to how to get there. The formal strategy exercise is a formal documentation of the target state, but also captures in detail the steps you’ll need to take, the processes you’ll need to refine, and the people you’ll need to hire.

A cloud strategy should comprise your organizational stance on how the cloud will change your approach to people and human resources, technology, and governance. Once you are confident that you can make and enforce decisions in these areas, you should consider moving on to Document Your Cloud Strategy. This blueprint, Define Your Cloud Vision, often serves as a prerequisite for the strategy documentation conversation(s).

Appendix

Summary of Accomplishment

Additional Support

Research Contributors

Related Info-Tech Research

Vendor Resources

Bibliography

Summary of Accomplishment

Problem Solved

You have now documented what you want from the cloud, what you mean when you say “cloud,” and some preliminary steps you can take to make your vision a reality.

You now have at your disposal a framework for identifying and evaluating candidates for their cloud suitability, as well as a series of techniques for generating risks and mitigations associated with your cloud journey. The next step is to formalize your cloud strategy using the takeaways from this exercise. You’re well on your way to a completed cloud strategy!

If you would like additional support, have our analysts guide you through other phases as part of an Info-Tech workshop.

Contact your account representative for more information.

workshops@infotech.com

1-888-670-8889

Additional Support

If you would like additional support, have our analysts guide you through other phases as part of an Info-Tech Workshop.

Contact your account representative for more information.

workshops@infotech.com 1-888-670-8889

To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team.

Info-Tech analysts will join you and your team at your location or welcome you to Info-Tech’s historic Toronto office to participate in an innovative onsite workshop.

The following are sample activities that will be conducted by Info-Tech analysts with your team:

Generate drivers for cloud adoption

Work with stakeholders to understand the expected benefits of the cloud migration and how these drivers will impact the overall vision.

Conduct workload assessments

Assess your individual cloud workloads for their suitability as candidates for the cloud migration.

Bibliography

“2021 State of the Cloud Report.” Flexera, 2021. Web.

“2021 State of Upskilling Report.” Pluralsight, 2021. Web.

“AWS Snowmobile.” Amazon Web Services, n.d. Web.

“Azure products.” Microsoft, n.d. Web.

“Azure Migrate Documentation.” Microsoft, n.d. Web.

Bell, Harold. “Multi-Cloud vs. Hybrid Cloud: What’s the Difference?” Nutanix, 2019. Web.

“Cloud Products.” Amazon Web Services, n.d. Web.

“COBIT 2019 Framework: Introduction and Methodology.” ISACA, 2019. Web.

Edmead, Mark T. “Using COBIT 2019 to Plan and Execute an Organization’s Transformation Strategy.” ISACA, 2020. Web.

Flitter, Emily, and Karen Weise. “Capital One Data Breach Compromises Data of Over 100 Million.” The New York Times, 29 July 2019. Web.

Gillis, Alexander S. “Cloud Security Posture Management (CSPM).” TechTarget, 2021. Web.

“’How to Cloud’ with Capital One.” Amazon Web Services, n.d. Web.

“IBM Closes Landmark Acquisition of Red Hat for $34 Billion; Defines Open, Hybrid Cloud Future.” Red Hat, 9 July 2019. Web.

Mell, Peter, and Timothy Grance. “The NIST Definition of Cloud Computing.” National Institute of Standards and Technology, Sept. 2011. Web.

Ng, Alfred. “Amazon Tells Senators it Isn't to Blame for Capital One Breach.” CNET, 2019. Web.

Orban, Stephen. “6 Strategies for Migrating Applications to the Cloud.” Amazon Web Services, 2016. Web.

Sullivan, Dan. “Cloud Access Security Broker (CASB).” TechTarget, 2021. Web.

“What Is Secure Access Service Edge (SASE)?” Cisco, n.d. Web.

About Info-Tech

Info-Tech Research Group is the world’s fastest-growing information technology research and advisory company, proudly serving over 30,000 IT professionals.

We produce unbiased and highly relevant research to help CIOs and IT leaders make strategic, timely, and well-informed decisions. We partner closely with IT teams to provide everything they need, from actionable tools to analyst guidance, ensuring they deliver measurable results for their organizations.

Member Rating

9.5/10
Overall Impact

$235,512
Average $ Saved

31
Average Days Saved

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve.

Read what our members are saying

What Is a Blueprint?

A blueprint is designed to be a roadmap, containing a methodology and the tools and templates you need to solve your IT problems.

Each blueprint can be accompanied by a Guided Implementation that provides you access to our world-class analysts to help you get through the project.

Need Extra Help?
Speak With An Analyst

Get the help you need in this 4-phase advisory process. You'll receive 7 touchpoints with our researchers, all included in your membership.

Guided Implementation #1 - Understand the cloud.
  • Call #1 - Discuss current state, challenges, etc.
  • Call #2 - Goals, drivers, and current state.

Guided Implementation #2 - Assess your cloud workloads
  • Call #1 - Conduct cloud suitability assessment for selected workloads.

Guided Implementation #3 - Identify and mitigate risks
  • Call #1 - Generate and categorize risks.
  • Call #2 - Begin the risk mitigation conversation.

Guided Implementation #4 - Bridge the gap and create the vision.
  • Call #1 - Complete the risk mitigation process.
  • Call #2 - Finalize vision statement and cloud decision framework.

Authors

Jeremy Roberts

Emily Sugerman

Contributors

  • Issy Ben-Shaul, CEO & Co-Founder, Velostrata
  • Vishal Ganeriwala, Senior Director – Product Marketing, Citrix
  • Kenneth Libutti, Chief Information Officer, Palm Beach State College
  • Eric Montagnino, Network Manager, Palm Beach State College
  • Carisa Stringer, Director – Product Marketing, Citrix
  • Nabeel Yousif, Executive Consultant
Visit our IT Cost Optimization Center
Over 100 analysts waiting to take your call right now: 1-519-432-3550 x2019