Special Feature
Part of a ZDNet Special Feature: Managing the Multicloud

Enterprise leader's guide to building a successful multicloud strategy

Developing a multicloud strategy is a must to effectively manage multiple cloud providers. We have four corporate best practices to get you started.

Cloud computing: What does a cloud-first strategy look like?

Special Feature

Special Report: Managing the Multicloud (free PDF)

This ebook, based on the latest ZDNet / TechRepublic special feature, examines how to play multiple cloud providers off each other and what vendors and tools can help you manage multiple clouds.

Read More

In July 2018, Virtustream-Forrester surveyed 727 corporate cloud decision makers, and 86 percent reported that they had a multicloud strategy. This is a good representation of what has gone on in organizations over the past six years. Companies are using a variety of public and private cloud resources and internal data centers -- and they want to incorporate all of it into a single IT architecture known as 'multicloud'.

A monolithic, multicloud architecture and strategy make sense. However, companies using more than one cloud need a strategy since:

  • Shadow IT, careless deployments, and failure to remove applications and systems from multiple clouds often creates an asset management crisis that IT is expected to manage;
  • Decisions can be made independently by IT and user departments to deploy certain applications and data on different clouds, depending upon their functions and also upon various cloud price points and services;
  • Which results in a plethora of IT resources that are spread between multiple clouds, which must be managed under one hood. 

A multicloud management strategy is expressly designed to unify and orchestrate all IT under a single IT architecture, no matter which clouds it resides on. This helps ensure that security and governance are consistently followed everywhere, and that data is properly stored, processed, and accessed.

An effective multicloud strategy also guarantees that all IT assets, whether in-house or in the cloud, are accounted for. It also is a means of optimizing what organizations spend on cloud resources. Cutting (or at least controlling) cloud costs is a major concern of companies, and so is avoiding cloud waste and investing in monolithic clouds that threaten vendor lock-in.

If a company uses multiple clouds, it makes sense to develop a multicloud strategy to effectively manage the IT that is distributed in the clouds. How can companies develop and deploy multicloud strategy? Below are some corporate best practices for multicloud strategies.

1. Build a rolling three-year operationalized strategic plan 

Most organizations have a strategic IT plan, but how many of those are well executed? 

Strategic plans have earned a reputation of being 'high level' and poorly communicated to the line managers and staff who are supposed to execute it. This risk of non-performance increases when you deal with a strategic plan for infrastructure, which is what multicloud strategic planning is. Why? Because infrastructure is an 'invisible' and intangible project to the average person when compared to the most visible IT projects, which a company strives for -- like a new ERP system, or a significant investment into factory automation. 

To break this cycle, CIOs and IT leaders must continuously communicate and educate the board, the C-level, and the staff. on the importance of projects and achievements of an infrastructure plan. 

A three-year time span is the most comfortable strategic span for an IT strategy since technology changes so rapidly. Minimally, this strategic plan should be reevaluated, budgeted for, and communicated annually so it remains relevant and prioritized in everyone's eyes and continues to move forward.

2. Re-evaluate vendor and contract management annually

Multicloud IT architectures involves contracts with outside IT vendors. These contracts are for services and performance SLAs, and they cost money. At a minimum, IT should meet annually with cloud vendors to assess vendor contract performance and costs, and to negotiate adjustments, if needed. 

The only way an annual contract review process with cloud vendors happens is if IT (before entering into a cloud vendor contract) negotiates in writing as a part of the contract a provision that annual reviews and performance assessments will occur.

This makes it incumbent on IT to have skilled contract negotiators engaged in contract formation and management. Many IT departments lack this expertise internally, so it may be necessary to engage legal council or other corporate functions such as a regulatory and compliance group to help. 

In other cases, IT might have staff members who demonstrate or have skills in contract negotiation and management  who can be developed to take on these tasks. Whatever route IT decides to take, contract negotiation and management are vital components of any multicloud strategy.

3. Manage ROI 

Getting a total handle on cloud costs and resource optimization is an important financial element of managing multicloud environments.

If you plan to use multicloud solutions to offset internal data center costs like hardware and facilities, also consider what additional costs for network security, bandwidth, etcetera, will be incurred in the cloud environment? 

You won't have the same visibility of 'true' costs with a cloud provider as you have in your own data center. This is a major reason why many companies are unpleasantly surprised when they see their bills from cloud vendors. Instead, run a complete toe-to-toe ROI, which compares using the cloud vs using your own data center resources. The ROI should reveal the benefits and costs for both options, so that you can make a deployment decision.

Second, you need to identify any 'wasted' IT assets that are on the cloud and are being paid for. You can do this by installing an IT asset management system to automatically identify any IT assets that IT or users installed on the cloud -- and whether these assets are being actively used. In this way, you can identify which assets you're paying for but not using and eliminate it.

4. Ensure 24/7 uptime and business continuation

When you consign some of your IT to a cloud vendor, you depend on that vendor to keep your systems up and running. If you engage a cloud vendor that has its own data center, there are undoubtedly SLAs that address system performance and uptime. 

However, it should be noted that a surprising number of cloud vendors promise their 'best effort' if systems are down, but they will also exonerate themselves from any liability for down systems in the fine print of their contracts. This is an area that should be thoroughly discussed and agreed to during any contract negotiation.

Also, if you use cloud SaaS vendors that don't own their own data centers, you have no direct contract privity with the data center provider if a mission-critical system goes offline. Instead, you must expect your SaaS vendor, who has a contract with the cloud data center provider, to ensure systems stay up and running. In these cases, your contract with the cloud SaaS vendor should address accountabilities and SLAs when systems and data fail -- no matter who hosts these assets.

Finally, if your company is multicloud, you should arrange for an alternate cloud vendor in another geographic area to serve as a backup site in the case of a regional disaster.

5. Remain agile

Whether it is disaster recovery or disappointment with a cloud vendor, it's always wise to avoid vendor lock-in and remain agile with your multicloud strategy. Your strategy should include negotiating an exit clause (as well as an on-boarding clause) in any contract with a new cloud vendor. This enables you to easily cancel a contract if the vendor doesn't perform to expectation.

Second, it's important to have redundancy and backups in place that use multiple clouds so you can failover to another cloud provider if there is a failure at your primary provider. 

Finally, avoid placing your IT in a vulnerable position where the cloud vendor runs a system or application, and your staff knows little about it. If you ever need to in-source a system, you must have an onboard staff who can support and manage it.

Also see