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 five corporate best practices to get you started.
Written by Mary Shacklett, Contributor

In Flexera's 2020 State of the Cloud survey, 93% of enterprises had a multi-cloud strategy, and 87% had a hybrid cloud strategy. On average, respondents used 2.2 public and 2.2 private cloud vendors.

Multicloud IT architectures make sense, but with them come an added layer of complexity when it comes to managing multiple clouds.

These complexities emerge when: 

  • Shadow IT, careless deployments, and failure to remove applications and systems from multiple clouds creates an asset management crisis that IT is expected to manage;
  • When decisions occur that are made independently by IT and user departments to deploy certain applications and data on different clouds; and
  • When different applications and services that reside on a variety of clouds must integrate and/or interact with each other.

At the same time that these various clouds must interact, IT is expected to manage them all, which is no small task.

To address these concerns, a multicloud management strategy, which is expressly designed to unify and orchestrate all IT under a single IT architecture, no matter which clouds that strategy operates on, is needed. This helps to 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. When these assets are tracked, it becomes easier to monitor the expenses that are incurred on them. This enables organizations to do better monitoring and optimizing exactly what they are spending on cloud resources. If there is cloud resource waste, organization can address it. Since cutting (or at least controlling) cloud costs is a major concern for companies, as is avoiding cloud waste and or the risk of investing in monolithic clouds that threaten vendor lock-in, companies should focus on these fundamentals of asset management.

Effective infrastructure tooling and staff must also be deployed so that multiple clouds that interact with each other can be effectively managed on a day-to-day basis.

How can companies develop and deploy a multicloud strategy? Here are five corporate best practices.

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 them. This risk of non-performance increases when you deal with a strategic plan for infrastructure, which is what multicloud strategic planning basically 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 re-evaluated, 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. 

It is equally important to understand upfront what each cloud vendor's flexibility is when it comes to sharing and/or transferring information to and from clouds from other vendors -- and a vendor's commitment to assisting you migrate data or applications to another cloud if you choose to move to an alternate vendor (some vendors tend to not be very cooperative).

Note: 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 an informed deployment decision. Any 'wasted'  IT assets that are still on the cloud and continue to be paid for should be eliminated.

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 that 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.

Editorial standards