We all know that cloud computing is becoming more and more relevant to public and private organisations. For most enterprises, the potential cost savings of moving infrastructure to the cloud are too big to ignore.
However, as a relatively new form of outsourcing, cloud computing is not without its potential pitfalls. This is especially the case when it comes to procuring Infrastructure as a Service (IaaS). Many companies have found out (often far too late) that their objectives and criteria for success are hopelessly misaligned with the provider’s.
In this article, I will reveal a common path of IaaS procurement which results in a project that is 100% successful for the service provider, but 100% unsuccessful for the buyer.
What Does the Buyer Want to Achieve?
When it comes to IaaS cloud computing, most organisations want to:
- Move their application software estate from costly in-house servers to an external data centre, with no impact on their business
- Benefit from scalable, robust architecture which can grow with their business, is always on, is accessible by mobile devices and constantly monitored by the provider.
- Benefit from multiple layers of cost savings while providing a much-improved disaster recovery and business continuity capability
These outcomes are possible (and realistic) with cloud computing but are often not achieved. For the most part, contracts are falling down at the first hurdle.
Where Does It All Go Wrong?
Let’s take a look at a hypothetical procurement process for IaaS. The following six steps are typical of many real life procurement processes, and always result in an unsatisfactory outcome for the buyer.
Step 1 – The buyer creates an Invitation to Tender (ITT)
The ITT sets out information such as the as-is and to-be metrics, along with other objectives such as the ability to scale up and down. It also includes various functional and non-functional requirements.
Step 2 – Multiple tenders are received from cloud providers,
The buyer evaluates and selects on price. Their prevailing belief is that because they are dealing with utility computing, a transition to a new provider (if things do not go to plan) shouldn’t be fraught with complications.
Step 3 – The buyer and provider sign a standard terms contract
The contract also includes the commercial model. The ITT and ITT response is excluded from the contract on the basis that it is a sales document. The definition of the managed service, details relating to reporting and monitoring, the implementation plan and pricing are all to be confirmed after the contract is formally agreed.
Step 4 – The provider purchases and sets up the infrastructure
The equipment is based upon indicative data — after all, they can scale up and down if necessary. As agreed at the contract stage, the managed service is for kit and function up to the operating system level.
Step 5 – The provider tests the infrastructure
The provider tests the infrastructure according to its own acceptance tests and approves it as “ready for service”. The buyer pays the setup fees applicable to the project.
Step 6 – Project closure
The project reaches closure from the provider’s perspective, and ongoing managed service delivery commences along with monthly charges.
The provider has completed their job (and achieved its outcomes) by providing the platform upon which software can be installed. But the buyer is left with their same old creaking system and a brand new one that is not yet fit for purpose. None of its original outcomes have been achieved.
One cannot look to the provider as the enemy in this scenario, as they have done exactly as they promised. In fact, the process may have run extremely smoothly, but that would not detract from the fact that the buyer is not left with a satisfactory outcome.
The issue ultimately revolves around the vast misalignment between intended outcomes. With that in mind, next week we will be focusing on how cloud procurement should be executed.
In the meantime, if you are interested in learning more about how to successfully contract for cloud services, you can read our free white paper.
Creative Commons image courtesy of Nicholas_T