Much of the discussion and debate over SaaS enterprise applications focuses on whether the SaaS applications are single- or multi-tenant solutions. For years now survey respondents participating in Mint Jutras Enterprise Solution studies admit they do not understand the difference between the two. While many don’t seem to care (leaving that for others in their company to worry about), many others express interest in learning more. And Mint Jutras has always been happy to comply.
You will find some industry observers that passionately insist SaaS solutions must be multi-tenant in order to be “true SaaS” and some offer quite a long laundry list of conditions that must be met before they will anoint a solution to be what they consider truly multi-tenant. The definitions I have always presented have been much simpler:
- Multi-tenant (or Single-instance) SaaS: Multiple companies use the same instance of (hosted) software. Configuration settings will vary per company and data is protected from access by other companies (tenants).
- Single-tenant (or Multi-instance) SaaS: Each company is given its own instance of the (hosted) software.
While many experts insist on multi-tenancy, this choice has more direct impact on the vendor than the consumer of the software. But that vendor impact can (should?) have a cascading impact on the consumer. Maintaining a single copy of the software instead of a separate instance for each customer means far less cost and effort for the solution provider. These savings can translate to lower cost and/or more innovation for the end user of the software, but multi-tenancy doesn’t come with any guarantees. If vendors offer both multi- and single-tenant options, they may not realize either of these benefits. And even if they do, they may not pass them on to their customers.
Over the years, my research has shown a slight preference for single tenancy. However, many that express this preference only see the limitations they assume multi-tenancy imposes. These limitations may or may not be real. And while the “experts” might be pushing multi-tenancy, is that really the question users should be asking?
Presumably the added efficiency of multi-tenancy allows the solution provider to focus more resources on improving the technology and developing more features and functions, which directly benefits its customers. That translates to more innovation delivered. But if the solution provider makes the same solution available on-premises, the frequency of releases may be constrained by its customers’ ability to upgrade frequently. So perhaps instead of asking whether the solution is multi- or single tenant, the better question is, how frequently is the software updated?
Is there a perceived downside to multi-tenancy? Yes, there can be. Many assume that a multi-tenant environment equates to “plain vanilla” applications that cannot be modified or tailored to their own needs. That may have been the case years ago when customizing software meant modifying source code, but today’s modern technology allows a tremendous amount of configuration and personalization without ever going near source code. So perhaps instead of asking whether the solution is multi- or single tenant, the better question is, what level of configuration, tailoring and personalization is supported?
Another potential concern over multi-tenancy is the perceived loss of control over the upgrade process. Indeed, in a multi-tenant environment, the customer often has little control over the timing of the upgrades. However, is there really a negative impact? If the solution provider bears the burden of the effort associated with upgrading and innovation is delivered in such a way that the customer may optionally choose to take advantage of an enhancement – or not – then there is no down-side and a lot of up-side.
Yes, single tenancy potentially affords you more control over the timing of an upgrade, but there are other ways to exert control. Some vendors will actually support multiple versions in a multi-tenant environment. So perhaps instead of asking whether the solution is multi- or single tenant, the better question is, how is the upgrade process engineered and executed and/or whether all enhancements are designed to be “opt in,” only visible to the users when the customer chooses to turn them on?
These are just some examples of how to ask the right questions to make sure the SaaS solution, whether it is single or multi-tenant, meets your needs.
In evaluating alternative solutions, remember different solution providers use different terminology so it is important to look beyond the labels in order to answer the questions most important to you and determine the real benefits of the different SaaS options.