Real-time LMS: Do you need it?
I’ve been in the LMS industry for over 25 years, and few things surprise me anymore. But lately I have had a real shock: Some Learning Management systems are not “real-time”. When did it become OK not to provide a real-time LMS?
I prefer to call it “experienced”, but I guess I’m old-school. I built my first real-time LMS when I was working in the petrochemical industry in the late 80’s. The primary purpose of that system was to track compliance training. The baseline “use-case” for that project was this: A regulatory auditor arrives on site and demands to see your training records. Typically, the auditor would spot check by interviewing several employees to make sure that the records pulled from the LMS matched the training employees said they had received. If your records matched, the audit would switch over to review your LMS records to ensure you were in compliance. If your records did not match… well, things could get ugly.
In this use-case, clearly a real-time LMS was critical to a successful audit. I assumed that real-time LMS was critical to everyone.
In the last few weeks, our sales group has been doing some system demos and had odd comments from potential clients:
- “Wait..you just entered that course and it shows up on student’s learning plans? In our system, we have to wait several hours for new courses to show up.”
- “Are you saying you can run large reports without scheduling them? In our system, only small reports can be run ‘real-time’.”
- “Did you just run a report that includes training that happened 5 minutes ago? In our system, we can only report on training data that is at least 12 hours old.”
- “You can run instant email messages about courses to students? We have to schedule email notices in a queue.”
So, apparently my assumption that real-time LMS was critical to everyone was invalid… you know what happens when you “assume”.
I think what is going on here is something I will call a “Synched LMS”. Most databases have the ability to replicate themselves.
As a user, you key data into your LMS and it goes to the “primary” database. Periodically, all the data is shipped over to the “replicated” database in the form of transactions. (Note: There are many ways to do this, but I don’t want to make this a technical discussion on replicating databases.)
Now, when you want to get data out, your data will come from the replicated database.
There are several advantages to this design:
- Your data is automatically backed up
Replicating your database provides a backup of your database. Depending on how frequently the transactions are copied, it may be either an exact copy of your production data, or it may be something that is only a few hours out of date.
- Disaster recovery
Ideally, the replicated database is on another server, possibly even in a separate data center. So if the primary database dies, you can fail over to the replicated database with minimal data loss.
This design splits the two primary tasks of a database: saving data and reporting data. Both tasks have improved performance because the load has been split across two databases.
Not so “synched” LMS
So how does this impact real-time LMS? The problem arises when the primary and replicated database on not synched frequently. The replicated database may be several hours out of date. In that event, you get the following issues:
- Courses don’t show up for your students until several hours after you create them.
You create them in the primary, and they later sync to the replicated database. Until that happens, they are not available.
- You cannot run large reports
The LMS vendor has implemented this model to provide better performance. If they allowed large reports to run in real-time, they would need to continuously sync. Otherwise they would have to run reports against the primary database, possibly impacting data entry performance.
- Your reports are not current
Because data is not continuously synchronized, your reports are always looking at old data.
- You cannot send instant email messages from the LMS
Again, your replicated database does not contains real-time data. So your email messages should ideally be scheduled after a sync occurs.
These issues are not the result of the decision to replicate; the problem lies in the timing of the synchronization. If you continuously sync, your replicated database is an exact copy (or very nearly so) of your primary database, so these problems do not occur. So a continuously synchronized database can provide real-time LMS.
Why Not Real-Time LMS?
So why would an LMS vendor choose not to sync continuously? The answer is again “performance”. When you have real-time synchronization you lose some of the performance advantages of the replicated database; now it is performing BOTH data entry and reporting tasks. So this is basically a design decision on the part of the LMS vendor.
I guess real-time LMS is now a “feature”, one among many to be considered when choosing an LMS. So, it is up to you as the LMS buyer/user… Can you live without real-time LMS? If you see the LMS as a compliance tool, I believe the answer is “no”. If you need to make course updates and have them immediately available to your students, I believe the answer is “no”. If you need real-time reporting, the answer is clearly “no”.
To me, this is another example of the LMS vendor making a decision that benefits themselves and not their clients.