Todd Biske: Outside the Box

I recently listened to a Churchill Club podcast from ZDNet which was a recording of a debate between Marc Benioff, CEO of Salesforce.com, and SAP Chairman Hasso Plattner. Besides being very entertaining and a great example of the cultural differences of the two executives involved, the podcast was also a good discussion around Service Management.

One of the things that came across to me throughout the discussion is that there’s a fundamental difference between what I’ll term Software in the Cloud and Software as a Service. Marc took a few jabs at Hans in discussing traditional enterprise software in talking about how the installation CDs show up in the mail, and the customer is left to install, customize, maintain, etc. until the next version is released and the vendor comes back and asks for more money. A bit extreme, but it served to illustrate his point. Take the money portion out of it, because there’s no such thing as a free upgrade. If you’re paying subscription fees, you’re paying for upgrades. Anyway, I began thinking about this whole space and asking the question, “Where’s the service?” Clearly, by having someone else host the application, there are efforts associated with maintaining the system that go away. But is this a service?

To me, the difference is service management. As I’ve emphasized in past blogs, putting an interface and an associated endpoint behind it may make you a service provider in the technical sense, but I don’t think it makes you a good service provider. Being a good service provider requires bi-directional communication between the provider and the consumer on how the service is being used, new capabilities desired, new capabilities coming, etc. Therefore, in the case of Software in the Cloud, there’s just as much risk of just being a faceless entity as there is in traditional enterprise software. I take your subscription fees happily, but that’s it. I am now at your mercy for the future of that system. To provide Software as a Service, the relationship needs to go beyond just providing logins and a URL. I’m sure there are many things placed in contracts to try to better define “the service,” but in reality, service is a differentiator. Look at any industry and you’ll see that there’s a relationship between cost and service. In general, for a given capability, you can provide it at low cost, but usually with relatively poor service, or you can provide it at a higher cost, with typically better service. The challenge is that the larger you become, the greater the challenge there is to provide consistent service. You can differentiate by cost levels, as many software companies (web-based or not) do, but then you’re at risk of damaging your ability to associate great service with your brand. I don’t know if Salesforce.com does this or not, but if they do, are they at risk of taking criticism on the whole “as a Service” because their lower-paying customers are seeing them as a faceless entity? In general, I’ve found that companies are either perceived as providing great support or providing lousy support, and it has very little corrolation to how much money you’ve spent. Just because I’ve only paid for 9×5 support instead of 24×7 doesn’t typically change how the person answering the phone or the sales staff treats me.

So, the gist of this post is a simple message. If you’re going to call yourself a service provider, simply sticking something in the cloud, in the service repository, etc. is not enough. You need to define what your service is, and make sure everything you do is valuable from not your point of view, but the view of your consumers, the ones to whom you are providing the service.

2 Responses to “Software in the Cloud versus Software as a Service”