Can on-premise software vendors have short development cycles?

This week, I was interviewing a software engineer from a traditional enterprise software company. When I asked him why he wanted to become a developer for on-demand solutions, he said that he was tired of 18-24 month development cycles. He liked the notion that on-demand software has much shorter development cycles (usually around four months, not 24 months).

He then asked me why traditional software doesn’t have shorter releases. “The engineers are just as good,” he said. He had asked his VP of engineering the same question, and got some rambling response about how customers wouldn’t trust shorter development cycles, because they’d be concerned that it wouldn’t have the quality level that customers have come to expect from enterprise software. Well, I may not up to date on absolutely everything happening in the high tech industry, but I’m pretty sure that it’s been a long time since anyone praised the quality level of current enterprise software. Pretty much the only thing people have come to expect from releases of enterprise software is that several service packs are sure to follow.

Nonetheless, it’s a good question. Why is it that on-demand offerings can be released several times a year, whereas traditional on-premise software has multi-year release cycles? The answer isn’t that on-premise software takes longer to write than on-demand software — it doesn’t. There is some impact from the fact that on-premise software requires additional testing to ensure that it runs on multiple hardware platforms and different versions of operating systems, whereas on-demand software only needs to run on the single hosting platform chosen by the vendor. But, that doesn’t explain the large difference in release cycles.

The difference isn’t actually caused by the on-premise software vendor at all. It’s caused by the customer. Customers hate upgrading software almost as much as they hate the initial implementation. Imagine going through a long deployment cycle to get an on-premise software solution up and running, and then four months later getting another set of CD’s in the mail with a note saying that it’s now time to upgrade to the next release. There’s no way a customer has the resources (or the patience) to upgrade their on-premise solutions several times a year. Once every 18 months is about the maximum that they’re willing to handle. So, the on-premise software vendor is restricted to release cycles that are at least 18 months long.

There are no such restrictions for on-demand vendors, since the customers aren’t responsible for doing the upgrade — the vendor takes care of that. So, as long as the vendor is willing to go through the upgrade process several times a year, there’s no negative impact on the customer. The customer can just log off the application at the end of the day on a Friday, and when they log back in on the following Monday morning, the new release is already in place.

The ability to deliver smaller, shorter releases is a huge advantage for on-demand vendors, and is something I’ll expand on in a future blog posting.

posted by Ken Rudin at 11:26 pm

---