Friday, July 20, 2007

JSOPs .... buy, buy, buy.

Carrying on from my last post, I want to breakdown the terms SaaS, FaaS and HaaS.

SaaS (Software as a Service) is simply where your data resides in an application from a SaaS provider.

Ideally you want to be able to move your data from one provider of that application to another and know that service will continue to work - you're just switching provider after all. This means the application has to conform to a standard - whether it's a standard for a CRM app or a standard for ERP app or whatever type of app it is.

Before anyone argues that you cannot create standards for such apps, Salesforce supports the case that you can. Where an app is ubiquitous in an industry, it's just a cost of doing business and not a form of competitive advantage. You may want your own special flavour of electricity - I want mine standard, bland, reliable, competitively priced and to come out of a plug.

The common service providers of a standard app worry about how this app is delivered, the infrastructure, how it works and the service. As a user, I care that my data works here with this CSP of CRM and that I can swap to this CSP of CRM because of price or better service or whatever. No lock-in, no exit fees and no hidden surprises.

FaaS (Framework as a Service) is simply where your data and your application resides in a framework from a FaaS provider. Early examples of this include Zimki and BungeeLabs but neither are open sourced yet. [Dec'2009 - this is now known as PaaS or Platform as a Service]

The same is true with FaaS as it is with SaaS. I want multiple providers competing to give me the best price and service, a competitive utility market, with no lock-in, no exit fees and an easy swap from one provider to another.

HaaS (Hardware as a Service) is simply where your data, your application and your framework resides in a machine environment (virtual or otherwise) from a HaaS provider. Again the same rules apply, I want no lock-in, no exit fee and an easy swap - hence open source standards are again the order of the day.

I met Jeff Barr some time ago. I told him that in my opinion the smart thing would be for Amazon to open source EC2 & S3, encourage competitors and compete on price and service - take first leader advantage, establish the market. If they don't, someone else could disrupt their market by doing this to them. I asked Werner the same thing at FOWA and he talked about their "secret sauce". I reckon all that is needed is an open sourced utility computing engine being adopted by small ISPs and they are going to have a fight on their hands.

Monopoly vs Market - who do you think is going to win?

Of course, once this starts to happen, and it is fairly inevitable it will for infra-structural like services, there are whole new opportunities that appear. From exchanges to brokers.

Why bother dealing with a H/F/SaaS provider directly if portability exists, just get a broker to manage the service on your behalf to constantly get you the best price at the quality you need.

Think I'm kidding? Nope, this is where it is going. Which is great for business, the open source world and the new markets which will establish but a complete nightmare for those still selling an ERP app (as opposed to the manner of its use) as a source of strategic value.

If you don't like change, you're really going to hate the future.

All of this stuff has been obvious for about a decade, we waxed on about it at EuroFoo '04 and many of us were delighted that Carr had firmly put the subject on the map.

The first shoots of this have only just started to appear over the last eighteen months and sometimes these things take time.

A future exchange in computing resources? A futures market? Swaps on JSOPs (JavaScript Operations).

You betch'a.

Six years from now, you'll be seeing job adverts for computer resource brokers.

[Update July 2013 - I originally thought the smart play with Amazon would be to open source the technology to prevent themselves being disrupted by an open source play combined with exploitation of constraints e.g. increase demand through a price war beyond ability of Amazon to build. In this I was utterly wrong. 

What I hadn't factored in was the CEOs / CIOs of their competitors being so completely dozy and dopey that they would allow Amazon to walk away with the market right under their noses. You live and learn. Never underestimate the blindness of competitors.]