Document Your Cloud Strategy

Get ready for the cloudy future with a consistent, proven strategy.

Analyst perspective

Any approach is better than no approach

Moving to the cloud is a big, scary transition, like moving from gas-powered to electric cars, or from cable to streaming, or even from the office to working from home. There are some undeniable benefits, but we must reorient our lives a bit to accommodate those changes, and the results aren’t always one-for-one. A strategy helps you make decisions about your future direction and how you should respond to changes and challenges. In Document Your Cloud Strategy we hope to help you accomplish just that: clarifying your overall mission and vision (as it relates to the cloud) and helping you develop an approach to changes in technology, people management, and, of course, governance. The cloud is not a panacea. Taken on its own, it will not solve your problems. But it can be an important tool in your IT toolkit, and you should aim to make the best use of it – whatever “best” happens to mean for you.

Jeremy Roberts

Research Director, Infrastructure and Operations

Info-Tech Research Group

Executive Summary

Your Challenge

The cloud is multifaceted. It can be complicated. It can be expensive. Everyone has an opinion on the best way to proceed – and in many cases has already begun the process without bothering to get clearance from IT. The core challenge is creating a coherent strategy to facilitate your overall goals while making the best use of cloud technology, your financial resources, and your people.

Common Obstacles

Despite the universally agreed-upon benefit of formulating a coherent strategy, several obstacles make execution difficult:

• Inconsistent understanding of what the cloud means
• Inability to come to a consensus on key decisions
• Ungoverned decision making
• Unclear understanding of cloud roles and responsibilities

Info-Tech’s Approach

A cloud strategy might seem like a big project, but it’s just a series of smaller conversations. The methodology presented here is designed to facilitate those conversations, using a curated list of topics, prompts, participant lists, and sample outcomes. We have divided the strategy into four key areas:

1. Vision and alignment
2. People
3. Governance
4. Technology

The answers might be different, but the questions are the same

Every organization will approach the cloud differently, but they all need to ask the same questions: When will we use the cloud? What forms will our cloud usage take? How will we manage governance? What will we do about people? How will we incorporate new technology into our environment? The answers to these questions are as numerous as there are people to answer them, but the questions must be asked.

Your challenge

This research is designed to help organizations that are facing these challenges or looking to:

• Ensure that the cloud strategy is complete and accurately reflects organizational goals and priorities.
• Develop a consistent and coherent approach to adopting cloud services.
• Design an approach to mitigate risks and challenges associated with adopting cloud services.
• Create a shared understanding of the expected benefits of cloud services and the steps required to realize those benefits.

Grappling with a cloud strategy is a top initiative: 43% of respondents report progressing on a cloud-first strategy as a top cloud initiative.

Source: Flexera, 2021.

Definition: Cloud strategy

A document providing a systematic overview of cloud services, their appropriate use, and the steps that an organization will take to maximize value and minimize risk.

Common obstacles

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

• The cloud means different things to different people, and creating a strategy that is comprehensive enough to cover a multitude of use cases while also being written to be consumable by all stakeholders is difficult.
• The incentives to adopt the cloud differ based on the expected benefit for the individual customer. User-led decision making and historically ungoverned deployments can make it difficult to reset expectation and align with a formal strategy.
• Getting all the right people in a room together to agree on the key components of the strategy and the direction undertaken for each one is often difficult.

Info-Tech’s approach

Info-Tech’s approach

Your cloud strategy will comprise the elements listed under “vision and alignment,” “technology,” “governance,” and “people.” The Info-Tech methodology involves breaking the strategy down into subcomponents and going through a three-step process for each one. Start by reviewing a standard set of questions and understanding the goal of the exercise: What do we need to know? What are some common considerations and best practices? Once you’ve had a chance to review, discuss your current state and any gaps: What has been done? What still needs to be done? Finally, outline how you plan to go forward: What are your next steps? Who needs to be involved?

Review

• What questions do we need to answer to complete the discussion of this strategy component? What does the decision look like?
• What are some key terms and best practices we must understand before deciding?

Discuss

• What steps have we already taken to address this component?
• Does anything still need to be done?
• Is there anything we’re not sure about or need further guidance on?

Go forward

• What are the next steps?
• Who needs to be involved?
• What questions still need to be asked/answered?
• What should the document’s wording look like?

Info-Tech’s methodology for documenting your cloud strategy

Insight summary

Separate strategy from tactics

Separate strategy from tactics! A strategy requires building out the framework for ongoing decision making. It is meant to be high level and achieve a large goal. The outcome of a strategy is often a sense of commitment to the goal and better communication on the topic.

The cloud does not exist in a vacuum

Your cloud strategy flows from your cloud vision and should align with the broader IT strategy. It is also part of a pantheon of strategies and should exist harmoniously with other strategies – data, security, etc.

People problems needn’t preponderate

The cloud doesn’t have to be a great disruptor. If you handle the transition well, you can focus your people on doing more valuable work – and this is generally engaging.

Governance is a means to an end

Governing your deployment for its own sake will only frustrate your end users. Articulate the benefits users and the organization can expect to see and you’re more likely to receive the necessary buy-in.

Technology isn’t a panacea

Technology won’t solve all your problems. Technology is a force multiplier, but you will still have to design processes and train your people to fully leverage it.

Key deliverable

Cloud Strategy Document template

Inconsistency and informality are the enemies of efficiency. Capture the results of the cloud strategy generation exercises in the Cloud Strategy Document template.

• Record the results of the exercises undertaken as part of this blueprint in the Cloud Strategy Document template.
• It is important to remember that not every cloud strategy will look exactly the same, but this template represents an amalgamation of best practices and cloud strategy creation honed over several years of advisory service in the space.
• You know your audience better than anyone. If you would prefer a strategy delivered in a different way (e.g. presentation format) feel free to adapt the Cloud Vision Executive Presentation into a longer strategy presentation.
• Emphasis is an area where you should exercise discretion as well. A cost-oriented cloud strategy, or one that prioritizes one type of cloud (e.g. SaaS) at the exclusion of others, may benefit from more focus on some areas than others, or the introduction of relevant subcategories. Include as many of these as you think will be relevant.
• Parsimony is king – if you can distill a concept to its essence, start there. Include additional detail only as needed. You want your cloud strategy document to be read. If it’s too long or overly detailed, you’ll encounter readability issues.

Blueprint benefits

Measure the value of this blueprint

Don’t take our word for it:

• Document Your Cloud Strategy has been available for several years in various forms as both a workshop and as an analyst-led guided implementation.
• After each engagement, we send a survey that asks members how they benefited from the experience. Those who have worked through Info-Tech’s cloud strategy material have given overwhelmingly positive feedback.
• Additionally, members reported saving between 10 and 20 days and an average of $46,499.
• Measure the value by calculating the time saved as a result of 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.

8.8/10 Average reported satisfaction

13 Days Average reported time savings

$46,499 Average cost savings

Executive Brief Case Study

INDUSTRY: Pharmaceuticals

SOURCE: Info-Tech workshop

Pharmaceutical company

The unnamed pharmaceutical company that is the subject of this case study was looking to make the transition to the cloud. In the absence of a coherent strategy, the organization had a few cloud deployments with no easily discernable overall approach. Representatives of several distinct functions (legal, infrastructure, data, etc.) all had opinions on the uses and abuses of cloud services, but it had been difficult to round everyone up and have the necessary conversations. As a result, the strategy exercise had not proceeded in a speedy or well-governed way. This lack of strategic readiness presented a roadblock to moving forward with the cloud strategy and to work with the cloud implementation partner, tasked with execution.

