The Veracity Learning system features a multi-instance architecture, which allows users to create more than one LRS database instance. Users can create up to a certain number of separate LRS instances depending on their account tier. Each LRS instance in our system is completely independent. They don't share keys, analytics, or even the same database. This allows you to completely separate different uses of the LRS.
So, why do customers need more than one LRS instance?
The answer may vary. The sections below describe common use cases for multiple LRSs
Cleaning data but keeping the original
Often it may be useful to modify data that comes into an LRS to change, add, or remove some values (e.g., change a verb ID to a standard ID used by other content that is not supported by a specific authoring tool or platform). Often it is useful to keep the original data in an LRS (sometimes called the “noisy” LRS) so that you can always get to the exact data originally sent to the LRS if needed. A noisy LRS can be configured to forward data to a different LRS and in the process
update the data using saved scripts. This results in one LRS with the original data and one with the cleaned data. In most cases, the cleaned data is used for regular business purposes and the noisy LRS is available if there are issues or inconsistencies that need to be evaluated.
Keeping data isolated for certain users
LRS instances in the Veracity Learning system use completely separate databases. This allows for complete separation of datasets so that it is impossible to accidentally mix data that should not be together. Since all of the Veracity tools are also scoped to an LRS instance, users can be granted access to an LRS instance that only contains data that they can see. This provides a secure way to control who sees what.
In many cases separate instances are kept, but some data is forwarded upstream for a different class of user. See below for this use case.
As described above, it may be advisable to isolate access to data in different LRS instances. However, it is often the case that an aggregate view of some data in a platform is required. When data is separated in different LRSs, the data exists in different databases so aggregate statistics are not available.
Typically, in this situation the isolated LRS instances will be configured with forwarding rules and saved scripts to forward some subset of the data to an upstream LRS. For example, the isolated LRSs may contain a lot of user performance information useful to the users that have access to the system, but leadership really just wants to know how many completions there are across all LRS instances. In this case, the isolated LRSs would only forward “completion” data to a single upstream LRS where leadership can get to the exact data they need without filtering through a lot of irrelevant-to-them data.
Also, it is useful to use saved script features to manipulate data in addition to filtering out “noise”. For example, it is possible to anonymize data when it is sent to an upstream LRS.
Development, test, production
Getting clean data that is ready for analysis can be a challenge for those new to xAPI and data science. Releasing content to users that tracks xAPI without a formal development lifecycle can result in data difficult or impossible to analyze. Many users will create LRS instances for this purpose:
- a development LRS for content developers so they can see the data as they work on the content creation
- a test LRS for quality assurance, verification and validation of the data approach, and
- a production LRS when the content and resulting data is tested and ready for release to production
Summary and Helpful Links
These are several use cases for multiple LRS instances, but are not the only use cases. There may be many other organizations or use case-specific uses for multiple LRSs. Our team can help your organization with strategic decisions on an LRS instance architecture.