Monday, June 16, 2014

Architectural Considerations for Multi-Tenancy – Part 2


In the first part of this series I listed a set of questions to understand the architectural requirements when you want to enable multi-tenancy.  In this final part of this series, I have included three broad areas of architecture that influence multi-tenancy.
 
Data Architecture:    An ultimate approach to define data architecture is by considering a shared schema. In this approach, you store the data of all tenants in a single schema by including an identifier or column such as Tenant_ID to identify data sets corresponding to tenants.    Another approach is to have a schema per tenant.  This helps when you have to deal with large volume of data per client.  There is yet another approach – a simple and fundamental approach.  That is about having separate databases per client. Every approach comes with some pros and cons.
 
Code Base:  Can you afford to have the same code base for all tenants and maximize sharing so that you allow some percentage of code that is unique to each client?  Or do you want to keep the code bases separate and have them run on separate instances of the application server?  Which is right for you? It depends on the needs of your application and tenants.
 
Implementation View:  How is your application going to be deployed in production?  Is there a need to share instances? Or do you need to have an instance per tenant?  What are the run-time requirements? This is another broad area that is going to influence your architecture and design.
 
This makes it clear that the multi-tenancy needs of your application or product is going to determine how you are going to implement multi-tenancy.  There are different multi-tenant systems running in production across organizations. Their architectures and designs are different and they offer different degrees of multi-tenancy.  When you want to define an architecture and design multi-tenancy you need to look at these broad areas and ask questions – I had shared those in the first part of this series, and make your decisions.  When you do this, I am sure you will come up with a meaningful architecture.
 
Have you come across any difficulties or challenges in doing this? Let us discuss.

References:
  1. Multi-Tenant Data Architecture
  2. Introduction to Multi-Tenant Architecture
 

2 comments:

Manikandan Lakshminarayaan said...

Hi Raja,

A very thoughtful, informative article. I do have experience in do a pilot for SaaS enabling a Legacy J2E Hospital Information Application.

As part of SaaS enablement, apart from what ever you have listed in your part-1 series, I believe a comphrensive business case is required, in case if you know the cost of ownership for the legacy application, it will be easy to see the TCO difference between a software license model and a service based pay-per-use model

One more point, is to have your sales team concurrence on how are they going to position or segment this product since the current existing business for the legacy application can be big so you don't want to position your new "on demand" service as a direct competition to your exisiting licensing product. So your "as a Service" model can start with minimum viable features and customers may need to buy full fledged software for getting a bigger feature list.

Raja Bavani said...

Thanks Manikandan, These are two good additions to the list shared in part-1 of this post. Thanks for sharing! Appreciate it.