Occasionally in our documentation and contracts, you'll see reference to the "central/remote architecture". For most of you, this should never come into play. For others, this might be a solution to a difficult problem. (Please note, though, that most of our basic contracts exclude the use of the central/remote architecture... although it could be added without too much cost.)
The central/remote setup is based around a single, central installation of the LMS and the SCORM Engine, complete with the database elements required for the SCORM Engine. It then allows for one or many implementations of the remote component, each in a distinct domain. Communication between the remote and central pieces, then, is handled via web services, and the remote component does not require a database.
Why might you deploy in this fashion?
For some, this would be a way to get the content closer to its destination. You might install the remote components at each of your customers' sites. Conceivably, this could be done with a CDN as well.
Picture, perhaps, the DoD with a fictional LMS hosted at the Pentagon. Rather than eating all of the bandwidth from the Pentagon to the various bases around the country, the DoD could then deploy both the remote component and the content to each of the bases. This would mean that the content could be deployed simply over the local base network while still working with the central data from the Pentagon.
For most, this level of complexity is unnecessary.