How to Create a Platform Cross-Charging Model (and Why Not To Do It)

I'm commonly asked by customers for advice on how they can build a good platform cross-charging model for their organization. And my gut reaction is nearly always "don't." We'll come back to why I think that later, but first let's look at what cross-charging means, why you might want it, and how it can be designed.

Why cross charge?

It’s not uncommon for enterprise platforms to be purchased by a central IT function — and this makes complete sense. This allows organizations to leverage a single negotiation and procurement process and benefit from economies of scale, and the reliance on central decision-makers means this is likely to be the best approach.

However the actual usage of the platform will be federated out to multiple lines of business (LOBs) — a retail group, a manufacturing arm, an enterprise IT function — and over time there becomes an expectation that these LOBs, typically each with its own budget holders and balance sheet, should pay their way.

However, it may not stop there. Within an LOB, an IT team is often targeted with being cost-neutral, so they also seek to recharge their customers, such as the underlying value streams. They then assign their costs against a specific business function, which is often where the real money lies.

Note that cross-charging, or recharging, is billing usage of a platform through recovery of operating and hosting costs. This is separate from product monetization, which is generating revenue by selling access to products. Monetization is a much wider topic and typically requires additional platform capabilities or components to manage subscriptions, usage metering, billing and access control, and so on, and we won't focus on that today.

Whose round?

With many platforms, there are often three groups of stakeholders, each of which may find themselves on the hook for picking up or contributing towards the tab.

• Platform teams are responsible for designing, building, and operating the core platform, including infrastructure and platform software components.
• Producer teams create the applications or services that are hosted on the platform. They are effectively customers of the platform team.
• Consumer teams create applications that rely on or consume the applications hosted on the platform. They likely have little explicit knowledge of the platform itself, but use it by virtue of being customers of the producer teams.

Figure 1: Common platform operating structure

When designing a cross-charging model, the first task is understanding and deciding which of these teams are the primary target for recharging, and that will be determined by the ultimate objectives of applying the recharging model.

Central cost recovery

As we mentioned earlier, the dominant reason for building a cross-charging model is to reallocate costs from a central function into subsidiary LOBs. So the first question should be: How are these costs incurred? Are they fixed over a given time, such as ELA software licences or fixed infrastructure? Or are they variable by usage, such as cloud infrastructure or consumption-based licensing? It's important that the model used aligns with the underlying cost, so that it can scale accordingly and doesn't leave a shortfall.

Where costs are fixed over a known period (such as an annual subscription), the simplest approach would be to simply divide the incurred cost amongst the platform teams using the products. In some situations, the platform teams may already be responsible for funding their own infrastructure and operating costs, so only the software licensing costs need to be redistributed. This can work well where there are a small number of well-defined platforms, but expect arguments as the number of platforms grows, especially if they're of significantly different sizes.

If cost distribution needs to be more proportional to platform size, or the incurred costs vary with usage, you'll need to look deeper at how each platform is being used.

Usage or consumption?

When platform costs are more variable, or you wish to cross-charge based on a more proportional basis, decide early on whether to charge based on usage or consumption. The difference between these is fundamentally based on whether you're charging your service producers or consumers.

• Usage-based: You will charge product producers for hosting their service on your platform.
• Consumption-based: You will charge consumers based on how many products they consume or how frequently they access.

Again, this will likely come down to how your costs are incurred. What metrics are used in your licensing agreement or subscription ,and how does usage growth impact the incurred cost?

For example, if your software agreement is based on the number of CPU cores the software has available, then a usage-based model may make most sense. As more products or applications are deployed onto a platform, the load increases, and more CPUs are required to host the platform. Service consumption may also have some impact here — more application users require more CPUs to serve their requests — so a blended model may be required.

What's important here is to ensure that the metrics being used align to the team or persona being targeted with the cost, so that it's something they can control. Using a consumption-based metric to bill a service producer team is both inaccurate and a risk, and it may significantly damage the overall value of the platform — we'll see why shortly.

More than just software

When constructing a platform recharging model (that is, one created to recover platform costs from the producer and consumer teams) there are other costs that may need to be considered. Infrastructure costs are a key consideration; although these may already be incurred at an LOB level rather than central, they're not always easy to accurately divide and allocate. Compute costs, storage costs, and network ingress/egress costs need to be considered — even rackspace, power, or cooling costs if physical data centers are still being used.

The other costs of operating a platform are the staffing costs: platform ops teams to maintain central platform components, patching, upgrades, etc. Some attribution of helpdesk or L2/L3 support teams may be required.

Finally, consideration should be made to enablement, if this is driven from a central team. This may be creating or delivering training courses or materials, providing or maintaining knowledge bases, or staffing a center of excellence (CoE).

You can see that building an all-encompassing model is highly complex and requires multiple data points, especially to make it fair and accurate.

Building the model

How do we go about building up a model?

Many enterprise platforms, including Kong Konnect, expose a raft of metrics and analytics data that can be used to understand platform usage and build a cross-charge model. These metrics can be exposed in Kong Konnect Analytics and displayed in a dashboard, or exported using a wide selection of plugins to an external tool for greater control and cost modelling.

When using Kong Konnect (or Kong Gateway Enterprise), there are some key metrics that are valuable, depending on the chosen cross-charge model being created. For example:

• At a platform level, the number of control planes (in Kong Konnect) or workspaces (in Kong Enterprise) gives a high-level quantification of platform size, which may be sufficient for cost allocation.
• For producer teams, look at the service count within owned control planes, or labeled services.
• At a consumer level, the number of requests based on labeled consumers may be most appropriate.

