I've read an excellent blog entry by Nicholas Carr on SaaS adoption. It is timely as utility computing including commoditised web operating environments (CWOE) and SaaS were a major focus of the web 2.0 summit this year.
[@swardley 19/11/2010 N.B. the term CWOE was renamed later to FaaS (Framework as a Service) in early 2007 and then became PaaS (Platform as a Service).]
Now I'm a vested interest running a company that provides a javascript application platform as a CWOE that we are open sourcing next year in order to create competitive hosting environments for our own platform.
Why? Because we need competitors for our customers to shift to and without such a move we cannot release our grid components, which enables a company to shift from one CWOE to another and back again. It also allows those with large hosting infrastructure to sell "space" back into the grid.
The big issue with many of the services today such as EC2 is portability. Yes, you can access your data but there is no where else to take it unless you build your own - Amazon's issue in my view is that there isn't a Google EC2 or a Microsoft EC2. Taking it back in house, is often an expensive process (in terms of machinery and man power) and most company hosting centres are massively under-utilised (approx 80% under-utilisation is the norm according to Jeff Bezos talk at web 2.0)
Economies of scale and portability are critical issues in SaaS and the CWOE scene, and central to creating an elastic grid of computing services.
There were a number of comments on Carr's blog, which raise some interesting points.
1. Software as a customised service is more likely to become the trend?
It all depends upon whether we are talking CODB, CA or transitional. There is a pre-occupation with customisation and a industry that does rather well out of it. A more likely scenario in my view is that as SaaS is adopted and the industry becomes more portable combined with a greater awareness that much of IT is CODB - then companies will be able to more clearly see the cost vs benefit of customisation. This I suspect will lead to less customisation in CODB areas (CRM, ERP etc) and not more.
2. Control, Flexibility and ROI are key?
The control and flexibility arguments can be covered in general by portability and commoditisation - no point in rehashing the arguments. However ROI? Well it seems (and experience backs this up) that companies on average use less than 20% of the computing power of their hosting environments. And almost two decades of personal experience tells me we are in a industry which just loves to rebuild the wheel. These are both areas which cause a large amount of waste and duplication and therefore are ideal for economies of scale especially in the CODB area.
Now let's make a clear distinction between CA and CODB.
CA (competitive advantage) depends upon differentiation, however if all your competitors are all using CRM or ERP then there is little or no CA (aka the warren buffet loom argument) in such systems (except of course unless the CA is in the implementation phase, as per Andrew McAfee's point on execution, which shows that a company may gain competitive advantage through implementation if the rest of us are so poor at doing it).
The majority of IT is CODB (a reason I'd suggest for the lack of correlation between IT spending and value and the need to focus on as "cheap as chips" approach - see Strassmann's site for more illumination on this matter). In general any savings are passed onto the customer if this is CODB - so the ROI arguments are often spurious at best, it is more a necessity to compete rather than any advantage.
As with all processes which become commoditised, there are always the vested interests who encourage customisation under the old argument of "customised for your needs", "to gain a performance advantage" etc - this is not for the benefit of the company implementing but the vested interest.
So I don't buy the flexibility, the customisation or the ROI counter-arguments. In my world these are the arguments of keeping the status quo - when what our industry needs is this change.
