Software in the Cloud versus Software as a Service

I recently listened to a Churchill Club podcast from ZDNet which was a recording of a debate between Marc Benioff, CEO of, 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 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”

  • How does service management come into play from the perspective of the client/consumer organization, when you do not have the ability to directly manage and monitor the services of the service provider?

  • The easiest way I can think of to illustrate the importance of it is the supply chain. As supply chains that crossed companies evolved, increased visibility was needed by all parties. Likewise, if I’m providing a service and I’m dependent on someone else’s service as part of that capability, over time, I’m going to need increased visibility into their service’s behavior. I shouldn’t need full visibility, but I’ll definitely need more than zero visibility.

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.