Note: This updated article features a new section on page two in response to various reader suggestions about coping with rapid-release Web browsers.

Nowhere is the intersection between the consumer world and the enterprise domain more significant than on the Web. In the consumer space, we depend on services like Facebook, Twitter, Gmail, and Amazon; in the corporate world, we have custom line-of-business applications and software-as-a-service (SaaS) applications such as Google Apps and Office 365. The same core set of technologies and infrastructure underpins both, and this creates quite a conundrum for many enterprises. The consumer world favors a policy of rapid releases, which is anathema to business.

Thanks to Web browsers and Web apps, however, corporate IT departments increasingly find themselves forced to adjust to this newer, faster world. So how can businesses respond?

What version number is my Web app?

Traditionally, users and administrators alike have been very much in control of the software that they used. New versions had to be explicitly purchased and installed, typically with intervals of several years between each version. Many businesses came to depend on this release schedule, upgrading their software only infrequently—often choosing to skip every other version—and only performing those upgrades after validating that the software works. Even if a new software version deprecated or removed a feature that a company depended on, that didn't pose an immediate problem; the old version could simply be retained until some solution was devised.

Compare that approach with today's online services, which tend to be in a state of nearly continuous change. A site such as facebook.com has no version number; instead, Facebook rolls out new features and bug fixes whenever it likes. The Web sites we use (usually) just get better, with no effort on the user's part.

For consumer-oriented services, such changes are safe enough. A new set of Facebook features might provoke a spate of sarcastic status messages from those annoyed by them, but they won't create a flurry of support calls from confused users. More importantly, they won't break anybody's mission-critical application.

This approach is more problematic when applied to online business services. Though these do tend to be a bit more conservative in their upgrade procedures, they nonetheless retain a similar rapid approach to upgrading. Smaller, more regular updates are favored over infrequent larger ones, and there's little or no ability to downgrade versions or to defer upgrading for prolonged periods.

One Googler described the evolution of SaaS applications to us as "like watching a child grow up," continuing, "you don’t notice the small changes very much day by day, but if you look back over a few years the progress is remarkable." The company told us that it had delivered more than 130 feature updates to Google Apps in the last year.

This approach undoubtedly delivers useful benefits to customers, but with a cost. If staff are trained on a particular version of a customer relationship management (CRM) system, or an online productivity application, an upgrade that changes the user interface can incur costs for businesses that depend on such services. Procedures may need to be altered, or users may need to be retrained. Worse still, needed features may be altered or removed entirely.

Rapid release on the Web

Part of the promise of SaaS is the reduction, or even elimination, of administrative burden. No longer do companies have to perform extensive software testing, deployments, or server maintenance. They just pay a service provider to take care of all that.

When compared with traditional software development cycles, these service providers often feature rapid release cycles that can be opaque to outsiders. There's often little or no visible indication of which software version has been deployed, and little ability to influence the version. In spite of this, software-as-a-service is a growing industry. Even that largest of traditional software vendors, Microsoft, is investing heavily to establish itself in the SaaS market.

The approaches taken to upgrades and feature roll-outs by SaaS providers vary, both in terms of notice and flexibility. Zoho, which offers an enormous variety of Web-delivered applications including CRM, desktop productivity, bug-tracking, mail, and wikis to more than five million users, provides advance notice prior to any substantial updates, and early access to those updates so that its subscribers can test and validate them. During this period, subscribers can switch between the old and new versions.

Google has a different approach. The company has two tracks for Google Apps: a Rapid Release track and a Scheduled Release track. On the Rapid Release track, features are available as they successfully pass Google's quality assurance processes. This is identical to the approach used for Google's consumer-facing services, and Google Apps users that pick this track have the full consumer experience.

On the Scheduled Release track, new features are announced and delivered only on Tuesdays. Each Tuesday, the company decides if Rapid Release features are ready for the Scheduled track, and if so, it announces them. The following Tuesday they are then rolled out. At least one week must elapse between the Rapid and Scheduled releases, and potentially more if problems are found after the Rapid release. Google Apps customers can switch tracks at any time, but it's an all or nothing proposition; if a small group of users wishes to test the Rapid Release track to get an early look at a scheduled feature, they must do so using a different account. This two-track approach only covers a handful of Google's services: Mail, Calendar, Contacts, Docs, and Sites. Everything else is rapid release only.

Microsoft's approach is different still. The company told us that "major service updates are rolled out to the service as they become available," with no option to delay or defer the upgrade. However, administrators can control the availability of new functionality through the administrative dashboard, which allows some ability to test updates and "prepare their users appropriately" before rolling out new features.

SaaS usage can also feed back into the desktop. None of the companies we spoke to support Internet Explorer 6 any longer. Google was most aggressive about this; since August of this year, the company supports only the two most recent versions of any browser. Not even Internet Explorer 7 is good enough for Google Apps; versions 8 and 9 are the only ones supported. When Internet Explorer 10 is released next year, one side-effect is that any company still using Windows XP will no longer be able to use Internet Explorer to access Google Apps; neither Internet Explorer 9 or 10 will run on Windows XP. Companies wishing to switch to Google Apps to relieve themselves of server maintenance and other chores may unexpectedly find themselves pressured to update their desktops.

Google argues that this approach to browser compatibility allows it to provide the best possible applications. The company told Ars that older browsers "just don’t have the chops to provide the same high-quality experience that a modern browser can," citing features such as offline Gmail as the "perfect example" of the kinds of capabilities that demand up-to-date browsers.

Though each of the providers we spoke to does offer some flexibility to its users, the situation is, unsurprisingly, still very different from that of on-premises software. The ability to use old software for extended periods just doesn't exist in the SaaS world. As more companies choose to use SaaS providers to replace traditional software, a more flexible approach to software versioning is inevitable.