Tag Archives: Multi-Tenancy

Posted on Fri, Jul 26, 2013 @ 1:17 pm

multitenancygraphic1Outsourced product development firms have been helping software companies for years to build robust, multi-tenant software products, such as SalesForce, that allow each customer to feel they have their own version of the software and data while in fact sharing a common infrastructure much like the tenants of an apartment building. This can allow IT shops to eliminate the replicated environments they might otherwise need to set up to support different large customers and have a single instance of the software with appropriate configuration settings and separated data. Good outsourced product development firms can even take an older software code base and add mutli-tenant capabilities such as the following:

(1) Tenant level data isolation

(2) Tenant level data model extensibility/customization

(3) Tenant level customization of UI themes/look and feel, forms and data capture widgets, notification templates and delivery mechanisms

(4) Tenant level creation and administration of roles and privileges, field level access permissions, data access policies

(5) Tenant level access control settings for modules and features, so that specific modules and features could be enabled /disabled for different tenants

(6) Tenant level business rule and workflow customization

(7) Tenant aware reporting tools

Migrating a single tenant data model to one that supports multiple tenants involves implementing a data architecture that provides the optimal degree of isolation/security of data at the tenant level, typically one of the following three approaches or a combination of these approaches is used to achieve this:

(1) Separate Database (Every tenant gets its own database)

(2) Shared Database, Separate Schema (multiple tenants use the same database but each tenant has its own set of tables grouped under a schema that belongs to that tenant)

(3) Shared Database, Shared Schema (common database and a shared set of tables store multiple tenant data, a tenant ID is used to associate data with a specific tenant)

Each of these approaches have their own distinct set of benefits and trade offs that make them appropriate in some cases and not in others depending on a number of technical and business/economic factors. Some of the criteria that a product development firm (OFS) would evaluate thoroughly before recommending an approach are as follows:

(1) Economics/Cost: More sharing of infrastructure (Shared Database, Shared Schema) between tenants reduces hosting/hardware and operational costs, the models that offer the most isolation cost the most and are least scalable.

(2) Security: The nature of the data that is being secured and the SLAs that have to be supported will determine the security safeguards that the chosen approach has to provide, However opting for the most isolated data model is not a prerequisite for implementing a robust security architecture. A shared data approach will also be able to provide the desired data safety if the appropriate design principles are incorporated.

(3) Tenant Considerations: Number of tenants the application will have to support, data storage requirement per tenant, the number of concurrent users that will have to be supported per tenant, support for data backup and restore on a per tenant basis, and the degree of data model customization and extensibility that tenants would require.

(4) Regulatory Compliance Issues: The regulatory and compliance requirements that tenants would have to satisfy might affect the data storage and data security choices.

(5) Technology Stack/infrastructure: The limitations that the underlying database platform imposes such as the maximum number of schema a database can support, the maximum storage per database etc. will have to be carefully considered.

Regardless of the approach that is chosen to convert a single tenant data model to once that supports multi-tenancy, a product development firm’s (like OFS) resultant model would be Scalable, Extensible, Secure and Efficient.