Chargeback Models for IT Services Require Deep Platform Utilization Data

Chargeback models for IT services isn’t a natural trigger for excitement, but with the right operational intelligence, things get interesting when you go beyond recouping costs. That happens when infrastructure utilization data (both real-time and historic) is applied to shared services chargeback models. The result is constructive conversations that improve operating margins and free up resources for higher value activities.

What is IT Chargeback?

Simply put, IT chargeback is the effort made to recoup the technology and human capital costs that are expended to build, acquire, support, and manage technology products and services shared across the organization. You need to know who (or what) used which technology, when, and in what capacity from which to calculate a cost. This responsibility is borne by the shared services team in large organizations.

The volume and type of infrastructure utilization data required depends on two things: (a) the platform analytics capabilities that you have, and (b) the chargeback model being used.

What is a Chargeback Model?

The chargeback process starts by measuring resource utilization over time and then applying a cost factor. The chargeback model is what determines how those measurements are formulated and the action to be taken on the results.

Gartner¹ identified a set of best practices for shared services chargeback based on five standard shared services chargeback models, which I have summarized below:

  1. The cost center model: This is the easiest model because there is no pricing strategy to maintain, and with no pricing strategy, there is no need to account for utilization in detail.
  2. Fixed allocation model: Another simple model in which each business unit is charged a flat rate or percentage. Because each group is charged the same amount month over month, there is little incentive to make the best use of resources.
  3. Variable model based on actual volume: This model starts to bring equity to the process by making each business unit accountable for the services that they consume. This requires accurate data collection not only to determine cost but to address disputed charges.
  4. Market-based model: In this model, the price of a particular IT product or service is influenced by external market rates of similar services. This is a good way to reduce shadow IT efforts that try to get better prices through 3rd parties (and increase 3rd party risk). Accurate consumption data is required to support good market comparisons.
  5. Cost-plus model: A profit margin intended for infrastructure reinvestment is added to the base cost. The chargeback to the business is not as transparent as in the earlier models with regard to the base cost of services.

The models described above run from simple to complex. Depth of data, timeliness, accuracy, and accessibility become increasingly important with models 3 through 5, not only for reporting purposes but to enable those models in the first place.

For example, if your organization is mature enough for a cost-plus model that encourages fiscal responsibility, but you don’t have the platform analytics capabilities to support it, you may be stuck with a fixed allocation model that doesn’t encourage business units to control costs.

Big Data—Big Challenges for Shared Services

Shared services organizations are challenged to respond to the growth demands of their organization. However, they also need to deal with the complexity that comes with that growth across a greater number of teams, cross-functional silos, geographic locations,² and virtual worlds residing on multi-tenant on-premises data centers, a private cloud, and public cloud environments.

Beyond the organizational aspects, it’s not a simple thing to track the usage of shared IT services that are distributed anywhere across a technological landscape layered with servers, virtual machines, containers, and other devices that each have their own unique functions and interactions.

Market data in financial services provides an example of this complexity because it is shared across a range of applications. The over-consumption of resources by a single app, especially as it relates to algorithmic trading, will negatively affect trading performance in two ways: (a) operational costs eat away at small incremental profits, and (b) resources are frozen that could be used for higher value trading activities.

A variable shared services chargeback model that is based on actual volume will instill good cost control behavior across the application owners but you need the right information to enforce it. It is one thing to figure out which application is over-consuming resources and another to figure out why. If you don’t know why then you can’t fix it, and that becomes a shared problem.

To further complicate the issue, an app that has been identified today may not have existed yesterday and may not be there tomorrow. This is because of the flexibility provided by cloud providers to spin new services up or take them down at any time.

Capture, Use, and Report on the Right Data

Solving the challenges described above requires a certain level of transparency. You need to know what’s going on. The more complete the picture, the better, and I will use Pepperdata Platform Spotlight to describe this in real terms. Platform Spotlight headlines an integrated suite of Analytics Stack Performance (ASP) tools that provides a full 360° view of your infrastructure and resource utilization.

