SaaS doesn't matter
Thomas Otter, an Enterprise Irregulars blogger who works for SAP, complains that SaaS has been arbitrarily defined by a purist cult who refuse to admit that, as he puts it, "SaaS is simply the latest evolution of the bureau."
Nick Carr, author of the contention that IT doesn't matter, respondsWhat really matters is delivering business services, not software with "a lesson in what SaaS is." Unfortunately, the example he chooses is Glovia GSInnovate, a SoSaaS implementation of Glovia's conventional on-premises ERP software for manufacturing companies. I coined the term SoSaaS for this type of offering precisely because they share virtually none of the characteristics of the on-demand applications that are the future of SaaS. It is simply misleading to cite this kind of proposition as an examplar of SaaS. No wonder Otter is confused.
Like so many SoSaaS initiatives before it, GSInnovate was launched last month with great fanfare as "a perfect fit for today's small and midsized ... companies." Yet strangely it has not a single customer in production, nor any tame prospects trumpeting how eager they are to go live with this cut-down new version of Glovia's established enterprise software product. I wonder how many of them will be tempted by the "minimal" starting price tag of $5k per month? No more, I suspect, than will be attracted by the "top manufacturing management capabilities" that Glovia's superficial and patronising market research has found them to be so sorely in need of.
My long-term dislike of the term 'software-as-a-service' is that it feeds this misconception that the debate is simply about different ways of delivering software: that you can take some software that currently exists 'as-a-product', host it in a data center somewhere, and let customers subscribe to it 'as-a-service'.
What it's really about is different ways of delivering services. Therefore I personally like Thomas Otter's bureau analogy, but with one reservation: the term sets another linguistic trap for computer industry people, who always start thinking of time-sharing computer bureaux, which is an unhelpful distraction into utility computing concepts. Look carefully at the paragraph he cites from ADP's corporate history and you'll see that when the business started in 1949, "It manually processed company payrolls" (my emphasis). There was no software involved.
That's why I like the analogy and why I've given this item the semi-ironic headline, SaaS doesn't matter. Of course it does matter, in the same way that IT matters, but both of them are subsidiary to the real issue. What really matters is delivering business services, not software. People go to ADP not because they want computerized payroll — if that's what they want they can buy a software package to do that — but because what they really want is to get their payroll done on time. They don't care how ADP achieves that goal. They just want a service performed, accurately, reliably and cost-effectively. Of course, to achieve those objectives, any service provider these days is going to have an automated infrastructure that uses some pretty powerful software. It so happens that ADP in the US uses SAP. But the software is not the service. It's just part of the infrastructure.
The other technology piece that any service provider is increasingly going to be using today is the Web — 1.0, 2.0 or whatever x.0 level of sophistication is available and appropriate. And it's this combination of the Web with software infrastructure powering on-demand business services that makes the killer difference. I don't believe ADP has quite reached that level of sophistication with its payroll services, but if you want to define what I've described as "the latest evolution of the bureau," that's fine by me — just like you could define the jet engine as "the latest evolution of the Chinese fire-arrow."
PS: I see Dan Farber has referenced David Terrar's response to the Otter-Carr exchange. I have another post under way as a follow-up to that; my own canonical definition of SaaS.