Developing the infrastructure within your organisation to transition from on-premise servers to cloud-based hosted systems comes with significant advantages. However, when you’re procuring potentially complex cloud solutions, particularly Infrastructure as a Service (IaaS), there are also a multitude of challenges you’ll need to avoid or overcome, as when undertaking cloud procurement projects it is notoriously difficult to ensure that your supplier delivers the outcomes you are expecting to achieve on a project like this.
Therefore, this article on cloud procurement looks to help critical friend check your thinking when contracting for cloud computing without all the stormy weather you might otherwise get caught in.
Advantages of Cloud Computing
With some of the more complex IaaS projects, if the risks are high, what would motivate an organisation to go through the upheaval of moving to a cloud-based infrastructure?
The answer to this can be summarised as follows:
- Cost savings. In-house servers are costly to buy, maintain, fix and run. Doing away with them and moving all of your applications (and the management of them) into the cloud, can save a significant sum.
- Scalability. This includes scaling up and down. On-premise server assets are inflexible – buying them is costly, selling them is difficult – sometimes you even have to pay to have them taken away and recycled. The result is a significant time-lag to adaptability, whereas cloud-based infrastructure can usually be scaled up and down as and when needed.
- User-centric. As the way we work changes and staff are given greater flexibility to work from home and other locations, what was once useful for sales and business people on the go is now vital for vast swathes of the working population: the ability to work from anywhere there is an internet connection and cloud computing offers this.
- Disaster recovery. Storing your data in the cloud allows for a more rapid and reliable disaster recovery process, should it ever be needed. Assuring you of greater confidence in your business continuity, subject to assurance that the relevant security and data protection mechanisms are being correctly maintained by the cloud services provider.
How Might Cloud Procurement All Go Wrong?
The fundamental difficulty on IaaS projects is the potential for a misalignment of objectives between client and supplier.
A supplier may be able to deliver exactly what was asked of them, on time and on budget, but still fail to achieve the outcomes the buying organisation was hoping for. This is usually for two reasons. Firstly, because those outcomes were not expressed with enough clarity by the client and understood with enough urgency by the supplier and secondly, the supplier did not discharge its ‘Expert Responsibilities’ and its ‘Duty to Warn’ when clarifying those requirements and outcomes with the client. In other words, the supplier failed to ask the client the ‘right questions’ to gain a better understanding of what the client was really aiming to achieve.
If delivery of the services has gone astray, you need to understand not just what has gone wrong, but why it has gone wrong. You need to understand where the liability lies?
To put this into context, if you are buying services direct it would normally be you who is responsible for the fitness of purpose of that purchase. However, if you have a systems integrator or solutions provider that has proposed a series of solutions to you, of which cloud services make up part of their offering, then it would be usual for them to be responsible for fitness of purpose, as they will have provided you with ‘solutions advice’ in their role as an ‘Expert’ in their field. This, though, does assume that you have not degraded this liability in some way through your own actions.
Cloud Procurement and Contracting: 6 Steps
The following six steps will look into the primary challenges that exist and how the interests of both parties can be aligned to deliver on the ultimate promise of successfully deployed cloud computing.
Step 1: Your Invitation to Tender (ITT)
Most organisations include ‘as is’ and ‘to be’ requirements, functions and metrics within their ITT, but many will go on to completely miss out the most vital information — your desired business outcomes. In other words, imagine the solution(s) has been implemented on an end-to-end basis and the solution(s) is operating successfully on a BAU basis: what business outcomes can you now achieve which you could not achieve before? What hurdles have you overcome and what business objectives are you now achieving? These need to be as fully quantified as possible so the supplier can really get under the skin of what advice and services to be delivered will be of most value to you.
The omission of business outcomes at this early stage can all but doom the project before it has even begun, because if the supplier does not intimately understand your desired outcomes, how could they possibly ask you the ‘right’ due diligence questions and provide you with the ‘right’ advice in order to design and deliver a satisfactory end solution? Moreover, their ability to put together an appropriate tender response without this vital information will be severely hampered as a result.
So, if you are buying individual cloud services direct, as opposed to buying them as part of one overall solution from a systems integrator or solutions provider, and the cloud provider does not have all of the necessary information they need at the tender stage, the financial and technical fitness for purpose risks of the project will lay squarely on your shoulders.
Positive Resolution: You must include your outputs, the desired business outcomes you require, and the business case metrics in your ITT.
Step 2: Selecting a Provider
If tender responses are not drafted with all the relevant information to hand, every stage thereafter results in an exponential increase in the risk of failure.
Without clearly set out objectives and reasoning within your ITT, bidding suppliers are likely to present you with tenders full of guesswork and incorrect assumptions. As such, you are likely to bear the risk of all the vendor’s assumptions and caveats.
However, even if you do provide clear and quantifiable business outcomes in step one, this second step still offers potential tripping points. All too often providers are selected on price alone, when that should be just one among many factors up for consideration. After all — just because a provider claims that they can deliver on your expectations does not mean that they can. Furthermore, the issue is not typically with the price, but rather what is excluded within it.
Positive Resolution: Require all tenderers to confirm that they can support your outcomes and business case and make it a condition of contract. Perform robust due diligence on the terms of the contract and the supplier’s ability to deliver the data centre, architecture and your desired outcomes — including how the outcomes will be achieved.
Step 3: Contract Execution
All too often a buying organisation will sign a supplier’s standard terms contract, not recognising the importance of specificity in an agreement as a one-size-fits-all contract comes with severe limitations. The warranties and obligations contained within such a contract are likely to be very light, and it is comparatively simple for the provider to discharge its obligations, whether or not this results in you achieving your desired outcomes.
And let’s not forget the inherent risk in signing standard provider terms. You may well be entering into an extremely messy legal environment based upon ‘agreements to agree’, which are not contractually operative and so cannot be relied upon if they are not delivered against. Again, you are faced with a great number of unknowns and are likely to shoulder much of the risk for service delivery.
Positive Resolution: For more complex cloud-based solutions, negotiate fit-for-purpose contract terms with more than one supplier to allow you to compare risk positions as part of the selection process. Put a residual process in place to ensure the contract is fully formed and contains no caveats, assumptions or agreements to agree.
Contract with providers to undertake a pre-contractual scoping of your requirements, outcomes, internal skill sets and resource availability, and to evaluate issues with moving the applications from legacy physical servers to a virtualised environment. Contract for this as advice in the first instance.
Agree terms of reference that will ensure that you understand the true risk position and have effective plans for mitigation. Ensure that an overall transition plan is created and agreed, which will take the project through to business as usual on the new architecture. Ensure that the outputs include a commercial model with effective what-if scenarios, so these are fully considered and understood by both parties before committing.
Finally, select a preferred partner who has evidenced that it can deliver to your desired outcomes, to agreed costs and timescales, and is prepared to underwrite this contractually.
Step 4: Provision of Infrastructure
At this stage, the provider often will configure the infrastructure and set it up in their data centre. The infrastructure is based upon indicative information on the assumption that it can be scaled up and down as demand necessitates. Furthermore, the managed infrastructure service is for kit and function, up to the operating system level only.
In line with the common theme established, unless you have implemented the “positive resolution” portions of the steps before this one, you are likely to have taken on key aspects of the financial and technical risk should the infrastructure have been mis-specified. Assuming that the provider’s obligation is to monitor up to the operating system layer, check whether this excludes the virtualisation software layer. If it does, the buyer takes the risk that the solution is fit to run all its business application software and that all the software will migrate successfully to the new virtualised environment.
Positive Resolution: Ensure the provider builds and provides the infrastructure in the context of what you actually need – you need to have requested an end result that meets your desired outcomes, not a blank canvas framework.
Step 5: Testing
As one would expect by this point, the testing process carried out by the provider is of little use to the buyer in ensuring that the infrastructure is fit-for-purpose. The provider will test the infrastructure with a series of ‘green light’ tests to verify that the hardware and network are performing as they should, but this is a long way from the system being fit for purpose (as a buyer would define it).
Additionally, once you accept the system (as you would be contractually obliged to do), your express contractual rights for non or partial delivery often degrade significantly. And perhaps most damagingly, you will at this point be paying for infrastructure that is not yet fit-for-purpose (nor do you know if it ever will be).
Positive Resolution: At this stage you should be carrying out the testing that truly matters – i.e. migrating and proving the business applications on the new infrastructure. You should be training your staff to use the new system and completing a clean transition from old to new.
Step 6: Closure
At this point, the provider may well have discharged all of its obligations under the terms of your initially ineffective contract.
It is now your responsibility to migrate your existing system over to the new architecture, which is in itself a major undertaking.
It is important to set up a new project to migrate to the new architecture, and understand that you will be wholly responsible for its success or failure. You, therefore, retain overall responsibility for achieving the desired outcomes.
Positive Resolution: On the other hand, if you have contracted well, you should now be able to realise the benefits of the new system, achieve your desired outcomes and ensure that your business case is intact. This is what should represent project closure, and the provider should now of course be appropriately compensated.
How to Successfully Contract for Cloud Services
If you are experienced in strategic commissioning you may make the reasonable assumption that cloud computing cannot be much of a different beast. However, we have found that nothing could be further from the truth. Step by step the process of procuring a new technological structure solution for your organisation needs to be handled with care as even a small deviation from the right path could have far-reaching ramifications.
If you are in the public sector there is one more factor to consider, that of the European Commission (EC) guidelines, designed over the last decade to set common standards for cloud computing supplier SLAs across objectives such as the supplier’s performance capacity, the security of data in the cloud and data management against EU data laws. Note that within these standards, some are voluntary, there are geographical limitations, and some ambiguity remains within the guidelines.
This article has taken an overview of a few of the most common challenges, but for a more in depth analysis on how to successfully buy and contract for cloud services, you can download our free white paper on the subject here.