sorted by: recent | see : popular

Content Tagged with pricing + SaaS

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.

RedMonk client eVapt's paper on hooking up a billing system - like theirs - to your SaaS offerings: considerations, benefits, etc.

Just over a year ago, fed up with the over-use of the Lego brick metaphor, my colleague David Sprott proposed the laundry model of SOA (Explaining SOA to the Business). Antony Reynolds of Oracle quoted this in his blog today (The Laundry Model of SOA), which is what reminded me.

Both David and Antony talk about the contract basis of the laundry model.

• I delegate something (in this case cleaning) to the laundry service.
• Officially I don't care how it's done (although the term "dry cleaning" seems to indicate a preferred implementation).
• The laundry service accepts some (limited) liability for any failure.

These are typical characteristics of pretty much any kind of service, more or less. But there is a particular characteristic of the laundry service I want to talk about.

• I entrust the service with something (an asset) that belongs to me.
• I expect the laundryman to be discrete. I do not want my dirty linen washed in public - in other words, I do not expect the laundryman to draw any inferences from the state of my clothes, or to pass these inferences to inquisitive journalists.
• If something goes wrong with the service, then my asset is damaged. The potential liability is linked to the value of the asset, not to the value of the service. (If my dress suit is ruined, I am not going to be happy if I just get the cost of the cleaning reimbursed.)
• I do not authorize the service provider to use the asset for his own purposes. (I do not expect the laundryman to borrow my suit for his daughter's wedding.)

These characteristics are common to many services. I do not expect my CRM provider to try and sell things to my customers, nor to allow identity thieves to access their information. (Indeed, the customer information may not belong to me either; it arguably belongs to the customers themselves, who have entrusted me with their information according to the same pattern.) I do not expect my ISP to read my email, or interpret my search history. (Perhaps I'm being naive about that.)

However, there are many services where this is not clearly agreed. Perhaps I get some cut-price service, and this is only economically viable because the service provider expects to be able to broadcast some advertising to me or my customers. But if I am careless with the small print on the contract, I may not have understood this aspect of the deal.

And there are many services where this simply doesn't apply. For example, information services often simply involve transferring information from the service provider to the consumer, while Software-as-a-Service may simply involve transferring functionality. Obviously there are trust issues here as well - I trust the BBC to provide accurate and balanced news, I trust my internet security provider to protect me from viruses, I trust Microsoft Excel to calculate my profits correctly - but these are not linked in quite the same way to specific assets.

So I think the laundry metaphor is a very useful one, but like any metaphor we must be careful not to push it too far. All services are a bit like laundry, and some services are very much like laundry, but few services are totally like laundry.

"I reckon that SAP is betting on the fact that once users sip the Kool-Aid, they'll want to buy their own refrigerator, blender, mixers, and booze to tailor it just to their liking."