Multiple Source Aggregation Model

FIGURE 10: UML ACTIVITY DIAGRAM FOR MULTIPLE SOURCE AGGREGATION MODEL

Typified by

TABLE 4: CHARACTERISTICS OF THE MULTIPLE SOURCE AGGREGATION MODEL

Description of scenario

The HEI has a large number of courses, whose data is held in a variety of databases, Word documents and spreadsheets.  Information managers in the HEI have been thinking about consolidating their course advertising information for a while, and some preliminary steps have been taken.  The most significant of these are:

• The most important sources of course advertising information have been identified;
• Agreement has been reached with senior management for the provision of resources, and with data owners to provide the information to a central source;
• A common identifier is now used across all the sources, although two or three of them require further work, so that course instances (presentations) can be used to generate full course records;
• The descriptive text on the website has been analysed and slightly re-structured, so that the XCRI recommended course description vocabulary can be used;
• Venue information (particularly names and addresses) has been standardised across all sources.

The implementation of XCRI was handled through a series of discrete projects over a period of 3 years.  It was decided early on that no attempt would be made to satisfy all the functional requirements for courses information, but that the focus would be on course advertising information only, with a concentration on outputs to supply the HEI’s website, paper publications and an XCRI web service.  The last would be available to internal and external organisations as the HEI’s authoritative source of course advertising information.

The development of a feed from each data source into the master database was handled as a separate project within an overall service oriented approach, co-ordinated through a central office.  Technical teams shared expertise by holding regular informal and formal workshops.

The development of the master database was a key project.  It was built using XCRI-CAP structures, and also included a range of structural and vocabulary services for internal and external use (for example its reference data included the latest UCAS entry requirement and subject vocabularies and data structures).

The scenario does not represent a fully centralised approach to all courses information.  Information relating to curriculum management and MIS systems is still held in separate systems.  However, system architects have made sure that a common approach to identifiers is used, and that each system has the potential to link to others, enabling system integration at a later date.

Example: Manchester Metropolitan University

Extract from the report of the xcri@mmu project:

1.4 Challenges and Solutions for Definitive Course Information at MMU

MMU is a large and diverse institution. Information about courses is generated, updated and consumed by varied institutional stakeholders. New courses are proposed to the Centre for Academic Standards & Quality Enhancement. Once approval in principle is obtained for running the course, the External Relations department will be alerted so that it can be advertised "subject to full approval". An early entry will be made at this time in an Access database maintained within the External Relations department, which is used to populate the online prospectus and to produce the printed version. Full documentation will be produced in Microsoft Word describing the rationale, academic and resource dimensions of the course and its constituent units, which will be considered by a validation panel at an event held to scrutinise the course. When the course has been validated, the External Relations department will be informed and the course will be entered into the student records system so that it can receive applications and enrolments.

When the XCRI@MMU project started, there was no common key between the Access Database of courses used for advertising, the documentation approved in validation and modification events, and the curriculum objects to which students applied and were enrolled in the student records system. Items could be matched by human intervention as, for instance, course leaders were aware of descriptions they had provided to marketing colleagues and could search by title on the web prospectus to confirm the descriptions were being used; they had copies of the documentation they had written for validation events; and knew how to look up applications and enrolment data for 'their' courses in the student records system. For undergraduate courses, UCAS codes helped the process of matching marketing, quality and enrolment representations of a course. For postgraduate and short courses, things were more challenging, which poses particular problems for aggregators such as the Greater Manchester Strategic Alliance.

MMU's solution to this problem of islands of course information is to launch an Academic Database project that will deliver a definitive curriculum database together with the workflow routines to ensure that it is maintained by the right people in ways that adhere to quality requirements for scrutiny and audit trails. The XCRI@MMU mini project has served to demonstrate the need for the Academic Database project, and the critical importance of common identifiers for aggregating data gathered for different purposes.

FIGURE 11: XCRI@MMU INTERIM SOLUTION PRIOR TO ACADEMIC DATABASE PROJECT