Develop a Cloud Strategy That Aligns With Business Goals
Proper preparation can yield IT and business success.
By Kristin Lewotsky08/01/2018
How you pursue a goal is as important to achieving it as identifying the goal in the first place. According to a study by Dominican University researchers, participants who wrote down their goals were significantly more likely to reach them. Moreover, study members who detailed the specific actions they would take and made regular progress reports were significantly more likely to achieve their objectives. Identifying a goal and building a strategy are essential steps to success. That particularly holds for complex and business-critical measures like cloud implementation.
Few organizations would dispute the value of cloud computing—and many are in the process of moving workloads onto the cloud. Perhaps developers are working on a cloud deployment in tandem with a business partner, or a business unit is using the public cloud surreptitiously via credit card. At the other end of the spectrum, the IT department may be using a virtualization layer to achieve private cloud functionality. These types of activities may result in some benefit, but may fail to deliver a competitive advantage to the business because they lack focus. To be effective, a cloud deployment needs to be based on a well thought out strategy that’s tied to the overall business strategy. As the Dominican University study showed, stating the goal is the first step to success.
Proper Cloud Strategy Alignment
“It’s so important to make sure alignment exists from the cloud strategy through the IT strategy and into the business strategy,” says Eric Marks, vice president of cloud consulting for Boston-based Cloud Spectator. “The process of determining cloud strategy can help enable and drive decisions around fundamental questions, such as ‘What is the organization’s core business model?’ ”
The process begins with determining top-line strategy. What will cloud do for the business and how will it be applied? “If you say the cloud is transformative, the question is, ‘What are you transforming?’ Are you transforming IT and IT delivery with the cloud?” Marks asks. “Or are you transforming the entire business? The distinction matters.”
Transforming IT brings significant value to the business, including improved alignment of IT costs with business operating expenses, and faster delivery to match the cadence of new product and service development within the business. “If you just stop there, however, you’re leaving a lot of potential transformative value on the table,” says Marks. “If you start to look at cloud applied to the entirety of a business model, then you can start to fundamentally change the way you build, design and provision new products and services. The process starts to feel like a digital transformation where cloud is looked at from the entirety of the value chain and not just within IT.”
The Decision Tree
Given the complexity of business, it stands to reason that no single cloud architecture can address the needs of all enterprises. Increasingly, companies are pursuing hybrid public/private cloud strategies. In these implementations, a substantial amount of the company portfolio remains on premises in a private cloud, while less sensitive workloads are moved to one or more public clouds.
Even organizations with large amounts of sensitive data, such as financial services or healthcare organizations, still have applications that can be deployed with confidence into a properly secured public cloud. Moving as little as 20 to 30 percent of the legacy computing portfolio to the public cloud still frees up resources and enables the IT shop and the organization as a whole to be both strategic and agile. The key is to develop a cloud deployment strategy that will enable the company to advance business objectives and meet compliance, security and risk requirements—while also taking advantage of the speed and cost benefits of the public cloud.
The aforementioned study noted that writing down specific actions focused efforts and drove success. A formal cloud strategy details the basic elements of the project: the vision; the mission; and the set of documented goals, objectives, strategies and tactics that will be followed during implementation. The strategy should be data driven, with third-party assessments of cost, ROI and payback period. It should also include a clear assessment of organizational and cultural issues and how they may affect the process and impact the success of the initiative.
The first step in determining where workloads and data should be located is to evaluate data sensitivity. Are there privacy concerns? If so, the workloads will most likely be deployed in a private cloud, usually on premises. Workloads that present less risk, such as email or application development and testing, could be moved to one or more public clouds.
The next step is to consider compliance issues: These can involve everything from financial regulations to privacy controls such as the recently activated General Data Protection Regulation. These considerations also control whether a public cloud will enable the organization to comply with regulations or whether the regulatory requirements call for a private cloud.
Data evaluation isn’t a one-time exercise, but an ongoing process that must be governed by a clearly defined data classification scheme. Such a scheme establishes the data hierarchy that will be applied to all new workloads. It also can be used to guide the migration of the legacy portfolio into the cloud. A good portion of the legacy portfolio is likely to remain on premises. It may be modernized, perhaps moved onto a new platform for deployment into an internal private cloud. The data classification scheme will make these decisions straightforward. It’s an effective tool for risk management, and it can be used to establish rules for automatic provisioning.
Once the data classification scheme is in place and workloads have been assigned to the public or private cloud, the next step is to determine the order of buildout. While companies may be tempted to build out both public and private cloud simultaneously, this strategy frequently leads to grief, says Marks. “Companies often think they can get it all done at the same time but there is an organizational aspect of commitment to the cloud that most organizations haven’t figured out yet,” he observes. “The sequencing of adoption matters a lot.”
The most appropriate strategy depends upon the starting point. If an organization already has public cloud services in place (officially or via rogue efforts), then the public cloud should be the starting point. The goal should be to put an organizational structure around public cloud providers to gain control over the workloads already deployed. This enables users to continue cloud access but in a secure, governed, compliance-centric manner. During this phase, non-sensitive workloads also can be moved into the cloud.
One of the key aspects of public-cloud strategy is portability and interoperability across providers and environments. “An organization shouldn’t lock in with just one public cloud provider,” says Marks. “I always suggest that clients have at least two of the hyperscale providers in their portfolios just to counteract each other on price negotiations, and then they might have a small-scale specialty provider in their mix just to keep the hyperscale guys honest.”
This approach is only effective if the workloads are portable. Designing new applications for the proprietary APIs of a cloud provider can lock an organization to the service, whether the contract is cost-effective or not. A better, more cloud native approach is to containerize applications so they are platform independent and can be moved easily from the premises network to the public cloud for testing, from the public cloud to the premises network for deployment, or from public cloud to public cloud to take advantage of better service or pricing. The approach offers significant strategic benefit, although it does require a certain amount of skill from the IT shop.
Speaking of staff, a widely held misconception suggests that moving workloads to the public cloud equates to cuts in the in-house IT staff. That’s not exactly the case. Certainly, offloading workloads like email and HR to the public cloud moves the responsibility for these workloads to the IT staff of the provider, but the project still requires internal staff to interact with the cloud provider and manage workloads on an ongoing basis.
Particularly in sectors like financial services, healthcare, retail and defense, organizations have large amounts of sensitive data to protect. These legacy workloads may be subject to regulatory requirements that prevent them from being deployed on the public cloud. The private cloud is a common solution, whether it’s located on premises, in a corporate data center or in multiple locations for backup.
A private cloud requires a platform that features robust security and virtualization layers. It will need staffing by individuals with the appropriate skill sets, and it will take time to deploy. It’s essential to develop accurate cost numbers for a private cloud, not just for initial buildout but for operations going forward. These costs not only include day-to-day operations but also refresh costs for the inevitable time when the capabilities of the private cloud no longer match the needs of the business.
“I find that the internal teams tend to undercount the actual cost as compared to the future costs of sustaining the cloud environment,” Marks says. “Public-cloud providers have the refresh costs factored into their business models. How often does your IT shop have the opportunity to do a full refresh of an IT infrastructure? Are they really, truly accommodating all of those costs and the associated risks, etc.? I find some of that is undercounted in the baseline numbers of the cost of the private cloud.”
“It’s so important to make sure alignment exists from the cloud strategy through the IT strategy and into the business strategy.”—Eric Marks, vice president of cloud consulting, Cloud Spectator
Organizations in the midst of building out a private cloud may be tempted to make another mistake: attempting to outdo the public cloud providers at their own games. That’s not an effective use of resources, Marks explains. “The private cloud shouldn’t try to be a private Amazon because it will fail,” he says. “An organization will never be able to compete with the hyperscale providers because they are too fast, too massive.”
Enterprises are better off dedicating their private cloud to data-sensitive workloads and requirements that only the in-house organization can deliver well. The private cloud and its staff should supply a unique set of capabilities that are specific to the enterprise. “I believe that the totality of the portfolio of your private cloud services should be the specialized capabilities where your IT team knows the business better than anyone else,” says Marks. “They can build direct services to deal with the data-sensitive workloads, proprietary workloads and the industry-specific work.”
The private cloud should mirror the supports, speed of provisioning, self-service functionality and cost of what public-cloud providers offer. The IT shop should benchmark against the hyperscale providers. It’s important to remember that private cloud organizations offer a set of unique services because they know the customer and the business.
The Hybrid Strategy
Once the public and private clouds are built out, the next step is to bring them into a unified catalog of services that can be provisioned with self-service technologies and capabilities to make them available to business units throughout the organization, as well as business partners. With proper application of role-based access, rules for automated provisioning and best-practices security, the hybrid cloud can support the business case while protecting the customer, the business partners and the enterprise itself.
With a clear understanding of the cost basis for public and private clouds, as well as the requirements of various workloads, organizations can make increasingly sophisticated decisions about deployment. “What if you have some means by which you could use cloud management and benchmarking analytics to make semi-real time decisions on where workloads best run to drive cost savings?” Marks suggests.
Enterprises wouldn’t just use this framework to decide between public and private clouds but also to choose among multiple public-cloud vendors. “Not many people are able to think that way yet or they don’t have a realistic mechanism to implement it, but I do believe it’s not that far off in the future,” he adds.
Kristin Lewotsky is a freelance technology writer based in Amherst, NH.