The Importance of a Cloud Strategy

Keep your cloud strategy simple, flexible and effective with this easy to use guide. Follow our own step-by-step process to analyze which cloud technologies your organization should prioritize, mitigate the risks of doing so and communicate the strategy effectively throughout your organization.

The blog was originally published here.

A clear, unambiguous, and widely-communicated cloud strategy is critical to the successful transformation of an IT organization. The creation and publication of the cloud strategy document serves to align the various teams across an enterprise to a cohesive plan which informs and guides the adoption of cloud services.

The creation of a cloud strategy may seem overwhelming at first, but it shouldn’t be. It is not intended to be a precise, detailed set of instructions for every technology loosely defined as “cloud”. Rather it should be a clear, concise, high-level analysis of which cloud technologies your organization should prioritize, with guidance to lower the risks associated with the adoption of these technologies.

Why do you need a cloud strategy?

While many enterprises have announced a “Cloud-First” approach, not all have a well-defined strategy that communicates the “why”, “how”, or even the “what” of cloud adoption. A cloud strategy is essential to guide your organization through the transition to the cloud by balancing expected benefits with guardrails to reduce risk exposure.

Without a strategy, business groups and users will adopt solutions to increase productivity as they become available. Many organizations have already experienced this in the form of “Shadow IT”.  The absence of a cloud strategy leaves these teams with little guidance for cloud service adoption leading to silos of technology, non-standard solution implementations, non-optimized costs, and greater exposure to risk from poorly configured environments.

Who should create a cloud strategy?

In many organizations the “Cloud Architect” will define and communicate the cloud strategy, working with leadership and business units as well as security and technology teams. Some organizations have already adopted several cloud technologies without a cloud architect or a defined strategy. In these cases, it is not important who creates the strategy as long as it is built collaboratively and supported by leadership before being communicated internally. Often, we find IT teams hear “Cloud-First” from leadership and then await further guidance. After all, you wouldn’t make such a statement without a clear plan, would you? Well, you might be surprised. When the cloud mandate gets out ahead of the cloud strategy, IT teams can help by drafting a strategy document and presenting it to leadership as the basis for further discussion and clarification.

What is the purpose of a cloud strategy?

• Identify the key benefits associated with cloud service consumption that apply to your organization.
• Determine which services you will build internally and which services will be consumed from a public cloud provider partner.
• Identify the partnerships your organization has (or is developing) with public cloud providers for those services (approved service providers).
• Communicate the approved service providers and associated services. State the risk of utilizing resources from a non-approved provider and determine the consequences of non-approved service consumption. Define and communicate the process to have a service provider or service added to the approved list.
• Determine how your organization will provide consistent policy and governance across disparate services and environments, as well as a consistent consumption and management layer.
• Determine protections needed to reduce the risks to data privacy, service costs, resource availability, and others. Until these protections have been established, an “on-premises”, private cloud strategy is best to safely provide your users with the resources they need.

Public / Private / Hybrid?

The cloud strategy will support alignment across teams supporting public and private environments. Your organization may be just starting on the journey to the cloud, or there may already be entire teams dedicated to supporting AWS and Azure workloads in your environment. Some services make more sense than others to consume from a public cloud provider. With IaaS workloads, for example, many organizations found that public cloud hosting led to higher costs and limited visibility. These organizations are taking another look at their private cloud offerings to expand the capabilities and prioritize on-premises environments for IaaS.  A private/hybrid cloud approach can provide many of the capabilities required to meet the needs of the business while providing a better consumer experience and superior governance to consuming those services directly from a public provider. Many organizations are looking to a management platform like the vRealize Suite to broker public and private cloud resources through a common consumption layer while ensuring full governance and compliance through automation.

What should a cloud strategy include?

At a minimum the cloud strategy should include the following sections:

• Scope: The scope of the strategy – what is included and what is not – along with sufficient definition for consumption by non-IT readers.
• Alignment to a larger strategic initiative – Ideally, there will be a larger “transformation” initiative to align with. This will help in several areas, including identifying business objectives, gaining leadership support, increasing organizational collaboration, and supporting requests for funding.
• Business objectives driving cloud service adoption – For example, datacenter lease expiration, the need to optimize IT costs, or new capabilities required to support a new business offering.
• Capabilities mapped to business objectives – High-level capabilities to support the business objectives, including identification of the consumer and consumption requirements, and capability prioritization. For example, on-demand application provisioning with application definition as code for IT teams via global catalog,  Kubernetes cluster deployments for application developers via API.
• Current state – The current state of your organization in regard to cloud service adoption, supported by an analysis of cloud services currently in use. While an internal survey can be used to collect some information, a more effective analysis should be done using a “Shadow IT Discovery” tool. Many security organizations offer this service, installing a “Cloud Access Security Broker” (CASB) on the network for a period of time to analyze and report on traffic patterns to external cloud providers.
• Desired state – The desired state for cloud service adoption for the next 2-5 years, including approved public cloud partners and services, capabilities to be supported by a private/hybrid cloud, and criteria and KPIs to measure and report on success.
• Dependencies – What must be in place to support the successful adoption of the defined services? For example, data classification to determine workload placement requirements, a Cloud Management Platform to provide common governance and policy enforcement across private and public and hybrid environments, or maybe an updated chargeback model.
• Risks – Internal and external risk. For example, resource limitations or a lack of required skill sets.
•  High-level path to adoption – A high-level plan of adoption for cloud services and supporting capabilities:
  • An evolutionary or revolutionary approach to cloud service adoption? Most Enterprises will favor an evolutionary approach so that existing investments can be utilized, and resources and skillsets can be updated over time. For example, a solid foundation for IaaS should be built and proven in a private cloud environment before extending to a hybrid or public cloud. One solution will build on another, for example, PaaS will build on IaaS.
  • Recommendations for the hosting criteria of services and workloads. The cloud strategy is not where the criteria should be maintained, but it should link to the defined criteria or list the criteria as a dependency for cloud service adoption.
  • Private cloud service creation – a prioritization of services to be built for the private/hybrid cloud environment and a high-level timeline.
  • Public cloud service adoption – which services will be consumed from a public cloud provider.
  • Strategic partnership development with public cloud providers, including security considerations for relevant regulatory and compliance requirements (PCIS DSS, HIPAA, SOX, FISMA, DFARS, FEDRAMP).
  • Implementation of a common security framework (for example, NIST, ISO 27001 or CIS) to streamline analysis for the authorization of new vendors or services.
  • Key Performance Indicator (KPI) definition for measurable outcomes for the adoption of services (for example, service consumption, service provisioning time, cost). It is important to measure the value derived from providing private/hybrid cloud services (or consuming public cloud services). This becomes critical when planning additional service development or requesting additional resources.
