If you are here we are assuming that you have either already gotten to know the limitations of most ITSM tools, when it comes to multi-tenancy (i.e. shared services across multiple tenants) or you are simply curious to find out why we think we have the right solution for the underlying problem. But let’s take a few steps back. Here are the questions we will be addressing in this article:

1. Why do organisations decide to opt for a multi-tenant architecture in the first place?
2. So how do conventional tools get around to solving these challenges?
3. What are the up- / downsides to these approaches?
4. How does 4me do it?

So let’s get started;

Why do organisations decide to opt for a multi-tenant architecture in the first place?

There are a few different reasons for doing this. These are:

• To Improve (Global) PerformanceIf you are a global organization with IT centers spread out, you might run into performance issues the further your users are located from the main server.
• To Control Data Visibility and AccessYou might not want certain parts of the organization to see other parts. Reasons here might be compliance, internal standards but could also simply be ease of use.
• To Support Shared Service Center Or Managed Service Provider EnvironmentsYou are a shared services provider or competency center that provides services to multiple divisions, at different levels, whilst working with external parties to deliver the services. External parties may vary by region or user group. - in short you are an “internal MSP”. Or you are an MSP offering (IT) services to your customers and want to manage the performance of these services in one service management platform.

So how do conventional tools get around to solving these challenges?

The Classic Method

Often, using multiple instances to achieve multi-tenancy is the only answer for guaranteeing performance for geographically disparate parts of the organisation because the architecture does not support the model.For on-premise solutions, this involves multiple architecture ‘stacks’, i.e. separate, locally deployed application servers, web servers, and database servers, along with the need for associated local infrastructure support.For SaaS solutions, separate cloud instances will be required, located in a local datacenter to provide good GUI response and application performance for users.Integrations are required to connect the separate instances, even when the integrated instances are from the same vendor.

The Advanced Method: Domain- or Firewall-Tenancy

Some tools do support data segregation within one instance using ‘domains’ which ‘firewall’ one organisations data from another. This is a common requirement in MSP environments.It is common to have separate configuration, per domain, to control visibility and data access across the different domains of the collaborating organizations / service providers, and further configuration to support the different processes and workflows demanded by each organisation.

What are the advantages and disadvantages of these approaches?

The Classic Method

The use of multiple instances requires that each instance is integrated, requiring integrations to be built between them, even though the same tool may be used across the different locations. These integrations need to be maintained, and often need to be updated and/or tested if one of the integrated instances is changed or upgraded, significantly increasing the cost of ownership.For on-premise solutions the need for multiple architecture ‘stacks’, adds infrastructure costs, increased support needs, and therefore, a higher cost of ownership.Even for SaaS solutions, this may add license costs for multiple instances of the platform, and will certainly add costs for setting up the integrations, and the cost of ownership for maintaining the integrations across the customer’s instances and the tools/instances of their service providers.

The Advanced Method

Whilst this approach addresses the challenge of ‘limiting access’ and ‘data segregation’, it does require extremely complex configuration to control visibility and access levels across the different customer organizations. Expanding, and even maintaining the configuration can be a major headache, at best, and at worst, can risk data segregation policy infringement due to mistakes being made in the configuration.Also, if any of the organisations in the multi-tenancy ecosystem want to support different processes, and therefore a different tool configuration, the required configuration needed increases exponentially, as more detailed rules of how the processes interact across organizations needs to be catered for..The other challenge with this type of multi-tenancy approach is that users of the organisations in the ecosystem that are not working in the same geography will likely experience poor performance because the tool’s architecture does not support geographically spread tenants.

Summary

The main drawbacks of the way that many tools implement multi-tenancy are that multinational organisations have to either; use one instance and put up with poor performance for remote parts of the organisation or service provider community, or, use separate instances and implement technical (WEB API) integrations between each.Often, separate instances are a good excuse for different organizations (or different parts of the same organization) to implement their own processes and supporting tool configuration (as they want to keep their own internal ways of working), which reduces process standardisation and automation, increases local admin overhead, and complicates the instance to instance integrations that are required (which also have to be maintained when there is a new release of the tool).