These metrics can either be directly converted into a dollar amount (like "$X per service" or "$Y per API call") or used to create a proportional model that allows costs to be allocated.

If considering a consumption-based approach, be wary of a model that could create unbounded or runaway costs. This approach would likely be seen as a risk and may put off teams looking to adopt the platform.

This usage data then needs to be combined with infrastructure costs, if these are also in scope. This can be a bit harder to directly attribute to a particular team, especially in cloud architectures where there are multiple abstraction layers between infrastructure and application, such as VMs and Kubernetes clusters. The simplest approach may be just to attribute a cost based on the proportional usage above.

The "soft" operational and enablement costs will require some level of manual input as these data points are unlikely to be drawn directly from the platform. Again, operational costs may need to be allocated on a proportional basis or enablement costs attributed based on the number of registered or trained developers, for example.

Figure 2: Dashboard data collection

Once the metrics have been identified, consideration then needs to be made as to how often the calculations will be made and charging models updated.

I once saw a customer team who knew the cost models were always calculated on the last day of a quarter, so they made sure to shut down all their non-production services (and probably went to the beach) in order to benefit from a lower bill the following quarter. Continuous data collection may be required along with appropriate aggregations and trends (e.g., rolling 30-day averages) to ensure the best quality model; this requires investment in appropriate automation to execute.

What goes wrong?

So why, then, is my instinct often to try and dissuade customers from taking this approach?

In short, it's based on simple human behavior: everyone loves a free lunch (or a free platform, in this case).

No one wants to pay for something if they don't have to. Every business I've ever worked with at some point has a focus on costs (for obvious reasons) and often places value on individual teams to find savings.

So let's start with the simple fact: a cross-charging model won't save you money.

Yes, there are arguments that by pushing or exposing costs at the user level, it makes people more mindful of what they consume. This is the "smart meter" argument — that by energy companies putting a display in your hallway or kitchen telling you how many dollars or pounds you've spent today, it increases awareness and makes you turn off the light. In practice though, it probably doesn't make significant step changes in behavior. I still want to turn on lights when it's dark, I still want clean clothes to wear, and I'm still going to fire up the coffee machine first thing in the morning.

Nearly every enterprise platform will have been sold with some level of business case, or BVA (business value assessment). This will show how quickly a return on investment can be realized and how many dollars a business will save over multiple years by buying the platform. But this BVA will contain a number of assumptions, many based around platform adoption. By introducing barriers to adoption, you're inhibiting the organization's ability to realize that business case and ultimately lowering the value — and savings — that can be achieved.

The establishment of cross-charge models also comes with multiple costs. Staff costs to design, build, update and operate the models, collect and curate metrics, execute the financial administration process, etc. If platform metrics are being captured, stored, collated, transformed, and displayed, this also comes with processing, storage, and software licensing costs of its own. Do these costs actually offset any reduction in usage of the platform?

People also act defensively when faced with an unexpected change, especially when money is involved. Introducing a cross-charge cost to a team to use a platform — especially when it's been free to them until then — is likely to elicit a reaction. That may be the team looking at alternatives: is there another platform that meets their needs? Do they need to pay for all the capabilities of a platform when they only use a subset of these? (That's a different topic on platform value we'll discuss another day.) Do they need a platform at all?

This introduces the risk of shadow IT, where product teams go against enterprise strategy to do their Own Thing and make decisions that are limited to the context of their own domain, not at an organizational level. Again, this impacts adoption of the primary platform, diluting value and ROI. It may introduce security risks, as non-approved tooling is used or requires additional effort to update, maintainand patch. It lowers developer experience as it lowers consistency across different teams, making it harder for developers to work in, or across, multiple products.

Specifically, within API management (although this does apply to other platforms as well), one key value metric is the premise of reuse.

The use of a central platform should allow teams across the business to easily explore and leverage solutions used by other teams, saving them the effort and time of creating something themselves. But careless or overbearing cross-charging can stifle this — I've seen it happen at more than one organization I've worked with.

A team that creates an API and allows this to be leveraged by other teams may object to a cross-charge model based on consumption: "If I’m charged based on the volume of traffic my API serves, why should I allow other teams to access and reuse my API?"

Equally, teams looking to reuse APIs from elsewhere may balk at a consumption cost: "If I’m being charged for each API I consume, maybe it would be better to just write my own that does everything I need?"

API reuse (or product reuse in general) is something that should be incentivised, both from a producer and consumer team perspective in order to yield net savings at the organizational level.

Ultimately, metrics drive behaviors, and the wrong metrics will undoubtedly result in the wrong behaviors.

On more than one occasion, after reviewing the actual requirements behind cross-charging with an organization's leaders and realizing that it's primarily something that they think they need to do rather than something they actually need to do, it was determined cross-charging offered insignificant value to offset the costs and risks associated.

Keep it simple, silly

Of course, doing nothing may not be an acceptable outcome for everyone.

Pushing costs away from a central EA or CTO group may be necessary, not least for reasons of budgets and cost allocation. So if that is a hard requirement, then create the simplest possible model to achieve that. In the context of Kong Konnect or Kong Gateway Enterprise, consider a high-level metric, such as the number of Control Planes to quantify the allocation across platforms. Keep the model simple and cheap to support and maintain and introduce as little friction as possible to your value streams.

Explore the analytics capabilities of Kong Konnect to get started today.