Results

The company engaged Info-Tech for a four-day workshop on cloud strategy documentation. Over the course of four days, participants drawn from across the organization discussed the strategic components and generated consensus statements and next steps. The team was able to formalize the cloud strategy and described the experience as saving 10 days.

Example output: Document your cloud strategy workshop exercise

Anything in green, the team was reasonably sure they had good alignment and next steps. Those yellow flags warranted more discussion and were not ready for documentation.

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

DIY Toolkit

"Our team has already made this critical 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 immediately. 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 to 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 4 to 6 calls over the course of 1 to 3 months

Workshop Overview

Contact your account representative for more information.

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

Phase 1

Document Your Vision and Alignment

This phase will walk you through the following activities:

1. Record your cloud mission and vision
2. Document your cloud strategy’s alignment with other strategic plans
3. Record your cloud guiding principles
4. Define success

This phase has the following outcome:

• Documented strategy: vision and alignment

Record your mission and vision

Build on the work you’ve already done

Before formally documenting your cloud strategy, you should ensure that you have a good understanding of your overall cloud vision. How do you plan to leverage the cloud? What goals are you looking to accomplish? How will you distribute your workloads between different cloud service models (SaaS, PaaS, IaaS)? What will your preferred delivery model be (public, private, hybrid)? Will you support your cloud deployment internally or use the services of various consultants or managed service providers?

The answers to these questions will inform the first section of your cloud strategy. If you haven’t put much thought into this or think you could use a deep dive on the fundamentals of your cloud vision and cloud archetypes, consider reviewing Define Your Cloud Vision, the companion blueprint to this one.

Once you understand your cloud vision and what you’re trying to accomplish with your cloud strategy, this phase will walk you through aligning the strategy with other strategic initiatives. What decisions have others made that will impact the cloud strategy (or that the cloud strategy will impact)? Who must be involved/informed? What callouts must be involved at what point? Do users have access to the appropriate strategic documentation (and would they understand it if they did)?

You must also capture some guiding principles. A strategy by its nature provides direction, helping readers understand the decisions they should make and why those decisions align with organizational interests. Creating some top-level principles is a useful exercise because those principles facilitate comprehension and ensure the strategy’s applicability.

Finally, this phase will walk you through the process of measuring success. Once you know where you’d like to go, the principles that underpin your direction, and how your cloud strategy figures into the broader strategic pantheon, you should record what success actually means. If you’re looking to save money, overall cost should be a metric you track. If the cloud is all about productivity, generate appropriate productivity metrics. If you’re looking to expand into new technology or close a datacenter, you will need to track output specific to those overall goals.

Review: mission and vision

The overall organizational mission is a key foundational element of the cloud strategy. If you don’t understand where you’re going, how can you begin the journey to get there? This section of the strategy has four key parts that you should understand and incorporate into the beginning of the strategy document. If you haven’t already, review Define Your Cloud Vision for instructions on how to generate these elements.

Understand key cloud concepts: Archetype

Once you understand the value of the cloud, your workloads’ general suitability for the 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.

Understand key cloud concepts: service and delivery models

In 2011, NIST published a standard definition of cloud computing. While not every provider exactly exemplifies each component, the five key cloud characteristics and the service models outlined here provide a good basis for designing your vision (and, therefore, your strategy). If you’re not sure how the different types of cloud should factor into your strategy, consider analyzing a handful of key workloads using the Cloud Vision Workbook. You will gain an understanding of the relative suitability of each service/delivery model for the cloud and can incorporate the results into your document.

Understand key cloud concepts: support model

Support models by characteristic

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 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 cloud and others that are not as effective, with that fit being conditional on the appropriate support model being employed.

Discuss: mission and vision

Participants

• CIO
• Management
• Perspective from Applications, Infrastructure, Data
• Executive leadership (non-IT)

Key decisions

• Cloud archetype
• Preferred cloud support model
• Preferred cloud delivery model
• Preferred cloud service model
• Defined mission/vision statement

Questions

• What are the overall organizational objectives and cloud drivers? Have they been recorded anywhere?
• Is there a cloud vision statement? If so, what is it?
• What is our preferred cloud support model? Will we be primarily hiring or training internal staff, working with consultants, or hiring a managed service provider?
• Are we primarily a public cloud shop? Does a private cloud or hybrid cloud model figure into our plans going forward?
• Could we benefit from a multicloud approach?
• How will we determine the appropriate service model for each workload? What makes a workload a good candidate for infrastructure as a service, platform as a service, or software as a service?
• Is there any disagreement on any of these counts?

1.1 Document your mission and vision

1-2 hours

1. Review the questions on the previous slide and discuss them with the group.
2. Consider any additional questions that emerge during the conversation. Are they worth including in the strategy document?
3. Assign a scribe to capture the salient points of the discussion.
4. Record a summary of your cloud mission/vision in the Cloud Strategy Document template.

Note that this is as far as many of your readers will go. Ensure that you adequately capture your stated cloud direction, including your preferred delivery, service, and support models. If the group cannot come to a consensus on these items, consider reviewing Define Your Cloud Vision to build that consensus.

Download the Cloud Strategy Document template

Review: alignment to other strategic plans

• The cloud strategy is not an island. It cannot exist effectively independent of other strategic efforts. If transitioning to the cloud will require additional headcount or change the nature of the staffing model, the HR strategy will be impacted. Security and risk management must be involved if data is going to be moving off site. The cloud is often part of a much broader digital transformation initiative.
• This section of the strategy is unique because interacting documentation, including relevant strategies, policies, etc. should be highlighted in general at the beginning, but it should be peppered throughout the document as well.
• The cloud strategy should refer to other policies and strategies throughout where relevant. For example, if you have a vendor management strategy/process, there is no need to replicate it in full, but linking to the document and acknowledging its existence and the direction it provides is a good way to provide readers with consistency.
• Start by reviewing the list of strategy components (mission and vision, people, technology, governance) and identify any documents that will impact the formation/execution of the cloud strategy document. Include references to that documentation in a summary section and throughout.

Discuss: alignment to other strategic plans

Participants

• CIO
• Management
• Cloud strategy creation team
• Perspective from some service owners

Key decisions

• Policies and strategies relevant to the cloud strategy
• Impact the relevant policies and procedures will have on the cloud strategy document

Questions

• Is the cloud initiative part of a broader strategy or digital transformation project?
• Who contributed to the creation of the cloud vision? Is there a documentation or policy/procedure that governs their respective disciplines?
• What needs to change to transform the cloud vision into a reality? Are there any policies/strategies that must be updated to reflect cloud priorities?
• Are there any stakeholders with strong opinions about the cloud vision? Do they have input into policy or strategy areas that must be addressed as part of the cloud strategy?

Info-Tech Insight

Sysadmins like to use the "scream test" if they can’t figure out what a server is supporting. Unplug it and see who screams! Use the same logic to incorporate other strategic plans into your cloud strategy. If you left them out of the cloud strategy, what stakeholders would scream? Use this information to ensure they’re included!

1.2 Document alignment to other strategic plans

1-3 hours

