Software-as-a-Service (SaaS)
Broadly speaking, SaaS application maturity can be expressed using a model with four distinct levels. Each level is distinguished from the previous one by the addition of one of the three attributes listed above.
Level I: Ad Hoc/Custom (this is a typical ASP hosted model)
The first level of maturity is similar to the traditional application service provider (ASP) model of software delivery, dating back to the 1990s. At this level, each customer has its own customized version of the hosted application, and runs its own instance of the application on the host's servers. Architecturally, software at this maturity level is very similar to traditionally-sold line-of-business software, in that different clients within an organization connect to a single instance running on the server, but that instance is wholly independent of any other instances or processes that the host is running on behalf of its other customers.
Typically, traditional client–server applications can be moved to a SaaS model at the first level of maturity, with relatively little development effort, and without re-architecting the entire system from the ground up. Although this level offers few of the benefits of a fully mature SaaS solution, it does allow vendors to reduce costs by consolidating server hardware and administration.
Level II: Configurable (this is a typical on demand model)
At the second level of maturity, the vendor hosts a separate instance of the application for each customer (or tenant). Whereas in the first level each instance is individually customized for the tenant, at this level, all instances use the same code implementation, and the vendor meets customers' needs by providing detailed configuration options that allow the customer to change how the application looks and behaves to its users. Despite being identical to one another at the code level, each instance remains wholly isolated from all the others.
Moving to a single code base for all of a vendor's customers greatly reduces a SaaS application's service requirements, because any changes made to the code base can be easily provided to all of the vendor's customers at once, thereby eliminating the need to upgrade or slipstream individual customized instances. However, repositioning a traditional application as SaaS at the second maturity level can require significantly more re-architecting than at the first level, if the application has been designed for individual customization rather than configuration metadata.
Similarly to the first maturity level, the second level requires that the vendor provide sufficient hardware and storage to support a potentially large number of application instances running concurrently.
Level III: Configurable, Multi-Tenant Architecture (this is the 1st generation SaaS model)
At the third level of maturity, the vendor runs a single instance that serves every customer, with configurable metadata providing a unique user experience and feature set for each one. Authorization and security policies ensure that each customer's data is kept separate from that of other customers; and, from the end user's perspective, there is no indication that the application instance is being shared among multiple tenants.
This approach eliminates the need to provide server space for as many instances as the vendor has customers, allowing for much more efficient use of computing resources than the second level, which translates directly to lower costs. A significant disadvantage of this approach is that the scalability of the application is limited. Unless partitioning is used to manage database performance, the application can be scaled only by moving it to a more powerful server (scaling up), until diminishing returns make it impossible to add more power cost-effectively.
Level IV: Scalable, Configurable, Multi-Tenant Architecture (this is a highly scalable, mature SaaS model)
At the fourth and final level of maturity, the vendor hosts multiple customers on a load-balanced farm of identical instances, with each customer's data kept separate, and with configurable metadata providing a unique user experience and feature set for each customer. A SaaS system is scalable to an arbitrarily large number of customers, because the number of servers and instances on the back end can be increased or decreased as necessary to match demand, without requiring additional re-architecting of the application, and changes or fixes can be rolled out to thousands of tenants as easily as a single tenant.
Authors:
Frederick Chong and Gianpaolo Carraro
Microsoft Corporation
read it here at:
http://msdn2.microsoft.com/en-us/architecture/aa479069.aspx
April 2006
Posts
Make sure your product is built on a next-generation architecture (using .NET 2.0 and 
Get a system’ designed so that workflow, forms and processes can be configured to meet the needs of your individual group, business unit, department, or country – or simply, by organizational unit
capabilities, making the best use of content acceleration technology to move the most frequent content out to the edges of the Internet to service global locations. Having access to multiple languages (with more coming) and global date and currency formats allows for a decentralized and extensible environment.
decentralize capabilities to configure their process, workflow and forms. Centralized control can be managed through the use of role-based permission groups. These tools provide the flexibility needed to manage organizations with 10's of thousands of users.
A single user-friendly interface should be as easy and intuitive to navigate as today’s consumer web sites. Having a unique roles-based user experience for executives, managers, employees, and administrators will allow for a single integrated portal, building engagement and adoption, no matter how few or how many modules have been rolled out
