CUTTER IT JOURNAL VOL. 28, NO. 10
  

As the cloud market has grown up, CIOs are now in a position to rely on a modern, robust ecosystem of cloud computing vendors to deliver efficiencies and cost savings at scale. To do this, however, the role of the CIO demands an understanding of how to build and subsequently manage that supply chain when deciding to procure infrastructure as a service. This article discusses how the CIO, ahead of launching an RFP, should prepare for the challenge of coordinating multiple, competing IaaS service offerings to establish the type of mature supply chain more commonly found in established utilities markets.

THE SHOPPING LIST IS DEAD; LONG LIVE THE SHOPPING LIST

Over the last decade, many enterprise IT departments resisted calls to fully outsource their function to large systems integrators. Enterprise IT is now being coaxed into considering a less extreme form of IT outsourcing — either a full migration of certain applications to the public cloud, or a gradual transition via a hybrid cloud model.

Within the next 10 years, enterprise IT will adopt a utility consumption model in order to retain inhouse control without the financial and support burden of inhouse delivery. They will take a multi-vendor approach to avoid vendor lock-in and maintain efficient pricing. This all means that enterprise IT procurement will require a radically different approach to selecting the best vendors. RFP tendering approaches designed for highly specific physical hardware are just not suitable for the procurement of intangible, perishable, shared utility services.

CIOs must assess their organization's readiness to adopt such a multi-vendor cloud procurement approach. Creating a robust supply chain for on-demand IT services will not be as straightforward as simply using services made readily available in established utility markets, like power. Regulators are just starting to wield their influence to encourage major cloud providers to cooperate in offering a resilient utility service of the quality offered by established utilities such as electricity and natural gas.

AVOID LOCK-IN BY MAKING ONE CHANGE TO YOUR PROCUREMENT PROCESS

Most workloads can be run in the cloud, and the capabilities of IaaS providers have evolved to a point where CIOs are forced to make a choice: invest in their own aging data centers or invest in building a modern ecosystem of suppliers to deliver the same capabilities. Some clouds offer a vertically integrated and deep set of products, but the savvy CIO is wary of vendor lock-in. This is precisely why CIOs who lead the organizational change to adopt cloud computing must understand supply chain management.

The two most common approaches -- choosing everything from a single vendor or simply chasing the lowest price -- do not fully price in risk or optimize for it. Let us take the classic example of availability. Is it better to rely on a single provider, Alpha, that provides 99.99% uptime (which amounts to 52 minutes of downtime a year and is expensive to achieve), or to seamlessly switch between two providers, Beta and Gamma, that each provide 99% uptime (which amounts to 87 hours of downtime a year and is considerably cheaper to achieve)?

TWO VENDORS, TWO THROATS, TWO HANDS

When a CIO takes the view that having a single supplier is easier because there is only "one throat to choke," they should question who is choking whom. Using multiple cloud service providers increases the flexibility and resilience of your supply chain as a whole. That one cloud provider that promised you the moon is unlikely to deliver top marks in all performance categories, including availability, because if your organization has already contractually committed to five years of usage in order to "unlock" discounts in price, there is no real incentive to go beyond minimum service levels. After the CIO's procurement team has short-listed prospective suppliers based on technical ability, the procurement focus should turn to the costs and practicalities of combining multiple suppliers that together can deliver a high-quality service at a reasonable price point.

Adopting a multi-vendor approach also mitigates risks relating to capacity shortages, single supplier risk, and issues over quality or poor vendor performance. By defining which workloads are most readily portable, an organization is better placed to avoid lock-in wherever possible. Ahead of issuing an RFP, a CIO might also consider benchmarking suppliers based on their specialism(s) in order to identify areas of collaboration between suppliers and assess pricing according to their combined merit.

COMBINING SUPPLIERS OFFERS LOWER RISK, LOWER COST, AND BETTER SPECIALIZATION

Coming back to our example of availability, it is more cost-effective, for exactly the same risk of system outage, to rely on the combination of Beta and Gamma. If we can assume their outages will be independent events, we would multiply 1% by 1% to get the same 0.01% system outage risk as for Alpha -- the single, more expensive supplier. The key question is whether the much cheaper capacity bookings at both Beta and Gamma are still less expensive than Alpha's premium service offering once you add in the cost of building the capability to switch seamlessly between them.