1. Review the questions on the previous slide. Discuss them with the group.
2. Document any specific alignments. If, for example, a strategic goal is to be more cost-conscious, capture how the cloud can be leveraged to accomplish this. Speak in broad terms.
3. Record a summary of the conversation in the Cloud Strategy Document template. Keep your audience in mind – help them understand why the cloud is relevant to them.

Download the Cloud Strategy Document template

Review: guiding principles

• Writing in the Harvard Business Review, Michael D. Watkins defines a strategy as “a set of guiding principles that, when communicated and adopted in the organization, generates a desired pattern of decision making” (Harvard Business Review, 2007). The cloud strategy is composed of – and must be driven by – principles.
• Per Watkins’s definition, a strategy is primarily concerned with “how” one can execute to achieve goals outlined as part of a broader mission/vision.
• Principles are the high-level guardrails that provide consistency and structure to the mission and vision without descending to the tactical level, captured here by the components listed under technology, people, and governance.
• When generating principles, think about the rules that define appropriate tactical responses. If, for example, the overall vision is to reduce costs, a principle might be pursuing standardization as opposed to customization, while a tactic would be using SSO technology to standardize the authentication process for end users.

Discuss: guiding principles

Participants

• CIO
• Management
• Cloud strategy creation team

Key decisions

• Guiding principles
• Contribution of guiding principles to underlying tactics

Questions

• Are there any guiding principles in place that have been incorporated into the cloud strategy informally or into other, related strategies?
• When executing on the cloud strategy, what do all actors need to keep in mind?
• Is there anything in the mission/vision component of the strategy document that can be effectively captured as a guiding principle, focusing on the “how” of the cloud project?
• What overarching principles will inform tactical discussions around people, governance, and technology? What do those making decisions in these areas need to account for?
• What misalignment potential is there? Where could an uneven application of standards cause disruption? Can this be rectified by instituting a formal guiding principle?

1.3 Document guiding principles

1-3 hours

1. Review the questions on the previous slide. Discuss them with the group.
2. If the group identifies a set of guiding principles that apply to the cloud strategy, record those principles.
3. Talk through how the principles would apply in practice. If one is “lower costs,” discuss the projected impact of the cloud on spend. If another is “focus on more valuable work,” ensure that all present understand what work is considered more valuable.
4. Record the results in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: measuring success

A strategy is a blueprint for achieving your goals or mission. But the goals and mission associated with the cloud strategy are often abstract, not reducible to a single element. There is no universally effective way to capture many of the goals that will underpin your cloud vision – only metrics, which serve as proxies for those goals and come with their own strengths and weaknesses. The metrics you choose matter tremendously. As Hauser and Katz argue, “you are what you measure.”

“If a firm measures a, b and c, but not x, y, and z, then managers begin to pay more attention to a, b, and c. Soon those managers who do well on a, b, and c are promoted or are given more responsibilities. Increased pay and bonuses follow. Recognizing these rewards, managers start asking their employees to make decisions and take actions that improve the metrics. […] Soon the entire organization is focused on ways to improve the metrics. The firm gains core strengths in producing a, b, and c. The firm becomes what it measures.”

– John Hauser and Gerald Katz

European Management Journal, 1998

Discuss: measuring success

Participants

• CIO
• Management
• Cloud strategy creation team

Key decisions

• List of cloud strategy success metrics

Questions

• What does success look like?
• What do we care about?
• What is the best way to prove that the cloud initiative has met expectations?
• What information can be realistically gathered?
• What underlying phenomena are most important to the various stakeholder groups?
• What metrics have been attached to similar projects in the past?

Info-Tech Insight

Consider using “tension metrics” to prevent overemphasis on one component of the strategy. A set of tension metrics complement each other such that attempting to game one metric will be detectable in the other. For example, “migration speed” could be held in tension with cost or performance to ensure efficiency and quality of service.

1.4 Document success metrics

1-3 hours

1. Review the questions on the previous slide. Discuss them with the group.
2. Ensure you discuss the story you want to tell about the cloud and that your proposed success metrics align with that story.
3. Once you have a shortlist, go through each one and, with the group, discuss how changes in its value would impact the story you’re trying to tell. If a sample metric is uptime, should the proposed cloud migration increase or decrease it? What can you expect to see if your beliefs about the cloud are true? Refer to any drivers you have previously identified, along with the mission/vision conversation from earlier in this section.
4. Record the list of success metrics in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Phase 2

Record Your People Strategy

This phase will walk you through the following activities:

1. Outline your skills and roles strategy
2. Document your approach to culture and adoption
3. Create a cloud governing body

This phase has the following outcome:

• Documented people strategy

The cloud changes your people strategy

Skills, roles, responsibility – the cloud changes them all

Depending on how you choose to roll it out, the cloud could represent a sea change in how your organization provides IT services. Managing physical infrastructure, spending hundreds of thousands of dollars on equipment in large, relatively infrequent capital outlays, and managing the entirety of the infrastructure stack on premises are skills that can recede in importance with a move to the public cloud. A complete cloud strategy must address the potential disruption caused by a dislocation. The templated document included with this blueprint focuses on three key areas: skills and roles, culture and adoption, and governing bodies.

Skills and roles

There’s a reason cloud skills are among the most sought-after in the job market today: While similar in many ways to the skills developed on premises, new platforms and ways of working – favored in many shops – require staff to train and pick up new skills to succeed. Managing a SaaS environment is very different from managing locally hosted software. Amazon and Microsoft add new services and features with almost alarming regularity. Learning how to properly manage permissions in a PaaS or costs in IaaS can be tricky as well. Your cloud strategy must address these points and others.

Culture and adoption

If you build it, they will come, right? Maybe not. No technology rollout can succeed without buy-in from users. This is especially true when the cloud spells big changes for end users (more self-service, a transition to Chromebooks, etc.). Managing change at the organization level is therefore a critical strategic dimension and must be addressed in the document.

Governing bodies

Decision making in the cloud is important as well. When governance proceeds in a haphazard fashion, an inconsistent deployment – which makes it difficult to acquire needed skills or to convince users to adopt the service – becomes the norm. An understanding of who is going to make decisions (a cross-functional body? A cloud architect?) is a key step in completing the strategy document.

Review: skills and roles

The cloud represents a new or expanding frontier for many organizations. Think about how executing on your cloud vision will impact those tasked with carrying the vision out and managing it on a day-to-day basis. Unfortunately, for many organizations, skilling up is not a simple matter of turning on a tap and watching expertise flow in. According to Pluralsight’s 2021 State of Upskilling Report, 44% of respondents report themselves as underskilled in the cloud management space, among the most significant gaps reported in the document. Cloud deployments can also involve management and orchestration tooling (cloud management platforms), knowledge of multiple cloud environments, and migration tools. Other skills, including vendor management, cost management, and cloud architecture are critical as well. Consider these examples of some cloud roles and the associated skills/responsibilities.

Review: skills and roles

There is no “correct” way to provision skills for the cloud. But there are some common steps that cloud customers take to ensure that the skills and abilities needed to operate in the cloud are available to be leveraged.

Lean on vendors for training: Include training and knowledge transfer as part of cloud service contracts. Cloud providers and third-party vendors have significant experience with migrating and managing transitions to the cloud. This is how they make money. They have valuable insight that they can share – ask questions, build this service into your contracts, and reap the benefits of the experience.

