Friday, December 21, 2007

Wooden horses ....

Amazon has made a really smart move by releasing DevPay. They have in effect created a SaaS (Software as a Service) platform (EC2 / S3 / SimpleDB / ASQS) for others to build SaaS products in. They also provide those SaaS companies (or providers) with a utility mechanism for charging their customers.

It's highly seductive sales story, you can imagine the sort of pitch:

Not only do we minimise your risk and the costs associated with infrastructure start-up and scaling but we also provide you with a simple mechanism for charging your clients. If no-one uses your creation, it costs you nothing and the more people use your service then the more you get paid.

Yes please, I'll buy one .... wow ...... wait. There's a huge gotcha here. Before EC2 / S3 / SimpleDB or DevPay, I was involved in Zimki and we covered the same ground.

Let's say you use DevPay and you decide to take your system out of this environment. Unless DevPay is an open service, then along with any migration costs you are going to have to build a payment service, create a mechanism of charging and then explain this to your customers. That's a lot of pain.

OK, but why would I wish to leave such a wonderful service?

Well the ability to easily leave a service and move to another service is what maintains competition in a market place, thus ensuring that prices for a commodity remain competitive. Now the nightmare scenario for any future SaaS provider is :-

  • To have their systems provided on a utility computing cloud.
  • To be in competition with other SaaS providers on the same or on different utility computing clouds
  • To not be able to move from one cloud to another.

In such a scenario, as a SaaS provider you NEED to enforce lock-in on your customers. If your customers can move services freely (which they will want) then you will face price competition, however since YOU cannot move services freely then your supplier doesn't face price competition.

Eventually all your prices will probably end up matching your suppliers and all your profit would hence be given away in price competition. The Warren Buffet Loom story is a worthy read here.

We considered this scenario for Zimki and the use of a utility billing service to create lock-in. We believed you could even open source everything else and create lock-in with this one little piece. Of course, if you want to create an ecosystem of providers and disrupt a whole industry then you need to open source everything.

Amazon is now that industry.

The last thing to note with a utility charging service, is that it can provide a very useful way of identifying revenue potential of any company using the service. Ideally for the provider of a utility charging service, you want customers of SaaS systems who are billed through your service to be able to sign up to multiple SaaS providers with same account (users would probably argue for the same for reasons of simplicity). This enables the owner of the utility charging service to not only estimate the revenue potential and hence value of the SaaS companies using its service but also cross selling potential. All excellent information for use in a good acquisition strategy.

Even at this seasonal time, be thoughtful of the gifts that others bring .... especially in business.


James Urquhart said...

Amen, brother. This is similar to the issues I noted with SimpleDB. Its nice to use these services when they become available (and SmugMug seems to be all over Amazon's services), but how do you hedge against the cost of your lone provider failing?

Furthermore, say you want to go public with a company based on Amazon (or any other vendor's "locked in" services). How closely is your stock price now tied to the health of the vendor's capacity business? I know if SmugMug goes public, but Amazon starts struggling to compete with Microsoft and Google, I'd be reticent to continue investing in SmugMug unless they could demonstrate contingency plans.

Also, you can have open source without portability, and you can have portability without open source. If I had to choose, I would take portability standards over open source, but I would agree that open sourcing the infrastructure should encourage the community to keep things portable.

I enjoyed your analysis.

swardley said...

Hi James,

Oh no, I hope we are not getting fanatical about this :-)

Anyway how do you hedge against the cost of your lone provider failing ... there is only way one - portability (either patration or software fluidity or whatever term is needed). It's the old second sourcing lesson again.

Regarding the last bit, the point I'm making is that open standards are not sufficient to ensure portability. In order to have portability you need a choice of XaaS providers.

The most practical way of achieving this is to not only have open standards used in the system but to have an open sourced implementation of the XaaS system itself.

My point is simply open standards are a necessity but they are not sufficient for portability. You are inevitably going to need open sourced implementations of such XaaS systems.

Open source is an essential and necessary part of portability.

quicken vs quickbooks said...

If you are trying to open a file doctor quickbooks and getting an error from the 6000 series then you can make use of the Quickbooks file doctor to repair the damaged data before it becomes unrecoverable.