Why not pay outsourcers for business outcomes rather than IT Capacity?
One of the primary reasons for outsourcing of IT infrastructure is to focus on core business and reduce the staffing and skills required to run IT. Yet many IT outsourcing agreements are billed based on capacity usage, so basic performance and capacity management skills are still required for the customer to ensure that the outsourcer is delivering optimally relative to the customer’s needs. A big part of what we do at SMT Data is provide tools and consulting to help customers and their outsourcers align capacity, performance, and cost with business objectives.
But, as someone asked me at a recent conference, ‘Why not just negotiate the business outcomes, response time, batch turnaround, and such and leave the technical details to the outsourcer to deliver.’
The simple answer is that the outsourcer’s costs are driven by capacity usage, and the capacity usage is driven by business activity. Responsibility for understanding the relationship between these two things – capacity usage and business activity – cannot easily be transferred to the outsourcer.
There are two general approaches to addressing this problem.
- The outsourcer agrees to a service level expressed as business outcomes like response time and batch turnaround, but the customer is still billed based on capacity usage.
- The outsourcer agrees to a service level, and the customer is billed based on business volumes.
I’ll discuss some of the pitfalls in each of these two approaches.
Agreed business outcomes, but billing based on capacity usage
In this case the outsourcer commits to a service level agreement or objectives (SLA or SLO). These are usually expressed in terms of well-defined metrics about availability, online response time and batch turnaround time. There are typically penalties for not delivering on these service levels.
Contracts may include some wording about the outsourcer running things efficiently or helping the customer optimize. But these aspects are often hard to quantify and therefore hard to tie to a financial reward for the outsourcer. Since the customer is paying based on capacity usage, the outsourcer’s interest is in setting up an environment where there are as few capacity constraints as possible. This has the double advantage for the outsourcer of maximizing their revenue while reducing the risk of not meeting the agreed service level. This is not about the outsourcer trying to cheat the customer. They are simply trying to optimize their business based on the agreed risks and rewards.
In the mainframe environment, this often means ensuring LPAR configurations that can deliver more capacity than the customer will ever really need. This allows the outsourcer to avoid worrying about capping CPU usage or tuning workload manager (WLM) by simply ensuring that there is enough capacity available that WLM doesn’t ever need to prioritize. For the outsourcer this means less work, less risk, and more revenue. For the customers it often means that they are paying for peak capacity usage driven by low priority work, that should have been delayed to a less busy time through a combination of capping and a WLM setup aligned with business priorities.
A similar phenomenon is seen in server environments. The outsourcer is encouraged to over-configure the servers. This ensures good availability, fast response time and quick batch turnaround. It also increases the outsourcer’s revenue if they are billing based on available capacity. The customer has an interest in rightsizing the servers to just what is really needed, but often lacks the data or skills to evaluate the outsourcer’s decisions or understand the potential tradeoffs.
Agreed business outcomes, and billing based on business volumes
We do see examples where the outsourcer bills the customer based on business volumes, but we generally only see this in cases where IT operations and software development have been outsourced to the same provider. The ultimate example of this is Software as Service (SaaS) where the provider has the end-to-end responsibility for developing, delivering, and operating the platform.
The challenge with this approach is that the outsourcers must be in control of the variables that can affect their costs. Two important variables are business volumes and new functionality.
Business volumes can be the number of users or number of transactions for example. If the customer is an insurance company, then the outsourcer might bill them based on the number of employees, number of customers, number of policies, number of claims, or some combination of these.
New functionality being added to the systems can increase the transaction volumes and can also increase the resource requirements for existing transactions. We have seen that the introduction of mobile banking has dramatically increased the number of transactions in a typical bank. But also simple enhancements to existing functionality can have a big impact on resource usage. If the outsourcer is billing based on business volumes alone, they need to be in control of application development and of what new functionality gets released.
This brings us to the basic dilemma. Determining what functionality is deployed is core business for most customers. Even if the actual development work is outsourced to a third party, it is not necessarily outsourced to the same company as the one doing the operations. The complexity of potentially renegotiating the cost per business unit with each application change makes a ‘pay by business outcomes’ very cumbersome. In general, the contract must have a mechanism to allow the outsourcer to increase the cost per unit based on the actual increase in capacity usage – and now we are back to the ‘pay for capacity’ model.
In the end, you can outsource the work but not the responsibility. Capacity usage and system performance are inseparable from application development, which, in turn, is inseparable from most companies’ core business. Having the data, the tools, the skills, and the time to understand the relationship between your business and your IT capacity usage is essential no matter how you are paying for the capacity.
Steven ThomasChief Technical Officer (CTO)