Sightings in SaaS

Last week we talked about the idea of the SaaS to SaaS integration and how this network phenomenon could not be duplicated by on-premise software vendors where the same integration has to be built over and over again.  Today, we turn our attention to application upgrades and updates, bug fixes, additional new functions, both large and small. Is there an inherent difference between on-premise and SaaS in this area? What is it?

I chose The Big Dig in the title, referring of course to the massive construction project in Downtown Boston, because I think that there are interesting political and social questions that impact the discussion of how to improve software applications. Let me explain.

We now have so many touches of technology everyday that we can quickly forget how important it is to our lives – we can take it for granted. Until it doesn’t work, and then we notice immediately how much we lean on technology for our daily lives. In our greater experience, we have come to expect technology to work and we little patience when it does not. We also expect technology to improve, and we yearn for the next thing. The overall effect is to give more and more choice and power to individual consumers.

This power comes as a cost to those who currently hold power. There is not a lot you can do to manage the message when you have a population walking around with i-Phones or one if its competitors. In this environment what’s the best way to move forward? With massive projects that require highly concentrated bureaucracies? Or with smaller projects each of which offers slightly different choices.

Looking at it in this light, forced on-premise software upgrades look big, complex, incomprehensible and, finally, coercive, whether it comes from SAP, Oracle or Sage. As a counterpoint, look at the upgrade process of SaaS software. Most fixes and upgrades happen incrementally, the average user does not know how the software was improved last night while they slept. On a scheduled basis more important functionality rolls out, but in smaller customer batches, including several beta groups, over a period of time. The whole point is to make the roll out as non-intrusive as possible. The point of the on-premise roll out is to force customers onto the latest release so that the vendor doesn’t have to support more than a few releases at a time.

But why do on-premise customers balk at the upgrade process? Because it is very intrusive. It takes up a ton of time and effort, from the actual software updates to testing and testing and more testing. Remember, on-premise customers do all the work for an upgrade and they receive no benefit from the testing of other users.

No only is traditional, on-premise software intrusive to upgrade, but its upgrade process puts it behind the curve of the latest functionality. For example, take, as Anshu Sharma does, the example of Microsoft, just now releasing Windows 7. I am typing this blog on a notebook running XP, I skipped the Vista experience. That means that I have the functionality that Microsoft released 8 years ago. If I want a few new functions I could buy Windows 7, but then it will also be outdated a year from now. Of course, MS will not release improvements until they have enough of them that they can sell me another version of their operating system a few years hence. 

More and more the big, coercive on-premise software upgrade process looks like the massive, messy projects run by big bureaucracies. But in a world of the I-phone, Twitter and the blogosphere, coercion looks very antiquated.