Remedy for frustrations in legacy IT infrastructure contracting model

A significant driver motivating companies to migrate workloads out of their legacy environment into the cloud is the increasing frustration of operating under onerous, complicated services contracts. Of course, these workloads migrate to the cloud and a software-defined environment primarily for greater efficiency and agility. But many workloads are too expensive and risky to migrate and thus are better suited for maintaining in a legacy environment. So, I’m calling for a better, more rational legacy infrastructure contracting vehicle. Here’s what it would look like and how companies would benefit. 

What’s wrong with the typical contract?

Large, cumbersome, difficult master services agreements (MSAs) with functional areas or towers govern the legacy IT outsourcing market. No matter the function outsourced, these legacy contracts have in common several characteristics that make them too complex and make administering these contracts incredibly complicated and frustrating. These characteristics include:

• Complex pricing clauses
• Complex service levels
• Service levels that measure only certain components
• Reliance on the customer enterprise to fulfill certain obligations
• Inability to know what services have been consumed and can be legally billed
• Penalties or consequences for early termination or descoping services

Yes,  the above characteristics are potentially well-intentioned legal clauses and sub-clauses that govern the behavior of both parties. But some are seemingly contradictory and, together, all these characteristics make it hideously complex to administer a services contract. Let’s look closer at the impact of these characteristics. 

The pricing mechanism relies on minimum payments and tiered pricing or banding of pricing with different prices in different bands. The contracts have multiple towers (functional areas) of services with different bands applying across them. Each band includes a guarantee of volume with ARCs (Additional Resource Credits) and RRCs (Reduced Resource Credits) mechanisms to adjust for volume fluctuations.

In many services relationships, these pricing complexities trigger misaligned interests between the client and service provider. As is evident through the past two decades in services relationships, clients’ frustration grows with the misalignment and they often decide to switch to a different service provider.

Service levels add to the frustration. Yes, there are clauses governing when a service provider incurs a penalty for not meeting service levels. Contracts include very complicated mechanisms to calculate penalties or advantages from service levels, and those penalties can increase with severity. But there are pricing caveats that allow the provider to make performance right and recover the penalty, so to speak.

In addition, service level metrics apply to only certain components of the service. I blogged before about this phenomenon, which I refer to as the watermelon problem. In these all-too-common situations, the dashboard displays green metrics. But on the inside, like a watermelon, the level of satisfaction with the overall service is red. The customer deems the service poor because the business impact is low.  

Then there is the difficulty of the provider and the customer tracking whether the customer actually consumes a service and thus what can be legally charged. This causes the need for the customer to establish a large governance team. Either the customer ends up not tracking consumption (and therefor is likely overcharged) or invests in the resources for a significant governance organization that monitors usage and tries to manage the complexity.

Another frustration: these contracts rely on the customer enterprise fulfilling its obligations such as notifications for change. It’s very difficult for a customer to provide all the appropriate notifications in the right time frame to administer these complex contracts. Consequently, either they don’t get administered because of the complexity or, if they are administered, the administration takes a great deal of time and resources.

Remedy

Replacing these onerous, difficult-to-maintain MSA tower contracts with a more effective contract starts with a simpler pricing vehicle based on consumption. 

Software-as-a-Service (SaaS) apps introduced businesses to the consumption-based model, where businesses pay only for the resources they use instead of paying for over-capacity in case it might be needed in the future. However, companies usually adopt SaaS solutions as point solutions. More and more companies move workloads to the cloud to take broader advantage of consumption-based services. But as I mentioned already, migration of some workloads is risky and expensive.

So I’m calling for a much simpler contracting structure with fewer but more powerful service levels, true consumption-based pricing, collapsing the towers and doing away with the pricing bands and the caveats.

Benefits

This new contracting structure has two primary effects:

• It dramatically simplifies the consumption and management of the services
• It derisks the service consumption for the customer enterprise.

At the moment, many of these contracts have early termination penalties or consequences for either descoping them or reducing consumption. This creates frustration with the model and signals a need to try to engineer a path out of this complex model. Moving to a simple consumption-based mechanism  relieves this frustration because it eliminates artificial contract termination lengths – the short windows in time at the end of or during a contract where the customer can make changes in volume. This reduces the risk of staying in the existing model. The customer can move its workloads as they naturally move, not as the contract forces them to move.

Paradoxically, by making it easier for workloads to reside in the appropriate architecture, we see businesses reducing migration from legacy into cloud. Once the contractual frustration is removed, there is less urgency to move workloads.

Moving those workloads is expensive and risky for the enterprise. And it results in a loss of revenue for the service provider. So, a consumption-based pricing vehicle for legacy services is a real win-win.