Journey from single tenant model to multi tenant model

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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