As acronyms go, the ASP (Application Service Provider) has been dying a slow death. But as a distribution model, its ashes have given birth to a more robust concept based on rich interactivity and a more easily updateable codebase: Software as a Service, or SaaS.

Once the ASP model began to mature, it ran into serious obstacles due to the architecture employed by most vendors. The typical ASP vendor instantiated a new app for each client, so that each account had both an independent data store and an independent codebase. This eventually made updates unmanageable and placed unnecessary demands on the vendor's infrastructure.

At the same time, Rich Internet Application (RIA) methodology has evolved to the point where developers can create more fully-featured, highly-responsive Web-based UIs in ever-shorter development cycles. It quickly made sense to apply these new coding techniques to existing products. But more than resurrecting acronyms from the marketing graveyard, this has resuscitated the ASP model and suggested new ways to build distributed applications. The result, SaaS, takes a different approach by opening up a single, easily updateable codebase to a highly scalable number of Web-based clients, or "tenants".

This one-to-many approach allows developers to push updates on a more frequent basis. (Easier to break? Easier to fix? You say to-may-to, I say to-mah-to.) Meanwhile, customers can license the software per user or group of users and not have to worry about installing patches or paying for upgrades. This win-win offers so many advantages over traditional distribution models that Gartner Research estimates the SaaS market will nearly triple, from around $6.5 billion worldwide in 2006 to $19 billion by 2011.

Building a SaaS Architecture
Creating a SaaS, however, involves more than adding a slick front-end to an existing application. While you can certainly extend your core code into a Web-based app, you must take several new criteria into consideration that are unique to a SaaS offering.

Uptime
Your SaaS will be rated on uptime. Your Web server and database should both be able to manage spikes in traffic, including thousands, or even tens of thousands, of connections.

Low-Cost Prototype
Unlike when building a desktop application for production, developers can create SaaS prototypes or early builds that can actually go to production. For the consumer side, sites do this all the time with feature-limited "beta" versions. New SaaS vendors looking to mitigate risk may build a low-cost proof of concept to see how it performs before investing in a full-scale release. If so, you'll need products you can license at reduced cost but without reduced functionality, and that won't lock you into a dead-end upgrade path.

Scalability
Conversely, you also need to plan for growth. Like any Web app, you may strike gold and experience the rush that goes with it. Not only does your server (or farm) need to scale up, your DBA also needs to set a foundation early on that can support rapid growth and increased traffic.

XML Support
As a RIA, your SaaS will love XML. You'll benefit from storing data in a highly portable data format. And you'll benefit even more from the ability to feed your REST, JSON, or Ajax code (or coding style) to manage data, build menus, or enable other client-side functionality.