Hire a cloud architect: Go to market for an IT team member with the cloud architecture skills to provide a leadership function and help design the environment in line with best practices. This person will also likely be involved in cloud governance, owning the strategy and participating in the governance committee.

Acquire cloud certifications for key staff: Amazon Web Services, Microsoft Azure, and Google Cloud all have certification paths. The same is true for many PaaS and SaaS providers. For those staff members who own/manage specific platforms, a certification can be a great way to facilitate access to knowledge about cloud services. Certifications can be part of development plans.

Require security awareness training for all staff on an ongoing basis: The cloud represents a shifting/changing risk landscape. Identity becomes even more critical than it has been historically as services migrate out of the datacenter and beyond perimeter defenses. Security is everyone’s responsibility, and the cloud represents an important change in this space.

Conduct a RACI exercise: With changes in the cloud, delineating specific responsibility for operational functions is essential for clarity. Consider conducting a RACI exercise to document how the cloud impacts staff roles and who needs to be involved in specific types of decision making.

Discuss: skills and roles

Participants

• IT management
• Applications
• Infrastructure
• Security
• Human resources (optional)

Key decisions

• Strategic approach to acquiring skills necessary to safely deploy cloud solutions
• Clarification of cloud roles and changes to responsibilities

Questions

• Based on our preferred delivery models, service models, and support models, what skills are going to be required to migrate to – and manage – the cloud going forward?
• Are there any obvious gaps in available skills?
• Must any new roles be created to accommodate additional cloud skills (e.g. billing)?
• What is the best way to fill any skills gaps: training, hiring, outsourcing, etc.? Is there a chosen cloud vendor? If so, are there any relevant certifications (Azure Fundamentals, AWS Solutions Architect, etc.) that might be prerequisites for the strategy to succeed?
• Is there an organizational training function? If so, what would that group’s involvement be in skills and roles?
• Is the operating model going to shift? What are the implications for roles?

2.1 Define approach to skills and roles

1-3 hours

1. Review the questions on the previous slide. Discuss them with the group.
2. Document the skills necessary to execute on the cloud vision, whether those exist in the organization or will need to be acquired elsewhere, and the strategy for procuring those skills (internal IT, MSPs, consultants, etc.).
3. Discuss any new roles that must be created if the skills gaps identified cannot be properly addressed by the existing roles in the organization.
4. Summarize the results of the conversation and record them in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: culture and adoption

“Culture eats strategy for breakfast.” This quote (long misattributed to Peter Drucker but actually from an article in a trade publication covering the paper industry written by Bill Moore and Jerry Rose) reminds the reader that any strategy swimming upstream against culture will fail. The cloud strategy must, therefore, account for the limitations imposed by organizational culture if it is to have a chance of succeeding.

1. Seek and incorporate feedback

• A top-down organizational culture can be effective in some cases, but when making significant changes, it can be difficult to bring others on board.
• Incorporate end users into the decision-making process – seek out and leverage feedback. If you involve potential detractors, they will take partial ownership of the eventual decision and are less likely to cause problems down the line.

2. Show, don’t (just) tell

• Wherever you can, demonstrate specifically what the impact of any changes would be. Use demo environments for SaaS solutions, walk stakeholders through proposed updates to provisioning workflows, and present any information that you’ve used to make your decisions or that you would like interested parties to consider.

3. Evolve and iterate

• Like all strategies, your cloud strategy should not be rigid. Evolve and iterate based on new requirements, market conditions, and even new technology. Let your participants know that the document will evolve, and be sure to discuss what the process for reviewing and updating the strategy is.

Info-Tech Insight

Don’t ask questions you don’t want to know the answer to. If you’ve already decided or there’s some limiting factor that makes a particular path nonviable, set those boundaries up-front instead of gathering feedback that you cannot action. Nothing is worse than filling out a survey or participating in a focus group and later learning that the people running the show have blatantly ignored your feedback.

Discuss: culture and adoption

Participants

• IT management
• HR/change management
• Application/service owners

Key decisions

• Steps necessary to overcome cultural challenges
• Organizational change management strategies
• Communication plan for cloud deployment

Questions

• How much of a change do cloud services represent for the organization? Will that change be difficult?
• What obstacles are likely to prevent a successful cloud transition and what steps can be taken to mitigate the challenges posed?
• For SaaS?
• For PaaS?
• For IaaS?
• Is there a robust organizational change management process in place that has been effective in bringing other services over? Are there any obvious examples of successful implementations that can serve a guiding function?
• Where does responsibility for change management sit – within the PMO or somewhere else?
• What stakeholder groups will need to be involved?

2.2 Define approach to culture and adoption

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. Discuss obstacles to a successful cloud deployment and your response to them. What is their likely cause?
3. Record the results. Consider especially how organizational change management will figure into the cloud strategy and the stakeholders who will need to be considered/the actions that will need to be taken to ensure a smooth transition.
4. Record the results in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: governing bodies

It is crucial to have the right people making the right decisions to drive the success of the cloud strategy. The governing bodies will help align your strategy with the business, establish accountability, and audit value.

Alignment

Drive cloud and business strategy alignment by having business partners accountable for the prioritization and selection of cloud projects and investments. Incorporate stakeholders into your planning process and ensure that your cloud strategy plugs into your broader organizational strategy.

Accountability

The creation of this group facilitates the involvement and commitment of the business through clearly defined roles and accountabilities for cloud decisions. Who is responsible for onboarding new services? Who needs to be consulted when there are budgetary issues? Who sets standards?

Value generation

Participants are responsible for the ongoing evaluation of cloud value and performance of cloud services. The committee should define standards and institute remediation plans for poor performance. This could include switching providers, changing architectural patterns, or even bringing on new staff.

Info-Tech Insight

Your IT operating model is a crucial part of your cloud governance plan. Review Optimize the IT Operating Model for advice on how to redesign your operating model to account for the changes that come with cloud services. You can use this blueprint to create a target operating model based on your knowledge of your users and consumers.

Discuss: Governing bodies

Participants

• IT management
• Application/service owners
• Architecture

Key decisions

• Responsibility for designing and maintaining cloud governance

Questions

• What are the governing bodies for your organization? (Center of Excellence, Cloud Group, IT Steering Committee?)
• What parts of the strategy will they be accountable for? Specifically, who is responsible for what?
• How will they collaborate? Will the cloud governance group meet monthly? Weekly? At a different cadence?
• Why were these groups selected?

2.3 Define cloud governing bodies

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. Record the key items of the conversation:
• Governing bodies
• Membership in the governing bodies
• Broad outline of responsibilities
3. Record the results in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Phase 3

Document Governance Principles

This phase will walk you through the following activities:

1. Document official organizational positions in these governance areas:
1. Architecture
2. Integration and interoperability
3. Operations management
4. Cloud portfolio management
5. Cloud vendor management
6. Finance management
7. Security
8. Data controls

This phase has the following outcome:

• Documented cloud governance strategy

Set and formalize the rules of the game

It’s not sexy, but governance is important

Without stable, consistently applied governance, the cloud strategy cannot be effectively implemented. Governance includes defining and enforcing architectural principles, integration practices, cloud portfolio management, and the introduction of new services into the environment. Upon reading the strategy document, IT staff and users alike should understand who is making decisions, the parameters they are using, the processes they follow, and the overarching purpose of each of the components. They should, in short, understand who is allowed to do what – and why.

