SOA Economic Model: Avoiding Chargebacks with Transaction Ratio Funding

  • Article

There are still people who believe that Chargeback models work.  For example, Mark Denne argued in CIO Magazine in January:

"Chargeback is a way to put IT services in terms that businesspeople understand and value. When IT is bought and consumed like other services, IT can become a business within the business. And that is the path to true IT value." (link)

To say that I disagree would be putting it mildly. 

I believe that chargebacks work in very rare circumstances.  In all but the rarest of cases, chargebacks not only fail to provide a measure for IT value, but they actively work against the enterprise by providing an economic incentive for the business units to build solutions that do NOT make calls to shared resources.

Now that we are entering the age of SOA, many folks are resurrecting the idea of using chargebacks as a way of incenting IT groups in large organizations to take on the burden of hosting a service that many different applications will use.  The idea is that we would measure the calls coming in to a shared service, and use those measurements to charge the users a fee for using the service.

Let me provide a scenario to make this clear.  Let's say that Contoso Sports retails fishing rods.  They also have a division that offers fishing tours and vacations.  Two completely different businesses under one roof. 

To keep things "simple", Contoso management created two different IT teams: one aligned to retailing, and the other aligned to travel services.  Let's say that a SOA architect comes along and says: put a service on the Customer system in the retail division, so that both divisions can use the same "customer master."

Sounds good, doesn't it?  That's the value of SOA, after all... to leverage shared resources.  Right?

The problem is the Customer system is part of the retail IT group, paid for by the Retail business.  All of the costs of developing and maintaining those services, including software development, activity monitoring, and failover support, are being borne by the Retail division, even though the Travel division use those services. 

The tempatation here, and the discussion among some SOA folks, is to simply meter the service calls.  Each call by the Retail division's applications will be charged to the retail division budget.  Each call by the Travel division's applications will be charged to the travel division budget.  Both divisions are using the same service, but they are not equally founded.

It is a really bad idea. 

In this situation, it is clear that the operating model of the company is either to keep these businesses seperate (with their own profit and loss statements) or to allow coordination but not enforce common processes.  Traditions grow up around those business decisions, and one of them is that the business leaders are used to dictating the scope of work for their IT teams.  The IT teams know where their bread is buttered, so they do only the work that their direct business customer wants to pay for. 

...And SOA is undone.  In the chargeback model, any feature change driven by the Travel business unit in the Customer system (travel meal preferences, for example) will not be paid for by the Retail division.  The travel division is now disincented from helping Retail with a shared service of their own. Communication stops. 

Using chargebacks, there is no incentive to develop a shared resource.  The funding model simply doesn't allow it.

This is because chargebacks have the same effect in the SOA model as they do in other forms of computing: chargeback systems reward those people who avoid them.  

We shouldn't be surprised.  This behavior makes sense.  We've seen it before.  Avoiding chargebacks is a proven strategy in life as well as IT.  We see it in the people who drive to other states to purchase things without a local sales tax, and in the departments who fled the mainframe environment, where they were charged back for each second of CPU time.

Creating a chargeback scheme to pay for a shared resource is like burning a hole in your shirt to get rid of a coffee stain: it works exactly once, and you won't like what you end up with.

One thing that makes more sense is what I call Transaction Ratio Funding or TRF.  In the TRF model, all shared resources partake of a different funding source than business-aligned resources.  This different funding source is a fixed budget allocated to pay for shared services.  How do we get that funding source?  Either the businesses pay a flat tax to the "service hosting fund" or each IT team is simply allocated a seperate budget for shared services. Either way, the business units are NOT visibly charged back for shared services. 

In Transaction Ratio Funding (TRF), you start with a fixed operating budget.  Then, based on the ratio of transactions, the single operating budget is divided up between the teams.  For example, if team 1 hosts 20,000 transactions against their shared services, and team 2 hosts 30,000 transactions, then team 1 would get 20000/50000 or 40% of the operating budget, while team 2 gets the other 60%.

This simple model rewards the IT teams that develops shared resources, without punishing the business funding sources for creating them.

So as you consider your SOA economic model, remember this:

  • Planning to develop shared services without an economic model is planning for SOA failure,
  • Using a strict chargeback model for shared services kills your SOA,
  • Transaction Ratio Funding from a fixed operating budget rewards the IT teams that create the most shared services.

And the next time someone suggests creating a chargeback scheme for SOA services, try not to laugh.  Not out loud, anyway.