Who benefits from Multi-Tenant LMS?

Multi-tenant Learning Management Systems (LMS) are becoming more and more prominent in the LMS market. In a multi-tenant environment, all clients have their data stored in a single database. When a client accesses the LMS, however, they can only view their data; records for other clients of the LMS are filtered out. In this article I will discuss some the of advantages and disadvantages of the multi-tenant LMS approach.

Multi-tenant LMS (Learning Management Systems) are becoming more and more prominent in the LMS market.  In a multi-tenant environment, all clients have their data stored in a single database.  When a client accesses the LMS, however, they can only view their data; records for other clients of the LMS are filtered out.  In this article I will discuss some of the advantages and disadvantages of the multi-tenant LMS approach.

Full-disclosure: RISC is primarily a single-tenant LMS provider. We do have some multi-tenant implementations where the specific customer needs require it. I’ll provide links to other views on this debate so you can make up your own mind.

Multi-tenant LMS What is Multi-tenant LMS?

First, for the purpose of this article, I am defining a multi-tenant LMS as a single database with multiple customers.  Each customer has their own view of the data and may not even know they are in a multi-tenant system.    Think of it as an apartment building.  Your company rents apartment 302, while another company rents apartment 403.  But you never see the guys in 403 and they never see you.

Start-up in Multi-tenant LMS

In general, a multi-tenant LMS will have a quicker initial start-up than a single tenant system.  By this I mean that the vendor can “spin-up” a new installation for a client quickly.  Some multi-tenant systems have a kiosk-style purchasing mechanism; you go to their site, type in the number of users you want to put in the system, and click “Go”.  Bam, you just bought an LMS.  Of course, it’s empty.  Now you need to start importing students, courses, history, etc.

Unless you are a really small shop, there is not much advantage with a fast start-up to the customer.  We can spin-up a new customer system in a couple of hours.  Setting up your data is going to take much longer than getting your LMS “running”.

Upgrades

Since there is only one system in a multi-tenant environment, the vendor only has to upgrade one database, one set of installed software, etc.  This is great… for the vendor.   The client may also benefit, but there is a drawback.

First, here is the benefit part.  The client may get more frequent upgrades and bug fixes.  Since the vendor has only one system to upgrade, they can upgrade more frequently… if they choose to do so.  But since they have many clients that want maximum up-time, they will more likely choose to upgrade infrequently.

Here’s the drawback.  Since there are many clients in a multi-tenant LMS, a single client may not have much say (if any) in the upgrade schedule.  In most cases, the upgrades just get installed on a regular schedule, whether that works for you or not.

Performance & Scalability

Multi-tenant LMS proponents argue that performance and scalability are better than in a single tenant system.   The argument goes something like this:  When I add new hardware to the platform, everyone benefits.

I don’t buy that argument.  You can do the same thing with a single-tenant environment.  Upgrade the hardware on which 10 systems are running, all 10 benefit.  And a single tenant LMS has another way to improve performance; split customers across multiple servers.  Suppose you have a really large LMS customer that needs a lot of resources;  easy, give them their own dedicated server.  They get great performance and they don’t impact the performance of other customers.

In my experience, multi-tenant LMS are generally SLOWER than their single tenant brethren.  Frequently, they are not “real-time”.  Examples I have seen:

  • All reports show day-old data.  Real-time reports are either not available or limited to a small number of rows.  (For more on real-time reporting, see Real-Time LMS: Do you need it?)
  • Courses have to be batch loaded overnight.
  • SCORM courses could only be loaded by the vendor and took weeks to show up.

OK, some will argue that my examples are from a poorly designed multi-tenant system, and I cannot argue that.  But I can not see any reason why a multi-tenant LMS would ever be faster than a single-tenant system if both are well designed.

Costs

The most often cited benefit of a multi-tenant system is cost.  It is clearly cost effective to have one database and one application instance than to have 50 databases and 50 application instances.  Your software license for the database is cheaper, you use less storage space, you only have to support and upgrade one installation, etc.

The question is… are those cost savings passed on to the client?  Based on the pricing I’ve seen for most multi-tenant LMS, the answer is a resounding “no”.  If you are a really small implementation, you may get a nice price break in a multi-tenant system.  The bigger you are, the more likely that a multi-tenant system is going to give you sticker shock.  I have no explanation for this;  A multi-tenant system should be cheaper to operate, but the vendors are simply not passing those cost savings on to their clients.

Data Privacy – Legal Jeopardy?

This is something I haven’t seen others comment on.  Consider this:  Client A is in a multi-tenant LMS with Client B, and Client B’s data is subpoenaed by a court.

It seems like there are two options:

  1. The vendor supplies the entire database to the court.  Of course, they just exposed Client A’s data as well as Client B’s.  This seems like a bad plan.
  2. Someone writes an extract program to extract all of Client B’s data and provided it to the court.

In option 2, who writes that extract?  I’m not an attorney, so I asked one.  The answer is that an independent third-party would likely be hired to perform the extract.  OK, but didn’t that third-party just get an opportunity to look at Client A’s data as well?  Sure, the third-party is probably under a confidentiality agreement… with the LMS vendor, not with Client A.  If you were Client A, would you feel confident that your data was safe?  Using my apartment example above, if the guys in 403 commit a crime the police get to search your apartment.  No thanks.

Single Point of Failure

Recently, a friend of mine that uses a multi-tenant LMS database reported that the database was down.  He said “It seems to be a world-wide outage.”  Well, of course it is.  If a multi-tenant database is down, it is down for every customer.  In a multi-tenant system, the database itself becomes a single point of failure.

Direct Query

One final thought: Some of our single-tenant LMS customers have a Virtual Private Network (VPN) to their database and query it directly.  Their IT group can build SQL queries at will.  In a multi-tenant environment, this would clearly not be allowed.  Sure, the vendor could build views for each customer… but I think that is unlikely.  More likely they have API’s that allow such access, if they allow it at all.

Summary

So now I will answer my own question: Who benefits from multi-tenant LMS?  In most situations, the clear answer is that the LMS vendor benefits more than the client.

Other Views

OK, so those are my opinions.  Want to read others?  Here are some links:

Multi-tenancy vs. single tenancy: Looking beyond TCO (ZDNet)

Multi-Tenant vs. Hosted Cloud ERP: Pros and Cons

The Advantages of a Multi-Tenant SaaS Architecture

Art Werkenthin
Art Werkenthin is president of RISC, Inc. and has over 30 years' experience working with LMS systems in the Oil & Gas, Retail, Finance and other industries. Mr. Werkenthin holds a B.S. in Electrical Engineering and an M.B.A. in Information Systems Management from the University of Texas. Mr. Werkenthin is a member of the ADL cmi5 committee and frequently presents on cmi5 and xAPI. Follow him on Twitter @AWerkenthin for xAPI and cmi5 updates, as well as blog post announcements.
Menu