SaaS Tenancy Considerations

Topic Statement

Large, decentralized organizations such as Harvard have many sub-organizations that may have similar or different business processes. Often Harvard and its affiliates must decide whether to purchase a single or multiple SaaS subscriptions for a particular product to meet the needs of its various groups. This guide identifies a set of criteria to consider in the decision process.

Executive Summary

From a vendor perspective, there are two primary architectural designs for software-as-a-service (SaaS) applications; single tenant and multi-tenant¹. In the single-tenant design each customer has an independent application instance. In a multi-tenant design, a single large application instance supports many different customers. Data is kept separate using various application and database level restrictions. Multi-tenant design is the most in common Software-as-a-Service offerings.

Regardless of how the vendor has chosen to design their SaaS solution, customers must decide whether to use a single subscription for the entire organization or to purchase multiple subscriptions for different groups of users. This decision will have implications for user experience, reporting, data sharing and cost should be carefully evaluated prior to finalizing a SaaS contract.

This document provides a series of guidelines for determining whether a SaaS solution should be established with a single shared subscription or multiple subscriptions. Every situation is different, and may lead to different approaches than outlined here, but this document lists the critical questions one must ask in making that determination. The table in section 4 provides a summary for reference.

Discussion

Having selected a SaaS product, customers must decide whether to share one subscription across the enterprise or to purchase individual subscriptions per organization. At a minimum, assess the following areas in making this decision:

1. Organizational alignment

   1. Consider whether or not the two sub-organizations should be viewed as distinct with respect to the processes that will be enabled by the SaaS application. Criteria include:

      • degree of process specialization
      • organizational ability to adjust business processes and requirements

      An application that supports more general business processes may lead to the decision that one subscription is appropriate for multiple parts of an organization. A good example is Office365. An application that supports more specialized processes may be more difficult to share across multiple groups, a good example is a student admissions application which may need to be configured differently based on student level and academic concentration².

      An equally important factor in considering organizational alignment is each group's ability and willingness to consider business process design changes. Differing legal, compliance or institutional requirements may limit opportunities for sharing a single subscription. Groups considering SaaS subscription sharing should discuss their individual needs and constraints prior to moving ahead with a shared SaaS subscription.

2. Business data requirements

   Data management requirements are an important consideration. Do the two organizations have requirements to:

   • Use common reference data?
   • Have similar data models?
   • Share or consolidate data from their business activities?
   • Report across multiple groups?

   A 'Yes' to these questions would support sharing a subscription because both organizations can leverage similar data import/export, data access and reporting capabilities.

   A 'No' to these questions should not immediately preclude sharing, but makes it less desirable because data import, export, and reporting must be configured separately.

3. Business process requirements

   Beyond generally similar business processes, more detailed business needs and requirements should be reviewed.

   Do the two organizations have:

   • Similar specific business requirements?
   • Similar role, authorization, and security models?

   A 'Yes' to these questions would support sharing a subscription because the business model similarity allows simpler application configuration to accommodate both organizations.

   A 'No' to these questions should not immediately preclude sharing but makes it less desirable because business model complexity is introduced into one configured tenancy.

4. Explicit sub-tenant support in the application?

   SaaS application designs and feature sets vary in their ability to support different groups and processes concurrently. Vendors may use terms such as 'sub-tenant' or 'sub-account' but the essential idea is the ability to logically segregate design, configuration, and customization for distinct business units or groups within a single environment.

   • Does the application have the explicit ability to support multiple sub-groups within one tenant instance? Absent specific sub-group support, does the application provide other ways to support multiple business process concurrently?

   A 'Yes' to this question would encourage sharing a subscription because the application has been designed to accommodate multiple organizations in one instance, using sub-tenant architectural features.

   A 'No' to this question should not immediately preclude sharing but makes it less desirable because application is not natively designed to support multiple sub-tenants in one configured tenancy.

5. Cost Implications

   SaaS costs vary based on the vendor's pricing model, subscription terms and negotiated agreements. Common pricing models include those listed below, individually or in combination.

   • Per user
   • Per business unit
   • Tiered
   • Feature based
   • Usage based

   Vendor pricing documentation is sometimes less than fully transparent and may include 'hidden' costs. Volume discounts may or may not exist and may vary in a complex manner. Given the variations in pricing, a financial analysis is required on a case-by-case basis. Cost savings cannot be automatically assumed for sharing subscriptions.

   Cost savings related to sharing subscriptions can come from several sources:

   • Reuse of one application configuration design by multiple organizations
   • Ability to use one user license across multiple subscriptions of a single SaaS product
   • Shared local administrative or technical support
   • Sharing of recurring costs that are not usage based, such as monthly base fees³

   Costs may result from:

   • Additional operating costs related to more complex application administration, data management, and user support tasks
   • Inability to take advantage of license cost inflection points for tiered subscription models

   A favorable assessment of these questions would encourage sharing a subscription because the cost savings may be possible.

   An unfavorable assessment of these questions should not immediately preclude sharing but makes it less desirable because cost savings are not compelling, or the additional complexity of shared tenancy results in increased operating cost.

Summary

The following table provide a summary of the above considerations and criteria.

Recommendations

Use the criteria above to inform single/multiple SaaS subscription decisions. Balance any short-term cost savings with the potential for additional long-term costs related to the complexity of configuration management, reporting and data sharing. Specific vendor support for sub or child tenants is an important consideration.

Consider revisiting this evaluation, including the financial analysis, on a repeating basis. SaaS vendors continuously revise feature sets and modify their cost models. Product and pricing changes may lead to different conclusions.

Definitions

Multi-Tenant - A SaaS application in which different unrelated customers share a single application instance.

Single-Tenant - A SaaS application in which each customer has a separate application instance, possibly running on dedicated infrastructure.

Subscription - Monthly or annual fee for use of a centrally hosted software application.

Shared Multi-Tenant, Multi-Tenant with Sub-Tenant support, Multi-Tenant with Child Instances - A Multi-Tenant SaaS application in which one tenant is intended to be shared by distinct parts of the same organization. The specific level of support for sharing will vary.

Footnotes

¹ The term 'multi-tenant' can be interpreted differently based on the vendor/customer perspective. Because SaaS products are generally priced using a subscription model, in this document we take a customer centric approach and define 'subscription' and 'single tenant' as generally synonymous. Also note that vendors may define terms differently. Microsoft, for example, defines 'tenant' as 'the regional location that houses the servers providing cloud services.'

² In such cases, application flexibility is very important. See Section 3.4

³ Base fees are uncommon