'Is xapiapps an LRS?'
It's a question I get asked daily.
'Nope. We're not.'
Silence for a moment...
'But you do this xAPI stuff right?'
And so the conversation proceeds. There's plenty of good reasons for the confusion, which I won't elaborate on in this post.
Since you're here I'll assume you know just a little about this xAPI stuff and how it fits into the training and development world.
What is an LRS?
In nontechnical terms an LRS collects and stores xAPI statements (which you can read about here).
Think of it as a database.
The 'database' can be queried for reporting and analysis.
Is it really that simple?
Hell no! An LRS has to meet these stringent technical requirements. Building an LRS is a hard process. We're going to skip over all that nasty detail.
Does that mean LRSs all do the same stuff?
No. But you could be forgiven for thinking that based on the introduction above. And this is what makes the LRS space very interesting.
A bunch of clever companies are building their own tools and features on top of the LRS specification. It's where the innovation is happening.
Okay, so what is an Activity Provider?
An activity provider is anything that sends xAPI statements. It could be performance management software, an ebook, a flight simulator or elearning content. In most cases the Activity Provider will be sending xAPI statements about a person.
So an Activity Provider just sends xAPI statements?
Yes. Actually no... we'll it's complicated.
'xapiapps' (we're an Activity Provider) accepts statements from LRSs for integration purposes.
Let's say an LRS has collected data about an employee. The LRS has determined that the best course of action is some on-the-job coaching.
The LRS sends a statement relating to that employee to xapiapps.
'xapiapps'. gets the statement and assigns the appropriate coaching.
Then it sends the results of the coaching back to the LRS.
So it's a virtuous circle?
We like to think so.