by Guy Creese | May 18, 2010 | Comments Off on 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.
Read Complimentary Relevant Research
Top Strategic Predictions for 2019 and Beyond: Practicality Exists Within Instability
Technology-based change is happening continuously, and most organizations struggle to see the change in advance. Continuous change can...
View Relevant Webinars
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.