Architecting SaaS Applications
Designing any kind of project is never easy and defining an architecture for SaaS applications is even more difficult. Architects have to make a major shift in their thinking before starting to design SaaS applications.

For designing an SaaS application architecture, architects have to design software that meets each customer's business needs as well as the SaaS model requirements. SaaS applications are a bit different from traditional applications as to:(See Figure 3)

1.  Location: SaaS applications are hosted at an SaaS provider's location whereas in the SaaP model the software is installed in the customer's IT environment.
2.  Licensing: An SaaS application is based on a subscription or metered model (use-based, say, the number of transactions), whereas in SaaP it's a one-time license model.
3.  Management: SaaS providers manage all the tasks and activities not transparent to customer and service level agreements (SLAs) govern the quality, availability, and support commitments that the provider makes to the subscriber, while in SaaP organizations the customer's own IT department is responsible for managing all tasks.

So "pure SaaS" applications religiously follow and comply with the three aspects above. In traditional software development as a product we target one customer for each license and these customers can have 'n' number of users.(See Figure 4)

While defining the architecture of SaaS application we always have to consider the requirement of all the stakeholders and each of these stakeholders has his own unique architectural requirements. For instance:

1.  Delivery architecture requirements - SaaS hosters looking for an architecture that meets their delivery requirement, i.e., a secured multi-tenant architecture where one common code/single installation will be able to handle more than one customer.

2.  Application architecture requirements - SaaS aggregators and ISV are looking for applications that are scalable, configurable, extensible, open-ended, loosely coupled, secure and support multiple environments.

3.  Consumption architecture requirements - SaaS customers (like, say, SMEs) are looking for architectures where they can save money, upgrade easily to new systems, integrate with new systems, customize business rules and the UI as they need using applications that can be accessed globally.

4.  Usability architecture requirements - SaaS end users are looking for a fast response time, ease of use, personalized information, etc.

An SaaS application's maturity can be expressed using a model at four distinct levels(See Figure 5)

A.  Level 1 (ASP model) - Ad hoc: At this level each customer/tenant has its own customized version of an application up and running on host servers. Most of current Web applications are at this level and if they're not then they can be ported with little or no effort.

B.  Level 2 - Configurable: At this level, each customer/tenant's separate instance of an application is hosted. That means the same code implementation is used for all customers. Applications provide many configuration settings so the applications' UI and behavior can be customized according to a customer's requirements without making changes in the code.

C.  Level 3 - Configurable and Multi-tenant: At this level, all customers share the same instance of an application and with the help of configuration settings the application's behavior and UI changes for every customer at runtime. It's important that security be well defined and implemented to keep each customer's data separate.

D.  Level 4 (Pure SaaS) - Configurable, Scalable and Multi-tenant: At this level multiple instances of the same application are up and running. Load balancing infrastructure decides at runtime which instance is used by which customer. Here one customer can be served from more than one instances of the application or one instance can serve many customers.

SaaS customers want to customize the application services they subscribe to and the challenge is we have to build an SaaS application to meet their expectations. We have to ensure that the task of customizing applications is simple and easy for the customers, yet at the same time not incur extra manual development or operation costs for each customization.

In addition to domain features a pure SaaS application should also support the

1. Ability to create custom business workflows and customize the existing ones.
2. Ability to define new business documents and customize existing ones
3. Ability to define new custom business entities and rules and customize existing ones - the idea is that we should either use rules engines or a mechanism to define the rules outside the code file like in database or XML files so they're not hard-coded and can be easily modified if required.
4. Ability to define custom validation rules and customize existing ones - the idea is that the application should have some validation frameworks so every customer can build custom validation rules to fit his requirements with ease apart from OOTB standard validation rules.
5. Ability to define custom reports and customize existing ones - every customer has his own requirements for reports for analysis besides standard domain-specific reports. So the application should provide this facility; it could be provided either by building some in-house reporting feature or integrating with DW or reporting tools like Cognos/Crystal Reports.
6. Ability to add new features and customize existing ones with minimal manual effort.
7. Ability to customize the UI, i.e., customizing brands, logos, look and feel and navigational flows.
8. Ability to integrate and exchange data with external systems easily.
9. Ability to support disparate clients (Web, wap, imode).
10. Support SEO features (like Search Engine Friendly metatags, etc).