other page actions:
sorted by: recent | see :
popular
Content Tagged payasyougo
SOA and Web 2.0
Economic principles such as network effect and the long tail play a role in how Web 2.0 may impact your business.
Web 2.0 and SOA together can help provide a cost-effective way of accessing these network effects and long-tail benefits.
In order to achieve these Web 2.0 benefits, there are some questions that need to be answered:
This is an extract from an article Lawrence Wilkes and I wrote in February Extending SOA with Web 2.0. Commissioned by IBM and available free from the CBDI Forum website.
Network Effect
- The value of a service in one place depends on the amount of usage elsewhere – the more the better.
- This is especially true of services that offer some form of communication – the value of the service depends partly on the number of other people you can communicate with.
- There is a positive feedback loop – as more people use the service, it may increase in value, thus persuading more people to use the service. This feedback loop may result in a rapid growth curve.
- This leads to the concept of critical mass – the level at which the growth curve becomes self-sustaining.
Long Tail
- The traditional Pareto principle (80% of the value comes from 20% of the cases) assumes a significant proportion of fixed costs. For example, a bricks-and-mortar bookshop must devote shelf space to any book in stock, and there is a cost associated with excess inventory.
- But in a service-based economy, it may be possible to alter the supply-side economics – for example shifting from fixed costs to variable costs – and this means that the rare items (both individually and in aggregate) could be as profitable as the popular items.
- The economic viability of the long tail depends critically on bringing down the fixed costs of servicing the long tail, and shifting to a more flexible variable-cost regime.
Web 2.0 and SOA together can help provide a cost-effective way of accessing these network effects and long-tail benefits.
- Cost reduction – leveraging existing systems through services, helping to cut cost of customization
- Cost mitigation – providing services not solutions, shifting responsibilities to collaborating partners. For example, customer self-service, small communities providing their own solutions. Thus collaboration helps spread the cost.
- Shift from fixed cost to variable cost – for example through “pay-as-you-go” on-demand pricing – thus helping to reduce the risk and the barriers to adoption.
Challenges/concerns
In order to achieve these Web 2.0 benefits, there are some questions that need to be answered:
- What are the implications for IT management? How can I guarantee the continued security of my core systems? How can I provide the necessary quality of service to my existing users as well as the new ones?
- What are the implications for business management? How can I guarantee the continued integrity of my products and services? If third parties are able to mash my services with external services, how can I retain control of my brand and corporate image?
- What are the implications for corporate governance and compliance? Do these external arrangements introduce new risks?
This is an extract from an article Lawrence Wilkes and I wrote in February Extending SOA with Web 2.0. Commissioned by IBM and available free from the CBDI Forum website.
Pay as you drive 2
Norwich Union has suspended its Pay-As-You-Drive insurance scheme [BBC News, 14 June 2008], announced here two years ago [Pay As You Drive]. I am disappointed at this news, because PAYD was my favourite example of differentiated pricing, using telematic information about driving patterns to determine the insurance premium paid by a driver.
This is not the end of differentiated pricing of course, and may not even be the end of PAYD. According to the BBC, there is one other insurance company in the UK (MoreTh>n) offering PAYD insurance, but all I could find on their website was a product called GreenWheels. This is not a PAYD insurance scheme, but uses similar technology to provide detailed information to the driver to help improve the driver's fuel and maintenance costs as well as safety.
Why did the Norwich Union scheme fail, and what does this tell us about the viability of such schemes in general? The primary reason is that the scheme failed to attract enough drivers to cover the fixed costs of administering the scheme. But in the longer term, a scheme like this was only going to be viable if the technology became cheaper and more widely available - in other words, compatible telematics devices fitted as standard to factory model automobiles. And this in turn was only going to happen if PAYD insurance was offered by several major insurance companies (perhaps across Europe rather than just in the UK, with appropriate "roaming charges" as with mobile phones) or if there was some other purpose for the technology and infrastructure. For example, providing information to support eco-friendly driving (Green Wheels). But the big opportunity was PAYD road pricing.
However PAYD road pricing is highly unpopular. There was a major campaign against PAYD road pricing in the UK, orchestrated by the road lobby. The UK government may have hoped that commercial PAYD products, including insurance, might have paved the way for PAYD road pricing, but this now looks less likely than ever.
Meanwhile, we already have some forms of road pricing. London already has a congestion charging scheme, and other cities are likely to follow. But these schemes, along with parking and traffic violations, are currently based on photographing the car plates, and this is of course vulnerable to identity theft. (You just need to put fake plates on your car, and someone else will get the penalty notice.)
At the core of PAYD needs to be a robust and reliable way of identifying vehicles and recording their behaviour, and this raises obvious privacy concerns. All differentiated service depends on an appropriate identity scheme, and such schemes are politically charged whenever governments get involved. So perhaps widespread adoption of differentiated service will have to wait until Identity 2.0 is more mature?
This is not the end of differentiated pricing of course, and may not even be the end of PAYD. According to the BBC, there is one other insurance company in the UK (MoreTh>n) offering PAYD insurance, but all I could find on their website was a product called GreenWheels. This is not a PAYD insurance scheme, but uses similar technology to provide detailed information to the driver to help improve the driver's fuel and maintenance costs as well as safety.
Why did the Norwich Union scheme fail, and what does this tell us about the viability of such schemes in general? The primary reason is that the scheme failed to attract enough drivers to cover the fixed costs of administering the scheme. But in the longer term, a scheme like this was only going to be viable if the technology became cheaper and more widely available - in other words, compatible telematics devices fitted as standard to factory model automobiles. And this in turn was only going to happen if PAYD insurance was offered by several major insurance companies (perhaps across Europe rather than just in the UK, with appropriate "roaming charges" as with mobile phones) or if there was some other purpose for the technology and infrastructure. For example, providing information to support eco-friendly driving (Green Wheels). But the big opportunity was PAYD road pricing.
However PAYD road pricing is highly unpopular. There was a major campaign against PAYD road pricing in the UK, orchestrated by the road lobby. The UK government may have hoped that commercial PAYD products, including insurance, might have paved the way for PAYD road pricing, but this now looks less likely than ever.
Meanwhile, we already have some forms of road pricing. London already has a congestion charging scheme, and other cities are likely to follow. But these schemes, along with parking and traffic violations, are currently based on photographing the car plates, and this is of course vulnerable to identity theft. (You just need to put fake plates on your car, and someone else will get the penalty notice.)
At the core of PAYD needs to be a robust and reliable way of identifying vehicles and recording their behaviour, and this raises obvious privacy concerns. All differentiated service depends on an appropriate identity scheme, and such schemes are politically charged whenever governments get involved. So perhaps widespread adoption of differentiated service will have to wait until Identity 2.0 is more mature?
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.
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.