The answer is yes, it's true and this is the only way we can really come up with a pure SaaS application. Now imagine that we have to develop software that can handle 'n' number of customers and each customer has 'n' number of end users and complies with all the requirements mentioned. Some of the things that have to be done at each layer of architecture so we can achieve the desired results are:

1. UI Layer: The UI layer should be highly customizable in terms of look and feel and should support I18N. If the application supports this then the application's UI can be easily configured or customized according to customer requirements. This can be achieved by following some of the approaches below:

   a)  Rendering the entire UI using CSS/XSL and allowing customers to define their own CSS/XSL.
   b)  Providing the ability for customers to do extensions or add their own scripting files/methods. c)  Providing flexibility so the UI can be changed or display additional information like promotions based on external factors such as information provided through URL parameters.
   d)  Loosely coupling the data rendering logic from the business processing logic so the customer or provider can change the placement of the forms/data rendered on UI. Easypage is a good example.
   e)  Using an XSLT approach can add further value in providing disparate client support.
   f)  Furthermore it would be good if the application provides the flexibility to map the UI by locales, branding, etc.
   g)  Personalization support (both implicit and explicit).
   h)  Search Engine Optimization should be supported if possible.
   i)  Provide a rich UI.

2. Integration Layer: The integration layer in SaaS should be such that it allows a system to integrate with third-party systems easily in a standardized way. This can be achieved by:

   a)  Following an interface-based API, JCA approach.
   b)  Allowing support for a messaging system and Web Services.
   c)  Using business orchestration tools and standard integration tools like SeeBeyond and webMethods.

   For data exchange it's always advisable to follow standard formats like industry standard XML structures or EDI instead of proprietary ones.

3. Data Access Layer: A pure SaaS application is designed in such a way that it is easy to support different data sources, for example, databases or files or third-party systems based on requirements. Keeping this in mind:

   a)  It's advisable to use OR mapping techniques like Hibernate and JDO.
   b)  Create middleware components that allow us to make system data source-independent system.

   As we know the database is the most important part of any application and we should spend a good amount of time defining and analyzing the database architecture. To manage multi-tenant data we have three approaches:(See Figure 6)

   c)  Isolated Database for each customer - This way we create a new database for each customer; it is the easiest, most secure, and costliest approach. In this case maintenance overhead (for example, backup and recovery) is low, reliable, and easy to enhance the database to customer-specific requirements.

   d)  Shared Database and Isolated Schemas - In this approach multiple tenants share the same database, but each customer would have a separate schema. This approach is also easy and provides a facility to make customer-specific changes in the database but it is less secure and not very reliable compared with the isolated database .In this approach maintenance overhead (again backup and recovery, for instance) is high.

   e)  Shared Database and Shared Schemas - This is the cheapest solution in terms of deployment and maintenance. All the customers share the same database and schema, maintaining data for all the tenants in the same set of tables. We have to put extra development effort in to make it secure so that data isn't shared by tenants by mistake.

An SaaS application database should support I18N and design should be extensible enough to provide enhancements easily or change the database to meet customer requirements. Based on the clarity of the requirements, an understanding of the domain requirements now and in the future can achieved by providing additional non-mandatory columns of a generic type in the tables or following a name-value pair approach to define the database structure. Security plays a key part in an SaaS application and one must provide an adequate security mechanism to avoid any unauthorized access to customer data. SaaS applications should provide support for standard SSO and security techniques (like digital signatures, ACL, message encryption, etc.).

On the technology front an SaaS application should be loosely coupled, highly cohesive, and designed to avoid use of proprietary databases and middleware. It should use open source and follow industry standards like XHTML, 508 compliance, XML, AJAX, RSS/ATOM, etc. When defining an SaaS application we should keep Web Services in mind and, if possible, follow a SOA architecture.

The key to developing a good SaaS-based application is the design of the application framework. We have to make sure that the base application framework should be flexible, open-ended, and robust enough so new features can be added to an application easily. This way we can create a customer community that will contribute developed features to our SaaS applications. This has two major benefits:

1. Our SaaS application becomes feature-rich and these new features can be offered to other customers based on a license or terms & conditions of the customers who had it developed.
2. It attracts more new customer to use our application that results in improved revenue figures.