The first step in addressing this challenge, is to understand the difference between single and multitenant models. Basically, single tenant means that you have your own dedicated instance of the system hosted in the cloud, while with multitenant you are accessing a global online system that serves many customers simultaneously. Data is usually stored in the same database with measures to separate the different tenants ensuring privacy and security.

Initially, you may think that selection is easy. After all, why would you want to share the system with others? The reality is more complex, and to answer this question, you need to understand what’s under the hood. Software vendors may suffer while operating a single tenant model, and this can negatively impact your business.

Here are some of the items software vendors agonize over while operating a single tenant model:

1.     Upgrades and updates:

Many software vendors claiming to be SaaS providers, will make it your responsibility to upgrade or update your system, and even if they help, upgrading hundreds or thousands of scattered single tenant environments begins to look like a mission impossible. Especially if each customer is on a different version, or have customized their installation in a different way. When the vendor struggles in accomplishing these tasks, this could leave you with many problems to address right after each upgrade, and it could mean you will be waiting on a long queue to have your upgrade executed and your customization issues addressed.

2.     Security:

Some software vendors claim security is the top reason you should consider a single tenant model. They forget how difficult it is to secure thousands of dissimilar scattered instances they have on the cloud; if they manage to track them at all.

A Single Tenant System is not only the software code, but also the underlying infrastructure services that support it (Application/Database/Email Servers, Operating System, etc…). Each service could have its own security issues.

Say if a major security vulnerability is reported by the Application Server software vendor. Your system vendor will not only have to upgrade the App Server version on thousands of instances, but also the platform itself to make it compatible with the new version of the App Server (all at the expense of your timetable). Some vendors will simply ignore the vulnerability because they cannot afford the solution with dire consequences for your business.

3.     Support:

“Could you please help us identify where your system is installed within our cloud?”. Do not panic if you get that question from the Support Rep of your single-tenant provider, it is a very common question in that world. You will get to see Support struggling to help with endless cases resulting from scattered instances, customers on different versions, installs and customizations done in different ways, and the list goes on and on.

4.     Innovation:

Your feeling that your single tenant provider is not innovating in terms of new features or enhancements is not wrong. If 80% to 90% of their R&D resources are busy throughout the year “trying” to contain the mess resulting from the huge number of dissimilar instances they have, then their inability to innovate is understandable.

If you just upgraded the system after waiting in a long queue to find out that the only thing that changed is the version number, and fixes for a few bugs that you didn’t suffer from, then your single tenant provider is just trying to deliver on their promise to provide updates within specified frequency.

5.     Performance & Technology:

You paid for dedicated powerful servers on the cloud; yet your users are suffering from nasty performance issues, their focus is shifted from doing business to waiting for pages to load?

The truth is that most single tenant vendors have old systems developed far before the recent powerful cloud technologies that allow building multitenant systems, ones that can scale to support a huge number of online users. At the time of the cloud boom, these vendors found that the single tenant model is their “easy” path to cloud, and instead of shipping the software to your on-premise server, they now ship it as is, to a server on the cloud (that easy).

These older technologies are limited in what they can do, and vendors that claim to be “Cloud SaaS” providers would always struggle to support your users with the performance they desire.

It is time for you to question technologies used in your Compliance/EQMS platform. Were these technologies invented in the previous century?

6.     Collaboration:

Single tenant providers are always challenged with providing the features you need to interact with external entities. Being on a multitenant online network allows you to interact with other entities (like suppliers, customers or product consumers) without having to introduce “helper” systems to accomplish the mission, nor risking a breach by using solutions that allow these external users into your intranet.

7.     Cost:

It is unfortunate that some single tenant providers will try to sell you a dedicated system as an advantage, and you will find yourself paying for the cloud costs (servers and underlying services), you will also pay for the cost of their struggles to manage the single tenants farm they have. At the end of the day vendors will have to be profitable even if they struggle, and you end-up paying the bill.

Where do you go from here?

After reviewing the items above, and if you made your decision to go with a multitenant provider, there are some additional considerations, to select the right one:

1.     Platform:

“Is the platform owned by the software vendor and was fully developed by them”?

This is a key question to ask, when you are about to select a multitenant vendor for your Compliance/EQMS software. If the vendor does not own it (utilizing a 3rd party), their ability to introduce the feature set you need in the Compliance world will be very limited.

2.     Configurability:

Realizing a configurable multitenant platform is pretty complex, because underlying database services are shared, so most multitenant providers will select to introduce a system that is not configurable or one that offers very limited configurability.

Configurability is key in the compliance world, and you should find a platform that you can leverage to implement your own business scenarios, not the scenarios in the mind of the developer who developed it to be used as is.

Being able to configure with ease is crucial too (No complex coding or scripting, no programmers). If you cannot build your process on your own (requires vendor intervention), then it is not the right platform for you.

3.     Unification:

To provide you with the set of applications you need, some multitenant providers deployed multiple loosely coupled systems that were either developed by them, or acquired from 3rd parties. These systems do not integrate smoothly in most cases, and you will end-up with data in isolated islands. You should be looking for a provider that has a unified tightly integrated platform that can be used for any business or compliance process or application.

4.     “True” Multitenant:

You will find systems out there, that implemented multitenant in an odd way, like being a multitenant on the application tier but not the database tier (or vice versa), or it could just be multiple single tenant deployments deployed on the same server hardware. Multitenant architecture in the software industry is crystal clear, and these inadequate solutions will not scale as needed, nor help your business.

To conclude, the choices are limitless, and the selection process is not easy. It should be done right, because once you have your data hosted within a platform, changing your mind later becomes harder. I hope this article helps, Good luck.