Which data should be analyzed?

In short, just about everything because you don’t know how models will change (i.e.: improve) over time. The more sophisticated the model (or hybrid of models) that your organization adopts, the more deep, timely, accurate, and accessible that data needs to be. These are further contextualized below:

  • Depth and timeliness: Pepperdata instruments every node to continuously collect and correlate hundreds of real-time operational metrics: host-level CPU, RAM, disk I/O, and network metrics as well as job, task, queue, workflow, and user.
  • Accuracy: Because the data is captured at the source you get actual utilization, not a calculated abstraction of it.
  • Accessibility: Platform Spotlight makes all of the data available via a streamlined UI, direct downloads, REST API, and data science reports.
it chargeback

Figure 1: The 360° view of infrastructure and resource utilization within Platform Spotlight. Pepperdata cluster performance monitoring includes real-time and historical information, including system demand, abusive users, and wasteful applications.

With the full set of capabilities described above, and as teams recognize what is possible, shared services chargeback models will evolve for the better. For example, the timeliness aspects will enable administrators to identify the factors that drive costs in order to optimize and budget accordingly much sooner than on a monthly or quarterly basis.

Go Beyond Recouping Costs

Below is a simple example that revisits the market data scenario above and describes how Platform Spotlight will enable organizations to go beyond recouping costs to drive cross-functional collaboration and facilitate better business outcomes.

Trading desks consume many different types of market data feeds that are each shared by many application owners, each of which expends resources in a different way. It quickly gets complicated to identify the source of platform overutilization because of the variables involved. Does the problem lie with the platform, how the market data is processed, or one of a thousand apps querying that feed?

As part of an investigation into platform utilization, this story starts by identifying the user that consumes the most memory and the most CPU, which in this case is Doug (see Figure 2).

We could stop there and charge back that utilization to his department, leaving it to him to argue the issue with management.

But in the spirit of collaboration, Platform Operations takes a proactive step further by investigating how Doug over consumes resources by drilling down to the applications he uses. In this example, the culprit is MktDataApp#260 (see figure 3).

What do we know now?

  • Doug is the most expensive user.
  • He is expensive because of his use of MktDataApp_260 that was developed by his risk team.
  • We have an accurate and detailed accounting that is charged back to Doug’s department in terms of memory, utilization, and core hours.

Let’s take a proactive step forward:

  • Doug’s risk DevOps team now knows that their MktDataApp_260 is expensive to run but they don’t know why.
  • With the help of Platform Ops, real-time and historical data is used to compare job runs over time to understand actual performance issues across each job phase.
  • Armed with that information DevOps rapidly ascertains that they have an executor sizing problem and implements a solution.

There are two benefits from this cross-functional collaboration:

  • An optimized MktDataApp_260 is less expensive for Doug.
  • Capacity is freed up for revenue generation apps.

it chargeback 2

Start a Constructive Conversation

The story above describes a simple and localized scenario. If you apply it across thousands of users around the world, then you can get a sense of how great the opportunity can be.

Deep, timely, accurate, and accessible platform utilization data empowers shared services chargeback models to make a difference and generate better business outcomes by a) providing accurate accountability, b) serving as the mechanism to encourage corporate fiscal responsibility, and c) facilitating constructive conversations between parties that seek solutions and optimize platforms.

To understand how the Pepperdata integrated toolset enables finance and big data success through DevOps and Platform Ops collaboration, read this solution brief, “Optimize Data Analytics in Finance.”

For a demonstration of how chargeback reporting is done with Pepperdata Platform Spotlight, see this video.

 

Sources:

1. Gartner. 5 Shared Services Pricing Approaches (November 19, 2019)

2. Gartner. Key Trends and Best Practices Impacting Shared Services Strategy and Structure (2019)