• Organizational recommendations – What will the support model look like? Many organizations have implemented a “Cloud Architecture Team” or “Cloud Center of Excellence” (CCoE) to define and manage cloud services, and a “Cloud Operations Team” to support them. These are cross-functional teams with Subject Matter Experts (SMEs) from various technical disciplines such as networking, storage, Windows and Linux, application development and security. Other organizations separate teams by discipline, for example, dedicated Azure and AWS teams. We recommend the creation of a CCoE to define consistent standards and policies across public and private environments.
• Exit strategy – How to move services and resources out of a public cloud environment requires as much upfront consideration as the initial provisioning or migration. Don’t leave this analysis until you need to move workloads as it may be too late. The complexity of moving data and resources once provisioned to a public cloud provider will vary by provider and should be well understood before any workloads are provisioned. The best way to protect resources and data from “lock-in” is to use a hybrid cloud approach – that is to extend infrastructure resources to a public cloud provider to take advantage of the agility and flexibility of the hyper-scalers, without changing the underlying architecture. VMware Cloud Foundation allows the extension of your private cloud into a public cloud provider (for flexible capacity, data localization or temporary scale requirements) while maintaining the underlying vSphere constructs – meaning that the exit strategy for these workloads could be as simple as a vMotion. An exit strategy should be included in the analysis of any third-party service provider.
• Stakeholders – Clearly defined roles and responsibilities for key stakeholders is critical to the successful creation and execution of any cloud strategy. Involve your stakeholders as early as possible to provide input to the strategy and to support its communication and implementation. Stakeholders will include, but may not be limited to, resources from the following teams:
  • Executive stakeholder – preferably the CIO or VP of Infrastructure or Applications
  • Security Team
  • Application Development Team
  • Infrastructure Team
  • Finance Team
• Strategy review  – How often will the strategy be reviewed and updated? It should be high level enough that a review once a year is sufficient.
• Supporting information – Include links to supporting documentation, supporting strategies, policies, and where to find more information or direct questions.

There may be initial resistance to the cloud strategy. Open and honest communication with stakeholder teams will help to alleviate many concerns. There will also be corner cases or exceptions that are not covered by the strategy. Use the 80/20 rule for guidance. The first draft will not be perfect, it will need to be reviewed and updated as your organization matures. If it seems to be getting too detailed refer back to the original intent of the document and reduce the scope:

• Identify the key benefits of cloud technology adoption for your organization.
• Decide which capabilities will be provided from a private, on-premises cloud. Prioritize the creation of these services.
• Partner with key public cloud providers and maintain a published list of approved cloud services.
• Identify and implement the protections required to reduce the risk of moving data and resources to the cloud and ensure there is a clearly defined exit strategy.
• Communicate with stakeholders and internal teams to increase adherence to the strategy and reduce the likelihood of “Shadow IT”.

How to communicate the cloud strategy?

Once the cloud strategy has been created it should be widely communicated throughout your organization. Share the document on an accessible internal repository and request that it be announced at the highest possible level, preferably at an “All-Hands” meeting of the VP of IT or CIO. Then request an audience at team meetings for each level until it has been presented to everyone in the organization. Request interaction and allow feedback within these formats to increase the likelihood that it has been absorbed and understood by everyone in the IT organization.

Final Thoughts

Prior to joining VMware, I developed and implemented the cloud strategy at 2 different organizations where I was the Cloud Architect. It is a time-consuming process that requires collaboration, patience, research, and documentation. That said, I consider it to be time well spent. The process is critical to the long term success of using cloud services to support an organization’s digital transformation. Organizational transformation requires alignment across IT teams, business teams, and application development teams. The earlier the stakeholder teams can be involved in the creation of the strategy the higher the probability that it will meet their requirements, gain their support and achieve the level of collaboration required for organizational success. The strategy will evolve as the technology evolves, but a strategy should always answer the basics – what are we doing, why are we doing it, how are we doing it, and how will we know if we are successful?

References

The NIST Definition of Cloud Computing: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

Center for Internet Security: https://www.cisecurity.org/cis-benchmarks/