Think out of the box while thinking of SaaS - Part2
In the earlier blog (Part-1), we had discussed the benefits of the SaaS model from both the customers (consumers) and from ISVs viewpoints. There are quite a few successful SaaS model based solutions from various vendors, of which Salesforce.com is a leading example. But, it is also evident that a number of failures in ISVs/Hosted companies occur due to the inability to handle the necessary aspects of scalability, configurability, integration etc which result in huge implementation and operational cost. In this blog post, I will touch upon ‘Multi-Tenancy’ – a key architectural consideration in a SaaS solution – and cover various consideration points, technologies available and best practices .
Multi-tenancy at Data layer:Multi-tenancy is a unique requirements imposed when considering a SaaS solution. Multi-tenancy is a mechanism to provide tenant specific views and features which enable customers to configure the SaaS solution as per tenant needs using a shared hosting data center and software. There will be need of multi-tenancy at different levels such as UI (User Interface), Business Layer and Data Layer.
Multi-tenancy at different layers of an application
Data layer – Segregating data of different tenants and runtime collection of data based on the tenant context
Business layer – Rules/logic segregation at the business logic layer - Creation of a pool of tenant independent services which can be easily aggregated to serve any client
Presentation layer – Need to support teneant specific looks and feel and validation etc
In the Data layer the important consideration points include Economic considerations, Security considerations, Tenant considerations, Regulatory considerations and any localized/region specific considerations. Once analysis is performed with respect to these considerations, one can check on the different options available at the database level for implementing SaaS solutions such as separate DB for each tenant, separate schema for each tenant or Shared schema (which is the top maturity level). The right approach to choose the DB options has to be selected after thorough analysis of various consideration points such as time to market, marketing requirements such as number of customers expected and level of variations required from each tenant etc.
Achieving Multi-tenancy with configurability at Application Layer
Configurability is very critical for a SaaS solution as there is no opportunity for customization at the UI layer (because of varying data fields or workflow) or at business services layer to support varying tenant-specific business rules. To handle this, it is important to segregate areas of the solution which involve static components from those that involve dynamic components (what I meant by components here is nothing but implementation of business services/needs in an applications).
Important points of consideration in the UI layer include tenant specific looks and feel, navigation changes as required, data validation changes, globalization support etc. Similarly consideration points for the Business layer include varying business rules, varying processing of data/flow as per region or locations etc.
It is important to leverage the right design patterns and techniques available to achieve configurability and flexibility at UI and Business logic layer. Some of the options available to achieve configurability at UI level include adaptive UI rendering, metadata driven UI rendering etc. These concepts can be extended to the business logic layer implementation also through these configurable metadata properties from external metadata XML (metadata xml is the one which contains all properties related to application properties to handle customer specific customizations).
Reporting and other supporting features:In addition to the areas mentioned above (considerations in the UI, App layer and Data layer), another important area is with regard to providing the flexibility to get tenant specific reports (one option to achieve this could be by using various templates on considering different consideration points). It is also important to consider how to provide flexibility in other NFR related features such as archival, data retention period etc.. There are chances that non consideration of the points discussed here might lead into customization which is not expected in a SaaS solution.
We shall discuss on other architectural areas such as integration challenges, scalability and security in the next blog.
