The idea of measuring a cloud almost sounds oxymoronic, doesn’t it? Clouds are amorphous, asymmetrical, constantly moving things that come in a variety of different shapes, hues and densities. Measuring a cloud in a single dimension and then proclaiming it to be a “7” or even somewhere within a range would be misleading in the extreme, as every other dimension you could measure might give a completely different result. So it is with cloud computing services. And yet measure them we must.
The advent of cloud services signals a dramatic shift in control of how services are delivered and under what terms — and that shift favors service providers. With traditional sourcing models, a customer could define the services once in an RFP and have every bidder meet the same requirements, resulting in the service providers having to support each customer in ways unique to that customer, thus constraining their ability to benefit from standardization and economies of scale. The cloud model turns that situation on its head, offering potentially dramatic improvements in standardization and economies of scale in return for customer acceptance of a solution that is generic across all of the service provider’s customers. The degree to which that trade-off occurs depends on which delivery model is chosen, with physically private, on-premises cloud implementations being most similar to the traditional model and public cloud being the most different.
The key for any organization adopting cloud services today is to go into that trade-off with their eyes open and not simply sleepwalk their way into a new sourcing model where they give up control and customization and get very little in return.
As I write this customers are signing up for services that include the word “cloud” (potentially the technology term that has lost more of its meaning more quickly than any other in history). In many cases these services do not deliver what we may have come to expect from a cloud service. There are also customers signing up for services and giving away benefits that they had before. There’s nothing wrong with making intelligent trade-offs, and cloud provides great opportunities to do that, but obtaining very few of the benefits on the left side of the table below, while giving up too many important benefits from the right side, is not a very good deal.
|
The Cloud Services Trade-Off |
|
|
Sample Potential Gains |
Sample Potential Losses |
| Short contract duration or none at all | Customized SLAs |
| No minimum volumes | Auditability |
| Fully automated elasticity | Application portability |
| Virtually unlimited scalability | System response time |
| Short provisioning times | Security control |
| Charges only for what is being used | Predictability of the monthly invoice. |
Why is that happening? Many customers have not fully considered what they are trying to gain in a cloud services transaction, nor have they fully considered what they might be giving up or the corresponding value of either one. Even if they have considered it, they don’t know how to quantify it. Each of these service elements (and many more I didn’t even mention) must be measured, and they must be measured in a rigorous and consistent way so that they can be compared across different services from different providers (all of which may price and define the services differently). The complexity that once existed in your RFP is being replaced by complexity in your solution evaluation. Get ramped up now on how to deal with that. Otherwise the chances are that you will be confronted with some serious mistakes within a year of your first significant cloud services adoption.
