The document discusses software multitenancy and the Force.com platform. Some key points: - Software multitenancy refers to a software architecture where a single instance of software runs on a server and serves multiple tenants, who are groups of users that share access privileges. - Force.com is a cloud application development platform that powers many popular Salesforce applications. It uses a multitenant architecture. - Advantages of multitenancy include improved scalability, performance, service/support, and easier upgrades since everything is centralized. - The main steps to achieve multitenancy typically involve adding tenant IDs to core business data tables, grouping existing company data by tenant, setting up partitions if needed

1. Presented By –MANIK SINGH

2. What is it ?
 The term "software multitenancy" refers to a
software architecture in which a single instance
of software runs on a server and serves multiple
tenants. A tenantis a group of users who share a
common access with specific privileges to the
software instance.

3. Platform – force.com
 Force.com is the proven cloud application development platform
that powers many popular salesforce.com cloud
applications (Sales Cloud, Service Cloud, etc.), as well as custom
applications that customers build to satisfy their specific business
requirements. The following sections provide you with an overview
of key aspects of the platform’s design.

4. Advantages
 Scalability- A multi-tenant infrastructure makes it easy to increase capacity
when more horsepower is required. When adding new hardware to the platform, the total
capacity of the entire environment increases, becoming more scalable for not just a single
customer, but for our entire client base
 Performance- The nature of a multi-tenant architecture makes it easier
(as compared to a single tenant environment) to maximize the performance of the different
elements in the technology stack, so optimum speed and reliability can be ensured at all
times.
 Service- Having to monitor and administer just one platform (instead
of managing different sets of technology stacks for each client), a multi-tenant SaaS
provider can deliver more efficient and effective service and support, including
troubleshooting and problem resolution.
 Upgrades- Upgrading the software version or elements in the
technology stack (such as databases, servers, and the operating system) is
easier since there is a single, centralized place to go to make adjustments,
install patches, etc.

5. Disadvantages
Something that influences the time before this point is reached, is the database
implementation of the application
 Independent database, independent database instances (IDII)-
Clearly, IDII is not a real multi-tenant database approach. However, it is one that is quite
often used as it is very easy to implement. The obvious downside of this approach is that it
is very heavy on resources
 Independent tables, shared database instances (ITSI)- ITSI is a semi-
multi-tenant solution, in which all clients use the same database, but each have their own
tables. This approach suffers from the same problem as IDII, however it does take longer
before the limits are reached, as a table instance requires less memory than a database
instance.
 Shared tables, shared database instances (STSI)- The problem with
the STSI approach can be described as an isolation problem. Because application
and database are shared, it is important that tenants are isolated from each other
regarding security, customization performance, etc.

6. The steps required to achieve multi-
tenancy
Based on my experience in working with creation / Migration of Apps to be
multi-tenant aware, the following are the typically followed steps. We can
consider the conversion of an CRM [Customer Modules]
Database Changes
 Add tenant id for each core business data tables [Customer, Tickets, Support,
Contacts etc..]
 group existing company data into different customers, this is a bit painful task,
but can be done by mapping your existing customers as tenant's and then
doing the corresponding tenantid updates in the core tables.
 Partitions, if required like tenant1 may belong to partition 1 [USA] and some
other tenants in Singapore may be put in a partition in Asia, are to be setup
and the data moved
 Custom setting data per customer to be grouped as tenant's custom settings
and stored in your core metadata database. This also includes the white
labeling stuff too.
 Customer specific custom fields or extended data should be stored in a
database with the appropriate tenant id values

7. THANK YOU