How to onboard a cloud solution provider – part one

Starting is so easy. All you need is a credit card and you can order and use cloud services, put data into the cloud and be digital. In the next step, you need to sign the standard contract of the cloud service provider and you are good to go.

Stop! This is an enterprise nightmare and if this has been your plan so far, it is time for some emergency braking.

While in a start-up environment this may work for a limited amount of time, it is not working for larger enterprises and especially not in a regulated environment. The reasons for that are manifold.

• Cost transparency / Cost control
• Data privacy
• Governance setup
• Technical and architectural consistency
• Economies of scale

So, how would onboarding a cloud service provider for enterprise-wide use look like? We must consider two dimensions – contractual and technical. These dimensions of onboarding include more than what the name indicates. Contractual is more than just a cloud computing contract and technical includes operational processes in the same way it includes networks.

Contractual dimension

There is a huge difference in onboarding cloud service providers and using a classic sourcing scenario. In a sourcing scenario, the customer sets the rules and the contract is on the customer’s paper — defined by the customer. In cloud, the approach is different. As public cloud providers provide a standard service and not a tailored one as in sourcing, they use or aim to use a standard contract of their own. And the challenge is that they are standing firm. It is their way or the highway.

Now, everybody is important and believes his company is an important customer, and so the cloud provider would bend the rules for them. Let’s face the truth, only very few companies combine a brand recognition with a size that will make even the cloud providers customize their offering. Having been inside the machine, I can tell you that the room to wiggle is small. Nevertheless, you should use that room to make the service fit best to your needs.

The first thing you will encounter will be a discussion about volumes and predictions, I would have said capacity considerations. This being a commercial discussion, can be put aside for this onboarding scope. There are plenty of articles available on pricing strategies and negotiation tactics for public cloud providers. So, despite keeping commercial aside, you still need to solve financial part of the problem. When and how to pay, based on which numbers and how to check and control these. This is a core element as the provider bill will balloon up quite quickly, replacing classic cost. Getting the administrative processes in place around ordering, using and paying is important. Part of this discussion will also be the internal way of ordering. You need to get the services included into the right internal order channels, whether that is a classic service catalogue, a cloud solution like ServiceNow or an embedded approach through a PaaS framework. This needs to be sorted along with internal charging.

You might argue that this is not a part of the contract, and you are right. It is, though, part of the onboarding.

The next stumbling blocks are reporting and cloud security controls. Again, we do see a reversal of roles compared to classic outsourcing. While in outsourcing the customer defines his “wishes” and the provider tries to comply, in this case, the starting point is a standard.

In reporting the cloud providers take a simple position. There is a dashboard/API and you can pull the information you need. No more push of tailored reports. The important part in onboarding is to check the available information and whether there are any gaps you need to raise as part of the contract negotiation. Then you need to identify ways to compile the information from these dashboards into the reports needed and hopefully this will be an automated process. And finally, you need to define an owner that checks the reports, has access to the dashboard and can put facts to numbers by being the intermediate role between business, IT and the cloud service provider.

In addition, you also need to be careful, what you ask for. Lately, I saw an RfP document that said

1. It is mandatory for the provider to use the customer’s ServiceNow for incident, problem, change, etc.
2. The provider needs to provide reports about incident response times, etc.

It is obvious why this does not make sense. It either leads to double accounting for the provider to be able to fulfil the request or change contractual agreement along the following lines:

1. It is mandatory to use our ServiceNow for incident, problem, change, etc.
2. The results/statistics from the customer ServiceNow are the single truth and the foundation for all SLA, volume, etc. statements
3. The customer will ensure access to the platform and the relevant data

The pull to push change also happens in the security control discussion. Especially regulated enterprises have their security controls defined and provide these to a service provider to match them. In the (public) cloud scenario though the roles are reversed. The cloud provider provides his standard set of policies and tasks to the customer to check for the grade of compliance. They per se do not adjust their framework to a single customer. So, if you ask for a security control to be changed, you’d better have a story on how this applies to the whole industry in that region/country/vertical. The willingness to accommodate regulated customers is different by provider. You should make the possibility to make your level of security a key element in the decision for a provider.

We will explore the technical dimensions in part 2 and 3 of this blog post series.

Part 1: How to onboard a cloud solution provider

Part 2: The foundations of hooking up to a cloud provider

Part 3: Making Cloud Onboarding hassle-free and valuable

Part 4: Tips for Seamless Cloud Onboarding