Resource-Based Pricing
This week, the Economist reports on a software pricing question that has been disrupted by technological change. (Economist, July 14th 2005)
Software vendors such as Oracle typically offer several different pricing schemes for users to pay for software. A popular pricing scheme for very large customer organizations is based on the number of processors on which the software is operated.
Both Intel and AMD are now ramping up production and sales of dual core processors, especially for back-office servers (where large numbers of Oracle databases can be found). If Oracle were to stick with the per-processor pricing scheme, it would suffer a significant loss of revenue. Instead it has redefined the pricing scheme, so that it now refers to the number of cores rather than the number of processors. Now it is the customers who are complaining.
Let's look more closely at how this mess emerged. The pricing scheme appeared fair to both sides in the context of a technology reference model in which each processor has only one core. This reference model is now being replaced by a new model in which one processor can have multiple cores. In renegotiating the reference model, Oracle is put in the awkward position of saying to its customers: "hey guys, when we said processor what we really meant was core".
In a complex and open world, reference models are unstable. (In this case, the trigger is a technological change - but it could equally have been a shift in the demand ecosystem, regulatory ecosystem or anything else for that matter.) The increasing prevalence of unexpected referential shifts is a significant source of uncertainty and risk for all stakeholders. Specifically, with resource-based pricing, risks are associated with possible changes in the reference model describing the resources on which the pricing is based. IT folk typically deal with the potential instability of a reference model by generalization or late binding - in other words, going to a different level of abstraction and/or leaving the specification incomplete - but that approach doesn't work here because if you take the specificity away from the reference model, the pricing scheme becomes arbitrary/incomplete. "Hey guys, when we said processor what we really meant was any kind of asset really, oh we'll work out the details later."
So should Oracle bill its customers according to the number of processors or the number of cores? The answer is: neither of the above. Resource-based pricing simply isn't flexible enough to give everyone a fair deal over an extended time period. So what's the alternative?
From Input-Based Pricing to Output-Based Pricing
There are various forms of input-based pricing besides resource-based pricing, but they all suffer from a similar set of problems. Among other things, the service provider has no incentive to improve efficiency. Go figure: a software provider gets paid more if the software consumes more hardware, what do you think is going to happen?
For the service economy, output-based pricing makes much more sense. Consumers pay for what they actually get, rather than what the service provider uses. There are various ways of calculating this, at different levels of granularity, with different distribution of risk.
Pricing Schemes
In my CBDI article Identifying Web Services (Feb 2002), I suggested that a pricing scheme should have the following characteristics.
Transparent - meaningful and understandable by customers and suppliers
Predictable - customers can predict how much the service is going to cost
suppliers can predict how much revenue the service is going to yield
Workable - technically feasible and efficient to administer
Incentive compatible - encouraging economically efficient distribution patterns of demand and supply
Stable - steady and sustainable over time, with reasonably steady price adjustments
Economic - capable of being delivered at a reasonable return for the supplier
Fair - level playing field - avoiding unfair discrimination between different classes of customer and usage, avoiding anti-competitive practices
In a recent blog, the author asks: Can we afford SOA?
It’s time to start thinking about service chargebacks. How do we design something fair? What are other companies doing? I’d love to get feedback on this if anyone is reading this.
The question is a good one. Although we have talked about service pricing before, we haven't done anything recently on the topic. So we are producing a new report on service pricing for the September Journal. As always, we welcome contributions and suggestions from members. Please let me have your experiences and opinions on this critical topic.
Author: richard.veryard@cbdiforum.com
|
Home