This section is the largest, most involved component of the strategy process and requires input in many areas, ranging from architecture and governance to security. Ensure that you have adequate representation from each group before proceeding. As an alternative, consider proceeding in a contingent fashion until you can secure the necessary perspective. You should also have completed the previous section on governing bodies as well; this will help you understand the limits of your approach.

Organizations fall on a spectrum when it comes to strategic direction in the cloud. This can range from those that are cloud-focused or cloud-first (prioritizing the cloud as a strategic end) to those that are cloud-averse (avoiding the cloud for whatever reason). This organizational perspective should have been captured as part of the mission and vision exercise; there should be a firm mission statement that offers a position on general cloud direction and should inform the steps taken to institute governance even at the service level.

Each conversation in this section should result in generalizable principles that you can use to govern decision making going forward. As you’re facilitating these discussions, think about how you can effectively apply standards, any key decision points, and any stakeholders that need to be consulted.

Review: architecture

Cloud architecture is defined loosely as the set of principles underlying integration and functionality within or between services hosted in public clouds, private clouds, or on-premises/in a colocation service. Cloud architects are concerned with setting and enforcing standards to ensure efficient and effective use of cloud resources. Some architectural principles may be exclusive to the cloud; others may extend across cloud and premises-based resources.

Sample architectural principles

• Avoid excessive egress from cloud environments or movement between cloud regions to keep costs low and the service efficient.
• Apply metadata tags in a consistent way to ensure that the ownership and purpose of resources are clear.
• Incorporate security as a design principle, not an afterthought.
• Build redundancy into every service in-line with business requirements for uptime/availability.
• Avoid complicated point-to-point integrations and use an API library for standard interconnectivity.
• Keep chatty applications together in the cloud or on premises to minimize latency.

Info-Tech Insight

Consider reviewing existing architectural guidelines for their suitability as cloud principles. Keep the fundamental cloud characteristics in mind (on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service), and evaluate how your existing principles need to change or what new principles must be identified to align with these characteristics.

Discuss: architecture

Participants

• IT management
• IT architects
• Application/service owners (optional)

Key decisions

• Documented list of architectural principles
• Statements on the architectural future state

Questions

• What architectural principles guide decisions around cloud deployments?
• Are the principles the same in the cloud as they are on premises? If not, how are they different?
• Is there any appetite for new/different architectures, like microservices or serverless computing?
• Are any applications/services set to be refactored? Which ones? Why?

3.1 Define architecture direction

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. As part of the discussion, consider the following points:
1. Record any architectural principles that will guide your cloud deployment
2. Identify any major architecture changes that are implied by the cloud strategy
3. Record the results of the discussion in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: integration and interoperability

Modern IT services are built on effective integration. When services exist in the cloud, in privately owned datacenters, and in colocation services, it becomes essential to understand what can be integrated technically, any additional costs that might be associated with certain types of integrations (e.g. egress charges for moving data out of cloud regions), and what the likely impact will be on performance and maintenance. Consider these broad approaches to cloud integration and how they might fit into your overall cloud strategy:

Principles

• Lean on APIs: Application programming interfaces (APIs) are the core of the cloud integration experience. In a nutshell, APIs represent the rules of engagement for integrating an application with another services. Some providers are more willing to expose public APIs for their SaaS solutions. Some are not. If you own the applications you’re looking to integrate, you may wish to create an API library to enshrine API standards. REST APIs are generally preferable to a point-to-point POST SOAP call, as they are more loosely coupled.
• Loose coupling: An integration is loosely coupled when it comprises a link that can be easily changed or replaced. New application architectures like microservices incorporate this concept, and it may be worth exploring for your applications and services. (Capital One calls microservices that are tightly coupled “distributed monoliths.” The overhead of managing a service like this would probably not be worth it!)
• Avoid middleware wherever possible: When multiple services need a software layer to communicate, this software layer is middleware. Middleware can include more traditional enterprise service bus (ESB) solutions or integration platform as a service (iPaaS) offerings. Middleware solutions like iPaaS are often used in conjunction with API management as part of common platforms. (Mulesoft’s is called “CloudHub,” for example.)
• Ensure compatibility with necessary software: You may have specific requirements for certain types of applications, like compatibility with a single sign-on provider. This should be accounted for in the cloud strategy to ensure that users have a seamless, high-quality experience.

Discuss: integration and interoperability

Participants

• Application owners
• Enterprise/cloud architect(s)
• IT management

Key decisions

• What principles should underly the standards set for integration and interoperability?

Questions

• What services need to be integrated? Are they properly documented?
• Are there any specific standards that must be adhered to for integration purposes?
• Does the proposed architecture of cloud services have any important implications for the integration regime?
• Are there any dependencies (internal or external) that complicate integration standards?
• Should we maintain an API library?
• Are API-related skills (e.g. development, where applicable) well-developed within the organization?

