Software as a Service - Part 1

I can’t tell you how many board meetings I’ve been in lately where the agenda included a discussion of the merits of software-as-a-service as a potential business for the company. The one thing that is constant about these discussions is that nobody can fully agree on what the idea of software-as-a-service really is. Some see it as a delivery method, others see it as a pricing strategy, and there’s even confusion with the popular “on demand” meme that we can blame IBM for inflicting.

Let’s agree on one thing: just like client/server meant different things to different vendors in the mid 1990’s, software-as-a-service has many definitions that the market will sort out in time and that there is no right or no wrong definitions at this time.

Let’s agree on a second thing: software-as-a-service is as much a change in the perception enterprise customers have about what software is as it is a technology or business model disruption for vendors.

Most of the talk about software-as-a-service centers on the idea that it is a delivery method; vendors will host applications and clients will subscribe to them. This really isn’t anything new, I’m sure you can recall the heady days of the ASP company which in itself was just a new set of terms for the outsourced IT movement that began many years before.

So if software-as-a-service isn’t simply delivery of application functionality to customers, is it subscription software, which in itself is limited to the manner by which a company charges a fee for their products? Perhaps, and if any one thing is crystal clear about this theme it is that enterprise customers are increasingly viewing software as a provided service and in many cases they want the freedom to discontinue the service if it no longer provides value to them. But a software company can have a subscription licensing model for a product that is being implemented by the customer in the customer’s data center, so this disconnection from the delivery aspect of the product in question raises the question of how integral subscription pricing is to the software-as-a-service idea.

In fact, one could argue that the concept of perpetual software licenses is not in the best interests of the licensor. I could also argue that the maintenance agreements attached to the license are really the thing that is coveted, so wrapping up license and maintenance into a monthly/quarterly/whatever fee is “the same thing, only different”.

The ability that a customer has to discontinue use of an application and more or less immediately cease paying for it is new, ironically. There is something I find troubling about this concept in that the application in question is supposed to be a value creating set of functions that the customer is using to support a portion of their business, but if they can simply stop using it and/or switch to another application, should we be concerned about something more important than the licensing model?

So let’s talk about on demand now and the implications for software-as-a-service. Clearly there is a desire on the part of customers to have a computing environment that scales up or down as demand dictates, all with a seamless and continuity that minimizes, or eliminates, disruption for end users. The software-as-a-service vendors that host their apps for clients and have an elastic pricing model that ebbs and flows with usage all claim this is a big benefit, and it definitely is. Let’s also be clear that the risk for customers is that they are entering into an unbound licensing model with regard to upside costs, because as the end of the day subscription pricing is fundamentally anchored to consumption of functions and resources by users and machines.

Where do I come down in this debate? Without even getting into the sticky issues of security, service level agreements, configuration/lifecycle management, and customization, I feel confident in my belief that we are seeing a fundamental change in our industry that goes beyond technology. The software-as-a-service movement is as much about the perception of what software is in the eyes of the typical enterprise customer, and the nature of the relationship they wish to have with their vendors. For software startups, the key to being successful in this model is one of economics, embracing a development methodology that brings them to market quicker and offsets the significant costs of creating a new market, as well as a sales model that decreases the significant cost of sales associated with selling large enterprise deals.

I'm thinking that for the next part in this series I'll write about how software-as-a-service and SOA converge. I'd appreciate hearing your comments on this subject.

Comments

[Ramana Kovi]

I belive Software-as-a-service is here to stay. I think all your points are valid, pricing, delivery are important components of the SaaS model. You are right on what cutomer is looking for - "flexibility to customize the applications to fit its needs, dispose it when done with it."

I think the big vendors (i.e oracle,SAP and siebel) most probably will play less of a role because it requires complete transformtion of changes in thier product line and thier sales processes.

[Dennis Posadas]

It will of course, benefit the software companies, in that they can forecast an NPV from their stream of cash flows in the future.

Dennis Posadas
author, Rice Bowl & Chips
How Asian countries are using the Silicon Valley
model to develop technology startups
(ISBN 0-595-34583-2)
http://www.ricebowlandchips.com

[Adam Messinger]

SOA and SaaS are related by one of the efficiencies which drives SaaS, namely the reduced cost of engineering which comes from not having to support the software in varying environments nor support many versions of it. To maintain this efficiency one must provide an integration API (so that customers don't demand you run in their environment for integration purposes) which is easy to upgrade (so that you don't have to keep supporting old versions). SOA is the natural way of providing such an API because it is loosely coupled (and thus good for integration) and coarse grained (and thus good for versioning).

[Jeff]

SaaS also supports agile software development much more effectively than what we have been used to, which in itself drives functional component development to enable the small parts loosely connected model.

[Kip Watters]

For the most part, I agree with your concerns and perception of software as a service changing the Enterprise software delivery/license model and being here to stay. Two points come to mind:

As for the possibility of a customer simply "canceling a subscription" and using another service, we need to remember that the end user of these services really doesnt know, nor do they care, that the software is being delivered as a service. All they know if that it took a hell of a long time to learn the software in the first place, and once a company overcomes the friction and pushback from users to a new application, it probably doesnt make sense to just "switch out".

Also, in the case of salesforce.com, for example, quite often companies use this service because it is a smart thing to do and a very effective way to organize sales leads, etc. However, the real value lies in the customer relationship which does not necessarily require CRM services to maintain, in which case salesforce.com does not become part of the backplane of their business. When we start talking about SaaS in the context of product catalogs, inventory systems, integration infrastructures, etc. -- there is a substantial non-software, non-subscription-based/license fee switching cost. Service based delivery of software does not change the fundamental economic principles of switching costs and barriers to entry that the software industry has so adeptly built it's market upon.

One other thing to mention -- basing a subscription on a by-the-slice/per function pricing model will not work, in my opinion. Subscriptions will work, usage-based subscriptions will not. Isn't this what AOL tried with internet access, what my former (now out of business) company tried with WS Management/SLA measurement, and what is at the root of why Vonage and other VOIP companies are growing like gangbuster? At the most basic level, it also discourages strong adoption, and ultimate reliance on the services that the software companies depend on.

[Jeff]

Kip,
I was going to include a few comments about Salesforce.com but decided to not get into naming names, especially because I can't help but have a bias considering my position with SAP.

Nonetheless, I think the CRM/SFA space is unique in many respects in that all CRM/SFA applications and users tend to be pretty similar. It's about as close to a generic app as you can get to in the enterprise, and that's also why you are seeing strong uptick for SugarCRM as well... all at the expense of Siebel.

My point is simply that this space is somewhat of an anomoly, but over time it should be expected (and encouraged) to baseline many areas of enterprise applications in order to be multi-tenant hostable. My comments right now reflect today's perspective on market dynamics... so I'm not entirely convinced that Saleforce.com represents a watershed event in the SaaS movement, but no doubt the success they are having fuels the trend.

[Eyal Rosenberg]

I believe SOA will play major roll in the SaaS arena, as enterprise applications are actually set of services implementing enterprise’s business processes. The shift, or I can say the upgrade, to SOA will enable SaaS vendors add value and improve the existing business processes in places traditionally preserved to the enterprise application vendors and to tailored customizations.
Moreover, SOA will simplify the integration with existing applications and business processes thus will accelerate time to market of SaaS vendors in the penetration process.
Therefore I think SOA will lead to faster adoption of the SaaS by enterprise customers