4 Integration with Source Systems

Integration with source systems extends to those elements of reference data identified in Figure 2 on page 7 of Chapter 2, "OSL Data Objects"^Foot 1. The integration mechanism is a technical concern that is outside of the scope of this guide. However, because it is possible to maintain this data through either the LTAdmin user interface or through automated integration with source systems, the functional administrators of an OSL environment must be very clear about the correct protocols and procedures for the administration of reference data.It should be noted that, as a general rule, reference data objects in OSL contain external identifier attributes that facilitate integration through the DLS (and SIF). These external identifiers are not exposed through the LTAdmin UI.

4.1 Integration through DLS

Data Loading Services (DLS) extend to all reference data objects. This makes it possible to maintain all reference data through automated processes and completely by-pass the need to use the LTAdmin user interface. In practice, it is very likely that there will be certain elements of data that are either simply not available in any source system (or in a data-centric format) or impractical to maintain in this manner.

To reduce the administrative burden and limit the likelihood of data (mis)entry issues, it is preferable to automate as much of the reference data maintenance as possible. Specific integration requirements may vary, the following table provides a summary of issues and considerations.

Table 4-1 Data Integration Issues and Considerations

Classification	Data Object	Issues/Considerations
Department	Schools	As schools are usually only ever created once, and as the creation of a school in the LTAdmin user interface is fairly simple, there is an argument to suggest that it may be simpler (for a small implementation) to maintain the list of schools manually in the user interface (UI). However, as most other data will reference schools (especially the user provisioning process) it becomes problematic if schools are not maintained through integration with a source system.
Department	Curriculum Framework	Curriculum Frameworks are unlikely to exist in data-centric format (to level of detail needed by OSL). Furthermore, only a few Curriculum Frameworks are ever defined (maybe once a decade) so it is generally less effort to maintain manually through the LTAdmin (Department Curriculum Administrator). NOTE: The majority of the effort is usually in the thinking needed to "translate" curriculum into a data-centric model.
Department	Calendar	Minimal effort is required to maintain calendars (setup once), however, some consideration might be given to automating the load of calendars to facilitate the adoption of calendars by schools.
Department	Grade Sets	Typically, Grade Sets do not exist in data-centric format. Only a few Grade Sets are ever defined and they are not onerous to enter and maintain manually through LTAdmin (Department Curriculum Administrator).
School	Calendar, School Curriculum, and Grade Sets	This would be part of the integration flow related to the creation of schools. Typically we would expect an annual process to automate the adoption of: the upcoming calendar year curricula that will be in operation in the school in the upcoming year grade sets that will be active in the school in the upcoming year The creation of school-based sub-calendars and grade sets is not recommended, as this only serves to add administrative burden at the school level for no real benefit.
School	Courses, Offerings, and Classes	Typically, this data is maintained in (different) local school-based systems (often home-grown) or in spread-sheets (or not at all) in smaller schools. Automated integration with source systems is preferred as it would save ongoing administrative overhead in schools. The biggest challenge is to provide K-12 business-centric consultancy to assist with standardizing (human) business processes.

4.1.1 Longitudinal and Partial Data

It should be highlighted that OSL maintains a complete longitudinal record of data to a level of detail that often does not exist in current systems. Many source systems only hold current data (for example, to which Grade a student belongs) or partial data (for example, a listing of Course with no reference to which Curriculum they are offered against). Dealing with source data issues is usually the biggest challenge in any implementation yet is often not given the due consideration it deserves during implementation planning.

Footnote Legend

Footnote 1: User provisioning is documented separately in Chapter 3, "User Provisioning".