Enterprise chargeback (the practice of formalizing a distributed carrying cost program for shared assets) is a conundrum. It should be easy but it’s not. Group X used Y, so they should pay Z. Sounds simple right? Go ahead. Ask people who’ve attempted to create a chargeback model for a shared development platform and they’ll likely either laugh or cry. It’s not that envisioning the model that’s so fraught with peril, it’s the adoption problem. Nobody wants to do the cost accounting work. Nobody wants to allocate their budgets for things they don’t control. Everybody wants to continue the free ride. If we don’t shift our thinking, we’re likely to be stuck in first gear forever.
Many organizations struggle with getting a chargeback model accepted by distributed and autonomous teams. I’ve worked in/with enterprises trying to get a low effort, easy to onboard, simple to understand model and if your experience is anything like mine, I think this doctored cartoon from Baloo sums it up pretty nicely:
The three speed bumps on the road to adopted chargeback
What makes chargeback so hard to formalize in a distributed enterprise? While every enterprise has unique characteristics and challenges there are still three common friction points that keep gumming up the works. An unhealthy obsession with precision, over-rotated bias on local control, and the lack of a model that accounts for reuse. If this topic is one that your team is trying to make progress on, please read on or watch our Friends of Max video below to identify the challenges and plan a route that will keep your enterprise journey a smooth one.
Speed bump #1: An unhealthy obsession with precision
Coming up with a precise cost-to-serve model to drive “bills” that are accurate to the penny/dollar tends to be a source of significant friction in distributed enterprises:
- Should we consider operational staffing costs? Ancillary software costs?
- How should we treat “cost of reservation” vs “cost of consumption”?
- How should we consider funding of architectural runway?
Most everyone understands that for external monetization, that cost-base pricing is not a good idea because it leaves money on the table. In external use cases, value-based pricing is the name of the game. For internal use cases on the other hand, the economics are often reversed because the goal is adoption of a shared set of assets/capabilities rather than profit.
In this context, a critical first step for program adoption is to frame chargeback as a “partial-cost recovery” tool. In other words, don’t have any intention of covering the full cost to serve a request (at least not out of the gate) because a precise cost to serve computation requires a lot of cost accounting work that covers operational staff, ancillary software, architectural runway, allocating headroom for usage spikes, and other items that your application consumers and creators don’t really care about.
When you get your organization aligned to a model of partial or significant cost recovery the economics and incentives begin to align with the actual goal of adoption, specifically because creating and consuming teams will receive more value than they are paying for. If you roll out your service and model to internal stakeholders and someone asks for a breakdown of the bill, you can start with “here’s what you aren’t paying for” which then makes the consumption costs and any dependency concerns easier to swallow.
Speed bump #2: An over-rotated bias on local control
Balancing the concerns of the large enterprise with those of consuming groups is difficult when individual and team goals are aligned and integrated into compensation systems:
- Why should a consuming group divert their budget to fund a shared service team when they can keep the funding and control/direct the outcome?
- How can we prioritize and commit to shared efforts when the benefits aren’t realized in a single year financial model?
Regardless of the good intentions of enterprise employees and leadership, “independent kingdom building” is a popular thing inside of corporations. Noting that many leaders equate their status with the number of people in their “kingdom,” you’ll notice that when you ask a decision maker to commit funds for anything, a calculation happens in their head where they compare what you are asking for to the task themselves within their own teams. Nobody likes being dependent on systems they have little to no control over much less having to pay for the privilege of dependency without control.
To overcome this natural bias, you will need to put some focused energy towards defining and instrumenting an aligned set of value metrics (e.g., “time to value,” “development and operational costs,” and “quality factors”). Developing a set of infographics and information radiators to communicate your value proposition will help your partners see the compelling opportunities of a shared platform.
It’s critical to remember that “data beats math” when trying to change status quo behaviors. You may not like it, but the burden of proof is on you to show the value in hard quantifiable terms to give decision-makers confidence that aligning to an enterprise solution will be the right play. Just like a dieting/exercise infomercial on TV, you’ll need to show before/after pics of real people to give your partners a “reason to believe.”
Many teams struggle to find time to develop a set of ubiquitous information radiators. This is why the MuleSoft team has created a freely available Metrics Framework to get you started and our customer success team has a free workshop to align your team to a data-driven future.
Speed bump #3: The lack of a model that accounts for reuse
Developing a chargeback model that accounts for the enterprise value of reuse is difficult given that reuse is often organic and not predictable:
- Why should a producing group share capabilities when potential customers don’t pay for the capacity/compute?
- Why should an architect stray from “fit for purpose” to plan/design for customers who don’t exist yet?
- How can producing groups recoup the cost of development, operations, maintenance, etc when others reuse their assets?
Let’s say you own the budget for an application development effort and someone asks you to design and plan for the assets you are making to be reused by other teams in the enterprise. Furthermore, you don’t just own the development budget. You also own the carrying cost for the infrastructure that will host the application. You get the privilege of allocating your product development budget and time for the benefit of others while you also get to experience the joy of hosting a solution that others leverage for their business objectives that you don’t share the benefits of. Does that sound like a good deal to you?
Getting over this last speed bump is not as daunting as it sounds, because the cellular phone companies overcame it years ago before the days of unlimited calling plans via a model referred to as “calling party pays.” Calling party pays is a telephony term that refers to a charging method that US-based phone companies used to drive cellular adoption. By introducing a structure that relieved phone owners of being responsible for the cost of others calling them, they took a major objection for phone ownership off the table.
If your team doesn’t create a structure to recoup the costs of compute and/or the costs for designing a reusable component, the altruistic incentives to create and share reusable componentry often aren’t strong enough to overcome local optimization behaviors.
At first glance, this may not seem difficult. You could just charge for use by referencing the client ID of the calling party. Therein lies the problem: because the client ID of the calling party in an API-led ecosystem isn’t necessarily the instigator of the request. In an API-led infrastructure where APIs calls are nested from experience, to process, to system, you need to identify “the root” caller which is often not an API at all; It might be a web page, a mobile app, or some other system in your portfolio of applications.
Using Mule 4 correlation IDs as a shock absorber
The above traceability problem isn’t necessarily a dead end however, because Mule 4 has a configuration feature called “correlation IDs” baked into the platform! Mule 4 can lubricate your billing process with a custom correlation ID that is made up of a business group ID to identify the original calling party and a GUID to uniquely identify the request. As one request spawns other requests across an application network, each of the requests carries along with it the same correlation ID that can then be used to create a usage bill where usage is allocated by the original root caller.
So once you’ve gotten past the three speed bumps the last task is creating a bill to distribute to your consumers. To jumpstart your efforts to create an automated billing process, the MuleSoft team has published a working prototype of a billing solution that’s free to download and use. Our prototype uses standard JSON loggers and a few splunk visualizations to compute a monthly bill amount.
In our sample billing solution we used three formulas:
- % API usage per group: business group application requests/total application requests * 100
- Weighted core usage per application: (application core usage/total core usage * total cores reserved)/.1 core
- Cost per application by consumer: % API usage * Weighted core usage per application * Cost per core
We can then pull the applications used per group and enumerate each line item in a bill format to give a total cost for a particular group over any time period. In rolling out a process for your organization, you’ll want to consider billing frequency and how a “true-up/down” model can give your consuming teams a billing plan that gives them both control and predictability.
Using chargeback to charge ahead
Looking back at the wants and needs of the actors and audiences in your API ecosystem, you can see how smoothing out the three speedbumps will accelerate your efforts to roll out a chargeback program that people would readily adopt.
For creators:
- The platform is already paid for inclusive of ancillary costs.
- Consumers pay for what they use.
For consumers:
- The platform and components are already paid for inclusive of ancillary costs.
- I only pay for what I use at a rate lower than cost to serve.
For operators/governors:
- Billing is “push button” and only requires some definition up front to model and process.
Once a chargeback structure has been created and adopted by teams, one of the five major obstacles to accelerating reuse (required changes in the financial operating model) will be much more solvable.
If you are having trouble getting your transformation program into acceleration mode, consider calling the MuleSoft team to help you unlock and reuse your enterprise assets by aligning the interests of your distributed teams.
