Making Sense of "Multi-tenancy" Claims

The last few weeks have provided some really confusing hype regarding claims of multi-tenancy from some ERP vendors.

The latest twist involves a vendor stating that their product can be multi-tenant IF some of their resellers/hosting partners can offer a standard configuration to more than one customer. What happens in this scenario is that some of their customers will share one copy of the code while data may or may not co-exist in a single physical database (it would, of course, be logically separated).

All of this terminology jockeying is getting tiresome and it is very confusing to customers and analysts. So, let's get a wash cloth and soap and clean this up a bit. (By the way, there's a place for all of these software options - but there's no reason to lump them altogether in one technical term)

Scenario #1

I think (just my humble opinion) that multi-tenancy works like this: Someone builds a right spectacular skyscraper. It has dozens of floors in it with which each tenant can make some modifications (i.e., tailoring) to their space to fit their business needs (e.g., office furnishings). These tenants must share the common areas (e.g., lobby, elevators, etc.) but cannot alter them. They can't alter any structural aspects of the building either.  If the building owner makes a modification to the building (e.g., the air conditioning system), it affects all tenants and all tenants equally. Some modifications, like painting the elevator lobbies may be done in phases and some tenants might have some success in altering the schedule for this work slightly. Nonetheless, the work will get done.

This is the type of multi-tenancy that some analysts see as true or real multi-tenancy. In multi-tenant software, all of the users essentially share one copy of the code. They can make some tailoring or personalization of the product but they can't fundamentally alter the core product. When upgrades occur, ALL users get them. Users may have some say as to when the exact upgrade occurs but it definitely will occur. The vendor can make these upgrades occur with minimal effort as they only need to upgrade that one copy of the code. Furthermore, this one copy has only one technology architecture.

Scenario #2

Using another building analogy, when a potential tenant for this skyscraper says that they need a dedicated elevator just for themselves, a barge dock, a rail siding and an overhead cranes, they are not a serious prospect for a shared building. No, they need a 'build to suit' facility like a one-off factory.

In this scenario, a software buyer wants and needs a standalone, single-tenant solution. This product can be an on-premise solution or a hosted on-premise solution. It may have a different technology stack (e.g., RDBMS, systems management software, etc.), than what is used in the multi-tenant product line. With this on-premise solution, the customer is free to modify the code and choose NOT to upgrade the product (if that is their wish). This solution could be run on the customer's own data center or on a private hosting service. However, since the solution will not be upgraded (automatically) by the vendor and may have non-standard code, it is a single-tenant solution. Hosted or not, it is single tenant.

Scenario #3

Now, this is where purists and marketers start to run into each other. There is a third scenario.

In real estate terms, this scenario resembles an industrial park. All of the occupants share the same utilities and roads. They all must meet the same zoning restrictions.  All of the facilities are in a common real estate tract but that's about as common or shared as it gets. Each firm can design their own purpose built facility and decide when or if they want to maintain it subject to the zoning or deed restrictions. If one property owner wants to upgrade their air conditioning system, they can and it doesn't affect any other property owner. This is still single-tenancy with some restrictions. If two firms want to co-locate in one facility in this industrial park, they can; however, their actions are separate from the actions of the other occupants. To call the two co-located firms as 'multi-tenant' is borderline truthful but it really doesn't compare to the multi-tenancy described in Scenario #1.

Software vendors are starting to offer their products with all kinds of flexibility in this third scenario. They let customers choose between an on-premise, hosted single-tenant and, possibly, a hosted multi-tenant solution (of sorts). I prefer to call this ‘mixed-tenant' instead of multi-tenant. Calling the last one multi-tenant assumes that several customers will voluntarily and permanently agree to use the same configuration of the product and can agree on when, if ever, they will want the product to be upgraded. To offer this flexibility, vendors frequently rely on channel partners to host the solution, do any customer requested upgrades and decide if they want to offer the ‘multi/mixed-tenant' version. As a consequence of these options, customers have the option to revert back to an on-premise solution if the hosted options grow tiresome.

How this gets confusing

A major organization was recently evaluating customer relationship management (CRM) solutions. They received a number of proposals from channel partners, each pitching a software vendor's solution. Two of the bids involved CRM software from the same vendor. One partner said the solution was on-premise or hosted while the other partner said it was a multi-tenant solution.

The customer was confused. They didn't see how one product could be all of these things. They looked at the vendor's website and collateral and found the language to be confusing at best.  In the end, the customer could not tell what the truth was re: the product and tossed out both channel partners' proposals.

Recently

A major vendor has announced the industrial park (Scenario 3) concept for one of their product lines. They are letting channel partners decide if they want to offer:

• Single-tenant SaaS solutions
• On-premise versions
• A hybrid solution where all customers will be hosted on a single device but some groups of customers can choose to accept a standard vertical version of the product. If this subset of customers agrees to this, the reseller partner (Not the vendor) will perform upgrades at scheduled times.
• The option to move between a hosted version to an on-premise version of the product.

In the last two bullets are some really important points to ponder. First, it's the channel partner, not the vendor, who must perform upgrades, patches, etc.  Second, the customer will have to pay for these upgrade activities as the vendor will not provide them. Third, the option to move from hosted to on-premise seems like a nice thing to say but may rarely ever get utilized in practice. For a company to move back to on-premise, they would need:

• New or additional computer hardware
• New or expanded database licenses
• New or expanded licenses for systems management tools
• New or expanded licenses for reporting, analytic and other data tools
• Etc.

Guidance

What's really confusing to fellow analysts, and I suspect to prospective customers as well, is the insistence of software marketers to call pretty much everything ‘multi-tenant'. They use a technical term as a marketing ploy and confuse it with deployment options.

At the end of one such briefing with a major ERP vendor, I spelled it right out for them: please define, price and name these products by their deployment methods instead of lumping every option under one confused term. Specifically, I suggested that they separately market and brand their:

• on-premise solution
• single-tenant hosted solution (with optional channel partner updates)
• mixed-tenant hosted solution (with optional channel partner updates)
• true multi-tenant cloud solution (with vendor provided updates)

Each of these should have its own name, pricing, update policies, data security and access protocols, etc. Doing so makes it easy for prospects to understand what they are/aren't buying and why.  This is why Honda has separate brands, models and trim levels for all of their vehicles. If they called everything an "Accord" none of us could make heads or tails of what they're selling, pricing, offering, etc.

Vendors, please, straighten this out.