3.2 Define integration approach

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. Specific points of conversation should include the following:
1. Broad architectural direction (see previous section)
2. Implications for integration and interoperability
3. Specific standards that must be applied in the environment (API libraries, integration patterns, templates, etc.)
4. Specific solutions that might be deployed (iPaaS, ESB, etc.
3. Record the results of the conversation in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: operations management

Migrating solutions to the cloud can involve significant changes in operations management. The transition to the cloud has broad implications, but especially in the following areas:

• Service design
• Availability management
• Capacity and performance management
• Configuration management
• Release and deployment management
• Asset management

How the cloud changes these disciplines depends on the preferred service model (SaaS, PaaS, or IaaS), the relative maturity of the existing process, and the strategic goals that the cloud is intended to facilitate. Asset management looks different in a SaaS environment (licenses and allocations) vs. an IaaS environment (components), for example.

Operations management: impacts

Discuss: operations management

Participants

• Asset manager
• Service owners
• Operations management
• IT management

Key decisions

• List of impacted operational management processes
• Optimal operational process changes given the desired cloud future state

Questions

• Reviewing a list of operational management processes, which are most likely to be impacted by the transition to the cloud?
• Are there any processes that are particularly important or warrant specific attention?
• What are the expected changes that the cloud will bring to service design, release management, etc.?
• Does the cloud offer any opportunities to streamline/improve any of these processes?
• Do we have the skills/expertise in house to handle changes to the operational management processes?

3.3 Define operations management process

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. Your discussion should address the following points:
1. Important changes to operations management as a result of the cloud transition
2. Potential improvements to processes
3. Steps that must be taken to ensure that operational management processes proceed as normal post-migration
3. Record the results of the conversation in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: cloud portfolio management

Assuming cloud services will comprise part of your portfolio of services, it is essential to actively monitor this portfolio to ensure that users understand and can access the tools they need to do their jobs. Cloud portfolio management involves ensuring management of the complete lifecycle of new cloud services, from their introduction at the intake stage, to their general availability as part of the service catalog, to their retirement once they are no longer needed or an alternative, more appropriate service is procured. Effective cloud portfolio management means understanding who will own these components of the lifecycle; how they will make decisions about services to be deployed, maintained, and retired; and how this will be communicated to end users.

Discuss: cloud portfolio management

Participants

• IT management
• Service owners
• Asset management

Key decisions

• Changes to portfolio management processes and procedures
• Standards for deploying, maintaining, and retiring new cloud services
• Approach to communicating results of the portfolio management exercise

Questions

• Does the cloud necessitate any changes to existing portfolio management processes and procedures?
• How are services selected for deployment?
• What steps must take place to deploy new, cloud-based services?
• What role should the asset management team play in maintaining a service catalog?
• How mature is the existing service catalog? Do users understand how and what they have access to?
• Are there many exceptions to existing processes? Do these need to be addressed as processes are updated?

3.4 Define portfolio management direction

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. Discuss the proposed lifecycle of cloud services. When are services instantiated? By whom? Under what authority?
3. Describe any important changes to the cloud portfolio management process that come as a result of the portfolio management process.
4. Record the results in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: cloud vendor management

The public cloud means shared responsibility. Vendors have multiple clients and, depending on the cloud service model selected, take different levels of responsibility for the services they provide. SaaS providers, for example, take ownership of the application or service’s infrastructure, while infrastructure components are the responsibility of the customer in IaaS environments. Amazon reminds its customers that it is responsible for security “of” the cloud, while customers are responsible for security “in” the cloud (“Shared Responsibility Model,” Amazon, 2022). Your cloud strategy should account for this shared responsibility and should include statements on the ownership of relationships with vendors, standard contract language that must exist for different types of cloud services, licensing considerations, escalation paths within the vendor’s support system, and so on.

Source: Microsoft, “Shared Responsibility in the Cloud,” 2022

Info-Tech Insight

Responsibility for a given service may be something you can offload to a provider, but accountability will almost always stay with you. The cloud is a tool in your toolkit for providing services to your end users. If cloud services do not meet performance or availability requirements, you are ultimately accountable for resolving the issue, whatever that happens to mean.

Discuss: cloud vendor management

Participants

• IT management
• Vendor management
• Asset management
• Legal
• Procurement/contracting

Key decisions

• Ownership of the vendor management process and management of individual vendors
• Necessary components of a vendor management framework
• Players in the vendor management space

Questions

• How does the shared responsibility model impact our organization? Broadly speaking, what responsibilities will remain with us or be transitioned to a cloud provider?
• Who is currently responsible for vendor management? Does it sit with individual service owners, with a central office?
• Are there any standards that must be applied more broadly beyond boilerplate contract language?
• What happens when vendors fail to live up to their end of the bargain? When should legal and procurement be involved in the vendor management process?

3.5 Define vendor management direction

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. Your discussion should cover the following key areas to be included in the final strategy document:
1. Responsibility for vendor management (centralization vs. decentralization)
2. Principles governing vendor management
3. Changes to vendor management practices brought about as a result of the cloud
3. Record the results of the conversation in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: finance management

Public cloud services are characterized by measured service. In practice, this means that cost is incurred on a consumption basis. This is different from the traditional datacenter which has traditionally required large capital outlays for assets that are depreciated over several years. Different cloud service models are billed differently:

SaaS: When purchasing SaaS licenses, you can expect to be billed on a per-seat basis, though these agreements are not always this simple. Some have additional fees for additional functions/services/credits (like premium connectors in Microsoft’s Power Platform toolset, though depending on how deep you go, this might look more like a PaaS). You should read terms and conditions carefully to understand what is covered by your license and ensure that users cannot incur additional costs.

PaaS: Generally billed on a transaction basis, you can expect to pay for PaaS differently depending on the function that it serves. For example, if you’re using a serverless solution, you may be billed only for transactions executed and for nothing else. Generally, you’re not paying for components specifically in a PaaS environment, but sometimes pricing is based on the underlying infrastructure (e.g. Azure SQL).

IaaS: Pricing is more granular than PaaS. Expect to provision virtual machines and pay based on their size and how long they run – often right down to the second – as well as for storage, ingress/egress, any GPU requirements, and the region the instance is running in.

Info-Tech Insight

The cloud isn’t necessarily cheaper, but the flexible pricing model can introduce cost efficiencies and allow you to free up capital that would otherwise need to be spent on infrastructure refreshes and software licensing.

Review: finance management

Discuss: finance management

Participants

• IT management
• Procurement
• Finance
• Development/operations (optional)

Key decisions

• Acceptable cloud cost models
• Approach to handling cost variability
• Responsibility for managing cost in the cloud

Questions

• How have expectations been set with stakeholders and end users around the cost of cloud services?
• Is there value in taking advantage of the variable cost model?
• Are provisions currently in place to handle cost overages? Can they be built? Who would be responsible for building them? Is there a contingency fund in place?
• Who will be responsible for right-sizing IaaS and PaaS workloads to manage cost overruns?
• What monitoring solutions are in place to review costs? What thresholds (if any) must be set? Who is responsible for acting on cost alerts?
• What is architecture’s role in ensuring that cost is managed effectively? Are any specific principles to be applied?

3.6 Document finance management tactics

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. Your conversation should touch on the service models you’ve chosen to employ as part of the overall cloud strategy, the implication for those service models on management of cloud finances, and responsibility for managing cloud spend.
3. Record the results of the conversation in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: security

Security is the cornerstone of a solid and compliant cloud deployment. Info-Tech’s cloud security framework (pictured on this slide) highlights how different technical security considerations figure into the different cloud service models, along with traditional premises-based infrastructure and endpoints. A cloud strategy should reflect the steps you plan to take to address the areas relevant to the cloud path you choose. In addition to these considerations:

• Training: ensuring that IT staff and end users are familiar with cloud tools, their features, limitations, and common threat vectors (phishing, etc.).
• Mindset shift (security by design): transitioning to the cloud means the death of the traditional perimeter and shared responsibility with the provider. Pushing a mindset shift across the organization can be critical to effectively securing a cloud environment.

Discuss: security

Participants

• IT management
• CISO
• Risk/compliance/privacy

Key decisions

• RACI for security responsibilities
• Process of security training
• Security standards/frameworks that must be broadly applied

Questions

• How do the choices about which clouds to use impact our approach to security/risk?
• What do we understand our responsibility for different areas of security to be (e.g. identity management, physical infrastructure, etc.)? Who internally has accountability for each of these areas?
• What will we do to ensure that vendors maintain secure solutions?
• Do all stakeholders understand how a transition to the cloud will impact the organizational risk profile?
• Are there any compliance requirements that necessitate specific approaches to security (CJIS, ISO, etc.)?
• Is in-house expertise sufficient to meet security requirements?
• Are there any security tools that must be integrated/compatible with all cloud solutions (e.g. SSO, SIEM)?

3.7 Define approach to cloud security

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. Focus on the following areas for the strategy document:
1. Key security principles that will be applied in the cloud
2. Security/compliance standards/frameworks that must be adhered to
3. Known risks/roadblocks associated with the chosen cloud direction
4. Strategies and tactics for ensuring maximum security in the cloud from a people perspective
3. Record the results in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: data controls

Data is essential to the modern economy. It fuels the engine of innovation. But with this great power and utility comes commensurate responsibility – data stewardship is among the most important tasks of the modern IT shop. The cloud complicates matters somewhat. Sharing responsibility with providers introduces considerations around data sovereignty, protection, and quality:

• Data sovereignty: You are responsible for the data entrusted to your care. Ensure that your relationships with cloud providers account for your responsibilities to external regulators, internal stakeholders, and – most of all – the customers/clients/members/donors/users who entrust you with their data. For all workloads, ensure that you understand how providers are going to use your data, where they will store it, and how they will respond in the event of a breach.
• Data protection: Ensuring that your data remains secure and available no matter where it is, is a critical component of cloud strategy. How will the data be backed up – including SaaS and PaaS deployments? What does disaster recovery look like? Consider governing your data following a best practice framework and using data loss prevention technology to secure your data in the cloud.
• Data quality: Ensuring data quality may be the responsibility of the owners of the source systems, or it may belong to the team that manages platforms that leverage data in the cloud. Understanding responsibility and ensuring that data is appropriately sanitized/masked before transitioning to the cloud is important.

Info-Tech Insight

A chain is only as strong as its weakest link. If you’ve got a mass of ungoverned data, you should treat it as though it could contain sensitive information and act accordingly.

Discuss: Data controls

Participants

• IT management
• CISO
• Risk/compliance/privacy
• Information architecture/governance

Key decisions

• Relevant compliance criteria
• Data quality processes and procedures
• Data protection standards, including backup and disaster recovery

Questions

• Do we have a solid data inventory? Do we know what data is where?
• What requirements are the various types of data subject to? Are there any specific regulatory or contractual provisions that limit where data can go?
• What information is required from cloud providers to ensure that they are compliant with data sovereignty requirements?
• Are there any compliance standards that providers are expected to meet if they will be working with sensitive data?
• How do you expect providers to respond to a breach?
• Who is responsible/accountable for data quality?

3.8 Define data controls in the cloud

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. Use your answers to these questions to develop and validate positions in the following areas:
1. Compliance requirements related to data
2. Data quality processes and procedures
3. Data protection, including backup in the cloud
3. Record the results in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Phase 4

Formalize Your Technology Strategy

This phase will walk you through the following activities:

1. Formalize organizational approach to monitoring
2. Document provisioning process
3. Outline migration processes and procedures

This phase has the following outcome:

• Documented cloud technology strategy

Cloud technology

Monitoring, provisioning, and migrating – what does the cloud mean for you?

People and process are arguably the most important cogs in the cloud machine, but technology – the tools used to provision, monitor, and migrate to and from cloud solutions – cannot be overlooked. While tech alone can’t solve all your problems, leveraging the right technology at the right time in the right way can be the difference between a successful, value-driving cloud deployment and an abject, miserable, no-good zombie project that eats up resources without anything to show for it.

How should technology figure into your cloud strategy?

Cloud technology encompasses significant breadth such that it is unrealistic to include every possible permutation here, especially when considering the multiplicity of service/delivery models available for purchase/consumption. That said, there are several technology components that all cloud customers are going to encounter in one form or another:

Monitoring

Monitoring in the cloud can be conducted using either the native solutions offered by providers or a third-party toolset like SolarWinds. Critical to success is understanding what must be monitored, how it will be monitored, and the steps that must be taken once an alert/alarm is received.

Provisioning

With the cloud comes speed, agility, and automation – provided you take advantage, of course! Understanding how resources are provisioned, who is responsible for provisioning, what the pipeline looks like – which automation tools are used, for example – and how these processes differ based on the service model in question.

Migration

The act of migrating to the cloud may also be a component of the broader cloud strategy. Based on requirements and technical capabilities, migration paths will vary and should be systematized (rehost, replatform, refactor, etc.).

Review: monitoring

One of the key risks identified by current and potential cloud customers is monitoring. Migrating to a public cloud and embarking on the journey of shared responsibility can be daunting. Figuring out how you’re going to monitor systems in the cloud – and accept those which you cannot monitor – is going to be critical to the success of your cloud initiative. Keep in mind that the cloud is not a monolith and what you monitor (and with what tools) will depend a great deal on the cloud service/delivery models you choose to procure and deploy. SaaS providers are going to be less likely to expose necessary APIs or make in-depth monitoring solutions available, while entire suites of monitoring and management solutions are available to IaaS customers. Keep the following in mind as you develop your cloud monitoring strategy:

• Understand your requirements. What are you looking to accomplish via monitoring? You may need to monitor performance, uptime, security incidents – ensure that you understand exactly what’s on the table and what your specific requirements are.
• You may already have a monitoring solution in mind or rolled out. It may be valuable to ensure that any cloud applications you’ve selected for deployment are compatible with your preferred monitoring solution. This is relatively easy to implement and shouldn’t winnow down your shortlist of candidates too much.
• Work with stakeholders to manage expectations. Going to the cloud involves trade-offs. Ensure that your stakeholders understand that, while you may not be able to track all the details they would like, what you’re getting in return (shared responsibility with a provider for updates, security, provisioning, etc.) means that the good outweighs the bad. If the good does not outweigh the bad in the case of a particular workload, reconsider deploying that workload to the cloud.

Info-Tech Insight

Don’t ask questions you don’t want to know the answer to. It’s fine to monitor solutions to ensure compliance with SLAs. It’s also fine to keep tabs on application performance so you can anticipate a deluge of customer complaints. It’s not fine to spend a ton of money collecting information you have no intention of doing anything with. When designing your monitoring program, think about how you will use the information. If you don’t have an obvious or compelling answer, reconsider your plans.

Discuss: monitoring

Participants

• Infrastructure management
• Infrastructure team/system administrators
• Application owners
• Enterprise architecture

Key decisions

• Solutions that must be monitored
• Technical solutions for monitoring
• Plan for actioning alerts/alarms

Questions

• What workloads require monitoring? Are there hard and fast rules about monitoring and specific requirements?
• What must be monitored? Performance? Uptime? Cost? Security? All of the above? Something else? Ensure that you understand your monitoring requirements as part of the strategy.
• Who will elicit requirements for monitoring? Who will they gather them from?
• What technology will administrators use to monitor cloud workloads? Will they use solution-native solutions like Azure Monitor, or third-party solutions like Datadog, Splunk, or Dynatrace?
• Who is responsible for receiving alerts? What do they do when they receive the alerts? Is there a current process that can be built upon?

4.1 Define cloud monitoring strategy

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
1. What is the goal of the monitoring program?
2. What services need to be monitored?
3. What solutions for this monitoring exist/need to be procured?
4. What are the gaps that still need to be addressed in providing the solution?
2. Record the results of the conversations – and the answers to these questions – in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: provisioning

One of the key characteristics that differentiates cloud services from traditional premises-based or hosted solutions is provisioning, the allocation of provider resources. The legacy provisioning model – negotiate a fixed price for a fixed solution – is outmoded in the cloud era. Instead, the cloud is characterized by modern approaches to provisioning: dynamic and self-service provisioning. Your cloud strategy should provide direction on provisioning, including preferred methods and governance around the process.

• Self-service: Cloud customers have the option to provision resources (compute, storage, etc.) at will. They can resize instances, add more resources, and pay only for the resources that they use. This can be especially useful when the cloud transition is predicated on agility and speed. Looking to embrace DevOps principles? Consider exploring best practices (Red Hat provides some good examples of these practices), including approved templates, cloud-native IDEs, and cloud APIs.
• Dynamic: like self-service provisioning, dynamic provisioning provides price flexibility via a pay-as-you-go model, but it is generally automated insofar as the customer specifies requirements and the provider provisions resources as-needed to meet those requirements. Oracle offers a good primer on dynamic provisioning in their environment, highlighting how this model can introduce automation and reduce overhead for IT administrators, allowing them to focus on more valuable work or manage more complicated infrastructure environments.

Info-Tech Insight

It might be tempting to implement governance restrictions like those you use on premises, but you should think twice before doing this. One of the key drivers most organizations cite when moving to the cloud is the opportunity for dynamism and agility. Don’t let fear of change lock you into the past.

Discuss: provisioning

Participants

• Infrastructure management
• Cloud users (developers)
• IT management/finance

Key decisions

• Responsibility for provisioning
• Tools used to provision resources in the cloud
• Principles and best practices that must be applied in governing the provisioning of cloud resources

Questions

• Who is responsible for provisioning cloud workloads?
• Are SaaS licenses managed centrally or on an application-by-application basis?
• What are the architectural principles that will define the templates built into cloud services (like Azure Resource Manager or CloudFormation on AWS)?
• Will you be using third-party cloud management platforms for infrastructure automation like Morpheus Data, CloudBolt, or Snow Commander?
• What does governance look like in these environments? Who is ultimately responsible for ensuring that anyone who needs to spin up resources can do so within the guardrails defined by the platform owner?
• How will provisioning differ in Dev/Test compared to production?
• How will metadata tagging figure into the provisioning conversation?
• Who will be responsible for gathering requirements from cloud customers regarding their provisioning needs?

4.2 Define cloud provisioning strategy

1-3 hours

1. Review the questions on the previous slide. Discuss them with the group. Specifically, the goal is to understand how the cloud changes provisioning, if at all, and what the future state looks like.
1. Review existing solutions
2. Discuss roles and responsibilities in the cloud
2. Record the results in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Review: migration

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.

Discuss: migration

Participants

• IT management
• Infrastructure leadership
• System administrators
• Application owners
• Enterprise architecture

Key decisions

• Acceptable migration paths
• Responsibility for the cloud migration
• Involvement of third parties in the migration process

Questions

• Which of the four cloud-focused Rs (rehost, replatform, repurchase, and refactor) are relevant for your cloud migration?
• How will you decide what workloads fall into which category? Who ultimately makes the decision?
• Are the skills/resources available to ensure that the preferred migration path can proceed successfully? Do you have the engineering talent in house required for a successful refactor, for example?
• Are any destinations temporary? If, for example, the goal is to rehost in the short term and refactor in the long term, this should be captured in the strategy.
• Is there an appetite for using third-party resources like contractors or vendors with specific knowledge of cloud migration techniques?

4.3 Define cloud migration strategy

1-3 hours

1. Review the questions on the previous slide. Discuss with the group.
2. Use the 6Rs framework and align workloads and workload categories with different migration paths (e.g. “communications and collaboration software services belong in SaaS”).
3. Create a table with each acceptable migration path, include a description of when you will take advantage of it, along with examples of when you will use each service.
4. Record the results in the Cloud Strategy Document template.

Download the Cloud Strategy Document template

Summary of Accomplishment

Problem Solved

Knowledge Gained

• Info-Tech’s approach to cloud strategy
• The components of a complete cloud strategy
• Tools for clarifying/justifying cloud spend

Process Optimized

• Cloud workload selection
• Cloud migration
• Cloud provisioning
• Skill/role definition in the cloud

Deliverables Completed

• Cloud Strategy Document

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:

Skills/roles discussion

Work with Info-Tech analysts to define roles and responsibilities that will inevitably become critical to the success of your cloud migration initiative.

Architecture discussion

Define key architectural principles that will be used to govern your cloud environment, ensuring consistency, quality, and portability.

Related Info-Tech Research

Define Your Cloud Vision

Define your goals, drivers, cloud mission, and desired future state before jumping headlong into a strategy conversation you’re not ready to have. Analyze some workloads for their cloud suitability, while you’re at it.

Manage Cloud Costs: Tips and Tricks

The cloud can be a wonderfully valuable tool in your toolkit, but you may want to explore some of the implications of the transition from an overall cost perspective, a cost variability perspective, and a cost complexity perspective. This set will help you do that.

Take Control of Cloud Costs on Microsoft Azure

If you’ve decided to move to the cloud – Microsoft Azure, specifically – you may want to review some of the specific steps, including tagging, monitoring, alerting, and right-sizing.

Bibliography

Apple, Pete. “Microsoft Uses a Scream Test to Silence its Unused Servers.” Microsoft Inside Track, October 20, 2021. Accessed Jan. 2022.

“AWS CloudFormation.” Amazon Web Services. Accessed Jan. 2022.

“AWS Lambda Pricing.” Amazon Web Services. Accessed Jan. 2022.

“Azure Monitor.” Microsoft. Accessed Jan. 2022.

“Azure Resource Manager.” Microsoft, 4 Feb. 2022. Accessed Feb. 2022.

“Azure SQL Database Pricing.” Microsoft. Accessed Jan. 2022.

Buchanan, Ian. “Infrastructure as Code: How Infrastructure as Code (IaC) Manages Complex Infrastructures.” Atlassian. Accessed Jan. 2022.

Churchville, Fred. “What Is iPaaS? Guide to Integration Platform as a Service.” TechTarget. June 2021. Accessed Jan. 2022.

“CloudHub.” Mulesoft. Accessed Jan. 2022.

“Datadog.” Datadog. Accessed Jan. 2022.

“Dynatrace.” Dynatrace. Accessed Jan. 2022.

“Enterprise Manager Cloud Administration Guide.” Oracle. Accessed. Jan. 2022.

Flexera. “State of the Cloud Report.” Flexera. 2021. Accessed Jan. 2022.

Hauser, John and Gerald Katz, “Metrics: You Are What You Measure!” European Management Journal, 16 no. 5 (1998): 517-528.

Henderson, Chloe. “4 Types of System Integration – Pros vs. Cons of Each Method.” AnyConnector. 24 July 2020. Accessed Jan. 2022.

“List of All Premium Tier Connectors.” Microsoft. 3 Feb. 2022. Accessed Feb. 2022.

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

Montgomery, James. “Cloud Provisioning.” TechTarget. Accessed Jan. 2022.

“Morpheus Data.” Morpheus Data. N.d. Web. Jan. 2022.

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

“Peter Drucker,” Wikiquote. Accessed Jan. 2022.

“Power Platform.” Microsoft. Accessed Jan. 2022.

Rajabi, Mariam. “How to Avoid Coupling in Microservices Design.” Capital One. 2 Dec. 2020. Accessed Jan. 2022.

“Shared Responsibility in the Cloud.” Microsoft. 2 Jan. 2022. Accessed Jan. 2022.

“Shared Responsibility Model.” Amazon Web Services. Accessed Jan. 2022.

“Snow Commander.” Snow. Accessed Jan. 2022.

“Splunk.” Splunk. Accessed Jan. 2022.

Swanepol, John et al. “Cloud Architecture: 4 Steps to Design Self-Service Access to Shared Resources.” Red Hat. 29 Apr. 2021. Accessed Jan. 2022.

“The Power of CloudBolt Explained.” CloudBolt Software. Accessed Jan. 2022.

“Types of Databases on Azure.” Microsoft. Accessed Jan. 2022.

Watkins, Michael D. “Demystifying Strategy: The What, Who, How, and Why.” Harvard Business Review, 10 Sept. 2007. Accessed Jan. 2022.

“What is Cost Management + Billing?” Microsoft, 13 Feb. 2022. Accessed Jan. 2022.

“What is Self-Service Provisioning in Cloud Computing?” CloudBolt. Accessed Jan. 2022.