Pay As You Go

In a recent post, Dave Linthicum talked about the Pay As You Go Challenge, and describes the benefits of Pay-As-You-Go in terms of shifting the risk from the user to the provider. Instead of the user paying for something upfront, before even knowing whether something works (generally, or in that particular use-context), the user pays only if and when it works, and can cancel at any time.

This pay-as-you-go model applies to software-as-a-service of course, and Dave urges that SOA vendors should adopt this model for SOA platforms as well, in other words, something like platform-as-a-service.

But there is a more fundamental economic basis for the pay-as-you-go model, which Dave doesn't mention. As well as shifting risk, the model shifts the balance of costs for the user - from fixed costs to variable costs.

Put very simply, the user's total cost equals fixed cost plus variable cost. Variable cost increases with volume, while fixed costs stay the same. (If you want a more sophisticated explanation, ask a friendly accountant.) Now fixed costs are subject to the economics of scale. If the user has a business process with a significant proportion of fixed costs, then the average cost will go down as the volumes go up. In some cases, a fixed-cost business process may only be economically viable if a constantly high volume can be maintained. But with a variable-cost business process, the average cost is much less affected by volume, and it is possible for the process to remain economically viable across a much wider and perhaps fluctuating range. In other words, a variable-cost process is much more adaptable to changing levels of demand than a fixed-cost process.

And this is where SOA comes in. Under certain circumstances, SOA can support the shift from fixed-cost to variable cost, and therefore can release a whole set of benefits related to adaptability and economic viability - the so-called On-Demand Business.

But only under certain circumstances. The problem isn't with the technology; the problem is with the traditional structures of funding and cross-charging within a typical enterprise or ecosystem or marketplace, which can make it rather difficult to establish adequate pay-as-you-go mechanisms, especially if noone else is doing it yet.

Thus pay-as-you-go is generally more difficult than traditional funding and charging mechanisms. If you are just starting out on your SOA journey, it might make sense for you to defer these difficulties until you have developed some experience and capability in other areas.

And this is where an SOA Adoption Roadmap or Maturity Model comes in. The purpose of one of these is to help you work out which capabilities you need in order to achieve which classes of benefit, and to help you tackle the difficulties in an organized fashion.