Journey from Single Tenant Model

to Multi-Tenant Model

www.techcello.com

Single Tenant Model – The Honey Trap• It’s quite common for ISVs moving from an on-

premise model to a SaaS model to take the route of Single tenant/hosted model.

• After 10-15 customers is when they start realizing the pain of maintaining a single tenant model both from cost and effort as well as from a quality perspective.

• When they make an attempt to move towards a multi-tenant model, they are stuck with more strategic decisions than technical decisions.

• The foremost roadblock towards the move is – Multiple versions for different customers.

• Single tenancy, which once allowed them to customize anything and everything for a customer, will be the biggest business disadvantage for growth.

• Imagine the difficulty of maintaining specs, test cases, upgrade plans, technical documentation for all these versions and the effort required for it. Hence, many of these processes are diluted, which leads to onerous confusions and quality defects.

www.techcello.com

Identify Your Product Challenges

Identify the core product

Identify Variations From Core Product

Identify Data Level Changes

Identify Workflow Related Changes

Identify Integration Related Changes

Identify Additional Reports

Identify Additional Features

www.techcello.com

Identify The Core Product

• The first task is for the product management team to identify the right features they want to call as “Core”.

• Core is the product that can be marketed to 90+% of the customers without many changes.

• This can be easily done by drawing a feature map sheet with the following details,• Feature• Business value• Selling Value• Number of customers who are actively using it

Identify The Core Product

www.techcello.com

Identify Variations From Core Product

• Once you identify your core product the next step is to find out the variations in these features and additional features that you have supported for other customers.

• It is very important to understand the kinds/types of variations and level of complexity it is going to introduce when you want to merge and support all these variations into a single code base.

• The variations can be categorized as one of the following items.

Identify Variations From Core Product

www.techcello.com

Identify View Level Changes

• Label level text changes in the view - Customers can demand different label texts for fields in order to be consistent with their nomenclature. For example in an employee management system- one customer could call an employee identifier an “Employee number” while another customer could call it “ID number”

• Simple validation changes - Customers can demand different validation requirements for the fields. For example, one customer might require the employee number in certain format and the other customer might need in a different format

• Field visibility - The number of fields required by one customer might vary from other customer. For example, in an employee management system some customers need Passport details and some would not want to show the field.

Identify View Level Changes

www.techcello.com

Identify Data Level Changes

• Additional information fields - Customers might need additional fields to be captured than what is offered in the product and the kind of fields can vary from customer to customer. For example in a loan processing system, the kind of information fields that the system has to capture could completely vary from one lending organization to another.

• Data level validations - Some customers might need different validation logic across fields. In the same example above one lending organization could need different validation logic for the fields from another.

Identify Data Level Changes

www.techcello.com

Identify Workflow and Integration Changes

• Business process level changes - Manual workflow could be different based on the customer. For example, in a SCM order processing workflow could be different between customers

Identify Workflow Changes

• On premise integration - Some customers might require their on-premise systems to be integrated at certain scenarios while others might have a different scenario for integration

Identify Integration Changes

• Ad-hoc Reports - Some customers might demand additional reports on top of the pre-canned reports for viewing and export purposes. These report needs could be completely different between one customer to another

Identify Additional Reports

www.techcello.com

Identify Additional Features

• Additional informational screens - Some customers might require additional screens to capture information for ad-hoc use cases. For example, in an employee management system one customer might want to capture training related details of an employee other than what is offered in the product and another might want to capture vehicle details of the employee.

• Changes in existing features - Customers can demand completely different navigations, business logic within existing features.

Identify Additional Features

www.techcello.com

Technical Design Approach

• Once you identify and categorize the variations, the next step is to see if at all these variations can be accomplished via a single code base.

• The good news is 99% of these variations can be achieved with a single code base by building a proper configuration framework.

• A configuration framework mostly comprises of,• Field Metadata system• Data Metadata System• Configurable workflows• Configurable Web Hooks• Configurable Reports

www.techcello.com

Technical Design Approach

• Even with a solid configuration framework, products may still demand (to meet the 1% variation) different coding level implementation to address the customer variations.

• To achieve this instead of maintaining different code bases it is advisable to adopt configurable tenant based code extensions where the extensions get executed at the right scenarios for the respective customer.

• The architecture of your core product would look something like the following.

www.techcello.com

Typical Multi-Tenant Architecture

www.techcello.com

TechCello – For SaaS Migration

• Once the technical approach is arrived, ISVs can be assured of the move towards Multi Tenancy and start their migration.

• For more details on SaaS Migration Strategies, please download the following whitepaper “SaaS Migration Strategy”

http://resources.techcello.com/Whitepaper-SaaS-Migration

• TechCello's SaaS development framework inherently builds configurability to your SaaS application via which all the variations we discussed earlier can be easily addressed.

www.techcello.com

About TechCello

Techcello is a cloud-ready, SaaS Application Development Framework

Can be used to,

Build new SaaS products

Convert single-tenant Apps to Multi-Tenant

Migrate on premise products to SaaS model

Cello framework is delivered as a set of libraries and APIs that can be easily integrated to your product

Applications built using Cello can be deployed in any cloud

Cello contains building blocks for developing, monetizing and servicing your SaaS offering.

www.techcello.com

TechCello – Flexible ArchitectureTechCello supports all models of database multi-tenancy, there by allowing ISVs to operate in a hybrid model.

TechCello offers an end to end SaaS Life Cycle Management Solution that can help in designing, developing and managing the operations of your SaaS product.

Using TechCello you can simply focus on building your product functionalities, and TechCello can take care of the rest.

TechCello is tested and proven SaaS Framework, built exclusively to meet the typical SaaS needs of your business and product.

TechCello offers more than 30+ modules covering all the basic engineering blocks and operational modules.

Apart from saving significant amount of cost, your precious time can be well spent on differentiating your product from competitors through unique product features.

www.techcello.com

Contact Us

http://www.techcello.com

sales@techcello.com