Cloud supplier pricing is incredibly complex and packaged as incredibly simple. It is often the case with the unsuspecting cloud buyer that the suppliers with the simplest pricing are also the most expensive. But that's changing as cloud buyers who don't have the internal skills to create an effective benchmark for vendor pricing comparison turn to brokers who do. IaaS isn't a commodity, but it should be priced like one in order to make evaluating proposals fairer and more transparent.

HAVE YOUR CLOUD AND EAT IT, TOO

The most common problem we see in RFPs for cloud services is the reuse of tendering materials that were designed for the outright purchase of physical objects. Problems that arise include buyers being unnecessarily specific in the definition of their requirements, buyers trying to impose what they would do in their small data center to an exascale cloud provider servicing thousands of diverse clients, and many others. The best way to spot these problematic approaches is by way of analogy.

Choose from a Defined Menu

Imagine you have to feed a family of fussy eaters. You start off by letting each person choose exactly what they want to eat, and naturally everybody chooses something different. Nightmare!

It quickly becomes unfeasible to meet the exact requirements of each family member, so you have to compromise. As a family, the way you save money on your food costs is to make sure the component ingredients and a limited set of tools necessary to prepare and serve them are the same across all meals. You tend not to have different perishable ingredients for every meal, and you don't invest in a brand-new pan every time you want to boil an egg.

The secret to feeding your family on a budget is then the same for delivering IT services in the enterprise … try to get everyone to choose from a carefully selected menu!

It Is Cheaper Because You Are Sharing

There is a fundamental difference between procuring the ingredients and capabilities to deliver a service that is solely for your own use versus procuring an on-demand shared utility service such as restaurant food or cloud services.

The attraction of accessing "the cloud" is the ability to leverage the benefits of sharing, whether that be between different types of users within a single organization (private cloud), or between different organizations (community and public cloud). However, these benefits come at a cost relating to the buyer's ability to define the exact specification of what is bought, and the terms on which that purchase is made.

If an organization fails to recognize this, and issues an RFP that demands a service or a contract that is too far from the market norm, then the benefits of sharing are degraded, driving up the cost to deliver.

Should You Try That New Restaurant?

To extend the restaurant analogy, would you commit your family to eating at a single restaurant for a year without trying it out? Probably not.

It makes sense to encourage representatives of each cloud usage case to try out a few different services ahead of the procurement and solicit their feedback. It is also important to assign a trial budget in order to sample the actual menu, not just the free appetizers, in order to understand the pricing and payment experience, which can vary dramatically between clouds.

As with restaurants, it can be unclear what level of support or service you can expect to be included in the price, and whether they will accept your preferred payment method. Ask your would-be cloud consumers, and their related stakeholders in legal, finance, and other departments, to take a taste test with prospective suppliers before you issue the RFP.

Should You Ask About the Specials?

It is one thing to look at the menu, but there are always questions for the waiter, and if you happen to be allergic to nuts, you're better off focusing your questions on how the meal is prepared than worrying about whether service charges are included.

Restaurant meals are not a truly fungible commodity, which is why we rely on the likes of Zagat and Michelin to help us compare quality. Cloud is also not a true commodity, and so similar brokerage models exist and are useful.

Keeping Your Options Open

Does the prospect of listening to your family complain about going to the same restaurant every day for a year not appeal to you? Are you worried that even if you went to that single restaurant that had everything you wanted on the menu, the quality might degrade over time? What if the restaurant opposite, the one with three Michelin stars, drops its prices to be cheaper than your restaurant?

The same applies to choosing a single cloud provider. No single cloud vendor is good at everything, despite what a vendor may claim; and what may seem great now may only be the flavor of the month. Why would you commit to using the same provider for a year?

IMPLEMENTING THE MULTI-SUPPLIER APPROACH TO CLOUD

By this point we hope we have persuaded you that taking advantage of multiple, competing service offerings is the most cost-effective way to procure IaaS. So how should you go about it?

Who Should Lead This Research?

Who better to lead the assessment of prospective suppliers and go on to manage vendor performance than the people who run your own data center? When someone from your own data center operations team joins you on a visit to assess a supplier, they're the ones likely to ask all the penetrating questions about redundancy, security, cooling, and disaster recovery. The logical progression for technical and operational roles is to transition to vendor performance management roles because the same subject matter experts who write your RFP are also the ones most qualified to assess their counterparts on the supplier side. Price is irrelevant if the service simply doesn't work for you. However, the CIO must also deploy a new set of financial and risk analysis skills in the RFP process in order to complement the technical side.

Should You Go for the Discounts?

In cloud provisioning, a one-year deal often represents a 50% discount on hourly or monthly contract rates. A three-year deal can be 70% cheaper. The discount is to entice more customers to commit to future spending so that the cloud provider can de-risk their up-front CAPEX investment.

