Buying (and Selling) Cloud Is Not (Yet) a Transactional Activity

Introduction

I will talk about “all” the things you won’t get from a cloud provider. This is not to make the cloud look bad. To the contrary, I am strongly convinced that every company benefits from using cloud services.
Instead, I want to highlight non-technical aspects in your procurement, contracting, provider management and decision making functions. If your company understands the differences between traditional outsourcing and cloud outsourcing, as well as why cloud credits are not (yet) understood in the same detail as software licenses, you remove friction in deciding for and contracting a cloud provider. More importantly you allow for quicker ramp on the cloud due to improved expectation management and encourage openness to “try and do it differently than today”.

Traditional Outsourcing vs. Cloud Outsourcing

Past:
In the past companies bundled parts of their IT and issued a tender for outsourcing. Typical bundles comprised e.g. data center facilities and operations, workplace or network operations. Essentially you handed over a piece of assets and employees working on them to a 3rd party. Of course such agreements included lofty goals like “innovation” or at least renewal, but at the end of the day, you handed over a very well understood piece of work. I’m not saying, it was also well documented…

In addition the process of traditional outsourcing, as well as “managing” the 3rd party is well understood. Not only have companies done it more than once, but can also rely on a plethora of experienced consultants and skilled workers understanding how it’s done.

Today:
A typical cloud contract is different to an outsourcing one. Essential concepts like the “shared responsibility model” and “self service for everything” need to be explained to and accepted by business, technical as well as buying and provider management functions.

Shared responsibility means that the cloud provider is not taking care of everything, but only for running and maintaining the platform. For example neither “installing a customer’s application” on the Cloud, nor operating it on the cloud is done by the provider. Basically every configurational activity or data manipulation is only executed on request by the outsourcing party (hopefully by an automated process) or it’s partners.

If the API doesn’t provide what you want, you most likely will not get it.

Self service means, if you want to make a change in your cloud environment or request a report, you use an API (or a graphical interface abstracting from it). If the API doesn’t provide what you want, you most likely will not get it. Unless the cloud provider builds it, based on your feature request. The appealing pricing structure and flexibility of cloud platforms is based on relentless standardization and automation. Serving one-time efforts or snowflake asks are usually not fulfilled by cloud providers.
For example you won’t get a monthly SLA overview tailored to your specific needs. Instead monitoring uptime and requesting a redemption in case of outages are self services triggered by customers. Still cloud providers share a general status overview, not specific to a single customer. Features you need to build such a report are baked into their platform.

Because of previous (people) outsourcing activities, the technical capabilities to understand and assess the impact and opportunities of the cloud can be limited.

Until today the described differences are not understood in its entirety by all buying companies. The consulting market on cloud advisory is growing, but from a low starting point. And because of previous (people) outsourcing activities, the technical capabilities to understand and assess the impact and opportunities of the cloud can be limited. The lack of documentation hasn’t changed (despite all the outsourcing), which is an additional challenge when “creating the business case”. Which is no longer a calculation based on labour arbitrage, but on speed, ease of getting access to latest technology, reliability and scalability.

Of course reality is not exactly black or white as pictured above. I just want to highlight why a fundamental difference in approaching the cloud requires new ways of thinking, not only from a technical perspective. And help you to avoid building “just another data center” in the cloud.

Licenses vs. Cloud Credits

Past:
Buying (and selling) software licenses is a very well understood transaction, practiced and refined during the last 40+ years. If a company needed to upgrade their 100 Oracle databases, they bought 100 new licenses, got a significant discount (and might have been confused about CPU cores, sockets, VMs and what it actually meant for their license coverage :D).

More importantly the buying and contracting functions as well as the IT department or it’s partners know how to install or upgrade the software and can mitigate dependencies arising in their on-prem or managed hosting environments.

Today:
Consuming cloud services is different. In fact cloud consumers only pay what they use. No need for upfront commitments or multi-year contracts. As most of the enterprises want some kind of predictability and of course a little discount, cloud providers introduced the concept of cloud credits, which — in a nutshell — are a virtual currency, paid upfront and intended to be “consumed” by using the provider’s cloud services over a given period of time. Some cloud providers also offer multi-year commitments for e.g. a number of servers to address the customers’ need of predictability over flexibility.

Most buyers of such cloud credits don’t know how to spend it though. Wait, that’s easy to fix, isn’t it? Just consume the cloud, right? Well, for consuming the cloud, enterprises new to the cloud have a couple of prerequisites.

The organization needs to be ready to run workloads in the cloud from a security, compliance and connectivity perspective, but also from a mindset one. Giving up some of the control one had in the past is a hard change. In addition, architects, developers and operations staff need to learn using the cloud and the new concepts coming along with it (e.g. everything is an API, delete and redeploy vs. patch, firewall rules). So ultimately these companies have an additional training and management of change effort.

Once the above prerequisites are solved, you can start to really use the cloud with all it’s benefits. And as most of the cloud deployment activities will not be greenfield (i.e. applications developed from scratch, being cloud native), there is migration effort involved. It requires time, effort and ultimately a little risk taking from the business when migrating to the cloud.

Now what?

The key point here is that all of the above has been solved for many companies and can be solved for those tackling the cloud now. The cloud providers and their partners are prepared and will gladly assist customers in this journey. In addition, I strongly recommend reaching out to your competitors or players in related industries. They might be open to exchange learnings from their cloud transition with you. I’ve personally seen great results from such dialogues.

A significant part of your transformation cost is not going to the cloud provider, but is spent on training your people and on migration efforts.

“Going to the cloud” is much more than just buying the cloud credits or signing a contract. It is a fundamental transformation for all of the enterprise, not only for IT. This needs to be considered when planning, staffing and budgeting for a cloud adoption journey. A significant part of your transformation cost is not going to the cloud provider, but is spent on training your people and on migration efforts.

Enable non-technical functions before starting the cloud selection process.
If your procurement, contracting, provider management and decision making functions have no experience with cloud (providers) so far, enable them to learn about it. Focus on what is different to your established processes and thinking. You might have individuals on those functions, who are already very informed and interested in cloud adoption. Identify and encourage them to disseminate their knowledge and let them participate in your upcoming cloud endeavour.

Be sensitive to finger pointing and foster exchange on eye-level.
If you are in the early stages of a transition to the cloud, carefully listen to messages like “The cloud provider doesn’t want to integrate into our IT Service Management.”, “They are not able to provide SLA reports.” or “They are not able to implement our security standards.”. Such statements are strongs indicators of limited understanding of “how cloud works”. They might also be an indicator of the cloud provider’s personnel not having explained those differences to yours. Therefore make both parties responsible for establishing a common understanding, without falling into the buyer vs. supplier trap.

Further Reading by Mathias Wagner

• Expand your Cloud Center of Excellence to the whole organization and become a cloud-first business
• Customer expectations and best practices when answering an RfP

Mathias Wagner is a Technical Account Manager at Google Cloud. There he accelerates enterprise customers’ journeys to the Cloud. www.linkedin.com/in/mathias-wagner

This post reflects personal observations and opinions of the author and does not necessarily reflect those of his employer.