Loosely Coupled weblog

Tuesday, March 22, 2005

Software-powered services

The move to SOA has a lot in common with certain forms of what is known as SaaS  in particular those being discussed at today's SDForum event in Santa Clara. It's great to see so many leaders in the field brought together for an event that has quite rightly sold out. But at the same time, I can't helping feeling disappointed that it's happening under a title that in my view is  and always has been  a complete misnomer.

To my mind, the phrase 'software as a service' has a misleading set of connotations that cause a lot of confusion when people talk about the sector. Many of the participants prefer to call themselves 'on-demand' providers, as distinct from vendors of 'on-premises' software. That gets part of the way there, but 'on-demand' is itself a much-abused term, especially by the likes of IBM, who like to wrap it up with this notion they have of utility computing (a notion, as I've previously written, that is tarnished by many misconceptions of its own).

I've been giving this matter a great deal of thought over recent months  and this is one explanation for the paucity of postings to this blog since the beginning of the year  because I've been writing some research reports for Summit Strategies on this very topic. It's a return to a familiar subject for me: several years ago I was seen as one of the thought leaders of what was then known as the ASP sector, having founded the ASPnews.com website in late 1998, which subsequently became part of Jupitermedia's online network. A lot of the attention at that time was focused on ASPs that delivered conventional software using Citrix or other thin-client technologies, which was a pity, as I never saw that as more than a stopgap technology. I always felt that what Summit likes to call the "net-native" providers were the ones with the best chances of success  including salesforce.com, Employease, NetSuite, RightNow Technologies and WebSideStory  all of whom are represented among the speakers at today's conference.

So when I sat down to write about this new breed of independent software vendor and what impact they were likely to have on the enterprise applications market, one of the first challenges was getting the terminology right. The problem I have with talking about 'software-as-a-service' and 'on-demand software' is that these phrases continue to give the impression that the model is all about delivering software, with the underlying implication that all that's changed is the delivery mechanism. In truth, the transformation is far more fundamental than that. The most important point to bear in mind about these net-native, on-demand ISVs is that they own and operate the software themselves. They take responsibility for making sure it's up and running before the customer starts using it. What the customer pays for is not the software itself, but the working functionality the software provides.

This is a distinction that the conventional software industry has a lot of difficulty understanding. They're so used to customers paying them simply for shipping out software that they think 'software-as-a-service' means signing a service contract for the same thing spread over three years. Think Microsoft Software Assurance (I know it's not a service in the same sense but it's symptomatic of the problem), in which the only thing assured is that you'll keep on paying Microsoft for the term of the contract, however much or little turns up on your doorstep, and irrespective of whether it works. The conventional ISV's view of 'software-as-a-service' cannot help but be tainted by all the defects and limitations of their current software-as-a-product model.

I've settled instead on the phrase 'software-powered services' because it goes to the heart of the on-demand, net-native model. These ISVs are certainly software experts, but they focus that expertise on creating functional services and applications for their customers, delivered to agreed performance levels throughout the life of the service relationship. The other advantage of using this phrase is that it applies equally well to services in a service-oriented architecture. That's not just a coincidence. These two forms of software-powered services are converging, and in my opinion will fuse sometime in the coming decade.

A lot of thoughts, findings and intuitions from the past five years have come together in these two reports (plus one other that came out last year: From Myth to Reality: Traditional ISVs' Evolving Software-as-Services Strategies). The project has not only produced a roadmap for where I believe the enterprise software industry is headed, but has also helped me map out my own trajectory in tracking its progress. Believe me, it's going to be a fascinating journey.

UPDATE [added March 23]: As I mentioned above, one of the problems is that the SaaS label implies that "all that's changed is the delivery mechanism," which encourages conventional vendors to ignore the really transformative aspects of the model. Well, Creative Weblogging's Torsten Jacobi posted a session-by-session blog of the event, and lo and behold, here's what Siebel's Ken Rudin, VP CRM on Demand, was saying in his panel session: "Ken insists that SaaS is a delivery model and not a new class of software." Hmm, I guess my work here is still not done.