Deciding whether to lock in heavily discounted future prices versus keeping your switching options open requires access to the cloud pricing history and the analytical skills to know what to do with it. This is the role of a financial broker (full disclosure: this is the authors' specialty). The more switching options you can show your financial broker, the better the deal you will secure.

The Role of Financial and Technical Brokers

Using a technical broker or a cloud marketplace is one great way to access those switching options. Think of it like choosing to frequent a food court every day instead of sticking to a particular restaurant. You're committing to paying the parking charges to use the marketplace, but that should be cheap considering the savings you'll reap from having multiple vendors fiercely competing for your business.

One downside to the cloud marketplace approach is that you get multiple receipts for your aggregated consumption, which can be a real burden for whoever controls the budget. Cloud services are priced and invoiced in a way that makes fair comparison of value for money a real challenge. When pricing is oversimplified, it is often true that pricing is more expensive than necessary. If not, the vendor is unlikely to remain the cheapest for long due to pricing inefficiencies. Look for services that provide unified billing, either as part of the marketplace offering, or as a standalone service -- your finance team will thank you! Basically, it's the financial broker's job to save the buyer money and support the RFP process to ensure the buyer has enough choice.

A More Pragmatic Approach to RFPs

Your RFP should specify your benchmark requirements, which ought to be set, if at all possible, in the middle of what the market offers. This should be defined as broadly as possible and not include any arbitrary specifications (e.g., "Do you really require champagne, sir, which can only come from the Champagne region of France, or will any form of sparkling wine suffice?"). You must understand that vendors bundle the cost of adaptation into the overall cost, which makes it hard to work out the premium added for exactly meeting your specific requirements.

This will require some research for each characteristic that you specify. Your research will quickly uncover that vendors offer services that deliver more or less than your benchmark requirements. In your RFP, you must make clear what happens when the service is above or below your benchmarks. You can avoid significant problems if you have a strong focus on vendor performance management, open communication with your supplier(s), and a willingness by both parties to engage in corrective measures outlined in a service-level agreement (SLA), such as remuneration in the form of a discount or, as preferred by vendors, a service credit. The best possible outcome is achieved through swift, open dialogue. Worst-case scenario, before a cloud buyer cancels the contract or takes legal action, arbitration has proven to be a very successful method for conflict resolution. If an SLA is clear on how conflict will be handled from the outset, and if arbitration is included as an option, a CIO may have a better way to deal with performance issues in the contract than resorting to protracted legal action and time-consuming tasks when moving to a new supplier.

Be pragmatic. Expect that what you ask for in your RFP will not exactly match what vendors are offering. If you insist that vendors meet your precise specifications, be prepared to accept a price increase.

FOUR QUESTIONS TO CONSIDER IN ORDER TO RUN A BETTER TENDER

1. How will you inform a large audience of vendors that you have a commercial requirement, and how will you handle it if vendors choose not to respond to your RFP due to a minor mismatch between their service description and what you have specified?

2. What if vendors add in the cost of unnecessary adaptations to their service, thus driving up the price? Can somebody from your data center team act as a liaison with your procurement team to decide what are acceptable limits for customization or price?

3. What if the differences don't get discussed, and vendors say that the service meets your requirements even though it doesn't? Whose responsibility is it to independently verify a vendor performance issue that is not made clear in an SLA?

4. Does your contract specify arbitration as a way of working around the differences short of terminating the contract (with all the ensuing disruption that implies)?

When you want to procure the hardware and capabilities to run your own IT infrastructure, you can specify any details you choose. This works because you are buying those ingredients and cooking utensils for life. The problem is that you cannot cook at home on the scale offered by a global restaurant chain, particularly not for short-term consumption. A very high level of specificity does not work well when you are renting something for a short period of time; the vendor will want to repurpose what it sells to you for the next customer. This limits your technical customization. The vendor also wants to minimize its cost of sale and operating costs associated with the transaction, which is smaller due to its shorter commitment period. This limits the amount of financial and contractual customization that can be done.

THE CIO IS FAST BECOMING A SUPPLY CHAIN MANAGER

A CIO must consider who will be involved in testing potential providers before sending RFPs, how the data center team's roles may change, how to appropriately benchmark and compare supplier pricing, and the extent to which customization can be minimized in order to maximize choice. Consider the input of a cloud broker when choosing to run a tender that allows multiple vendors to join a robust, modern, and resilient supply chain.