Journey from Single Tenant to Multi Tenant Model

1. Journey from Single Tenant Model to Multi-Tenant Model

2. 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

3. Identify Your Product Challenges www.techcello.com

4. 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 www.techcello.com

5. 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. www.techcello.com

6. 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. www.techcello.com

7. 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. www.techcello.com

8. 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 • 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 • 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 www.techcello.com

9. 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. www.techcello.com

10. 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

11. 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

12. Typical Multi-Tenant Architecture www.techcello.com

13. 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'sSaaS development framework inherently builds configurability to your SaaS application via which all the variations we discussed earlier can be easily addressed. www.techcello.com

14. 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

15. TechCello – Flexible Architecture TechCello 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. 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. Using TechCello you can simply focus on building your product functionalities, and TechCello can take care of the rest. 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

16. Contact Us http://www.techcello.com sales@techcello.com www.techcello.com