SaaS vs. Software: The Release Cycle for SaaS Is Usually (Not Always) Faster

This is the first in a series of posts I plan to write comparing and contrasting the strengths of SaaS and software. Many people view SaaS as just software running on a web server. While true, that’s a viewpoint that misses the nuances of SaaS–and its the nuances that make all the difference.

SaaS vendors often pitch that SaaS has a much faster release cycle than software. Rather than having to wait three or four years for a functionality refresh (as is the case with some major software packages), enterprises can get new functionality every couple of weeks. This is true. However, once in the hands of the marketing people at SaaS evangelists (e.g. Google and Salesforce), the pitch takes on the tone of, “We’ve reinvented the laws of physics.” It’s along the lines of, “Unlike the laggards at IBM, Microsoft, and SAP, who take forever to code and release product, we get stuff out fast.” What I have an issue with is the implication that SaaS release cycles are always faster than software release cycles. Sometimes they’re just as long.

To understand the subtlety here, you have to step back and think through the software release process. First you spec a change; you code it; you QA it; and then you release it. The timelines for the first three process steps are pretty much the same for both SaaS and software. While there will be differences based on the development platform and internal processes, the differences won’t be huge.

Where they do differ is in the last step: the release cycle. Here, software uses the “big bus” metaphor: the release is held until every feature is on board,  because generating a software release is a logistics nightmare. The vendor has to generate documentation and packaging for the channel, train both customers and support personnel on the many changes, tweak pricing and perhaps packaging, etc.

SaaS, on the other hand, uses the “small shuttle” metaphor: a new release goes out when one or two features get on board, largely because the logistics are so much simpler. The vendor doesn’t have to adjust the pay-as-you-go pricing, and small number of changes means training is ignored or is at most a little Help text.

Therefore, in the SaaS case, the real controller of when a feature is released is the complexity of the coding. Some features that have a huge business impact can be coded and tested quickly. However, others that are very complex–such as altering the underlying data model–can take years.

Google Apps Premier Edition (GAPE) is a perfect example of that. Initially released in February 2007, the solution has been through many iterations. Some features, such as offline storage of documents, took a little over a year to come out (Google Gears started getting rolled in to GAPE in April 2008); others took two and a half years (e.g., mail delegation arrived in GAPE in August 2009). Note that if Google had said in February 2007 that mail delegation would be coming out in 2.5 years, it would have been perceived as slow as the software companies it goes up against. So it just stayed silent.

So on average, SaaS does offer a faster release cycle than software; it’s just that sometimes there are outliers.