Open University Case Study | Managers Perspective
About The Open UniversityScope and coverage of the previous systems and processes
Making the decision to implement XCRI-CAP
Coverage
Baseline position
Description of activities: Occam Project
Description of activities: XCRI-CAP 1.1 implementation
Issues
XCRI-CAP in practice top of page
About The Open University
The Open University (OU) is the United Kingdom's only university dedicated to distance learning. It is the largest university in the UK by number of students, and its course offerings are correspondingly large and complex. It has around 150,000 undergraduate and more than 30,000 postgraduate students, 11,000 of the latter studying for Higher Degrees.
The OU's style of teaching is called ‘supported open learning’. Nearly all students are studying part-time. About 70 per cent of undergraduate students are in full-time employment. More than 50,000 students are sponsored by their employers for their studies. A third of the OU’s UK undergraduate students have entry qualifications lower than those normally demanded by other UK universities.
Most OU courses are available throughout Europe. Some of them are available in many other parts of the world. More than 25,000 OU students live outside the UK.1
top of pageScope and coverage of the previous systems and processes
In 2006 the University had several centralised databases and other electronic file stores of courses information, in order to carry out the university functions of validation, approval, curriculum management, and so on. These systems, both large and small, had accrued over time in reaction to the development of mature processes and ad hoc additions to activities, as manual systems became digitised, and as the need for information for reporting and marketing grew.
Segments from the databases, Word documents and other files were fed into a small centralised database (the P12 database) that held the material for publication of courses information on the OU’s main website. The process of merging and manipulating the data from multiple sources, so that it was of sufficient quality for publication on the website was a complicated one that had grown up over the years, requiring careful management and time consuming operations. Replacing this set of complicated processes with a new robust centralised Content Management System (CMS) was a high priority, and senior managers set up a project to advise on purchase and to carry out the installation. An early decision was not to wait for this new source, but to press ahead with an alternative solution and plug in the CMS as and when it became available.
The OU receives over a dozen requests per year for the supply of its courses information to third parties. The organisations and services making these requests range from major national website services, such as the National Learning Directory (NLD, now the Skills Funding Agency’s Course Directory) and Graduate Prospects, that require the supply of comprehensive details, through to relatively small local or regional services, such as individual Lifelong Learning Networks or commercial operations such as TrainAgain, that require only a relatively small subset of the information. Under the 2006 system the easiest place for University marketing staff to source the relevant information for onward transmission was the P12 database, because all other sources were partial, fragmentary or of unknown provenance. The University’s Communications Team sub-contracted APS Ltd to provide an intermediary service between the P12 database and third party organisations to fulfil the course marketing information supply function.
Some of the costs of keying and re-keying courses information (a major driver for use of XCRI-CAP) were already being off-set through the use of APS as a service provider. This enabled the University to reach seven data aggregators through one data feed from the OU to APS. The 2006 system involved APS in downloading the P12 database and carrying out a range of data manipulation activities, prior to producing bespoke outputs for each third party organisation. Although part of the data processing in the existing system used XML, in the absence of a course advertising information standard, these methods did not use a service oriented approach or XCRI, which meant that the model was not transferable to other Higher Education Institutions, and neither could the service be widened to include aggregators that might use XCRI in the future.
The main drivers for change to the existing system for supplying information to third party aggregators were the need for more efficient and effective delivery of the information, promoted by middle and senior managers within the organisation, in order to gain more students. It became clear to the OU’s Communications Team that adding an XCRI-CAP feed to the new CMS system would be a relatively trivial development with significant potential spin-offs for the further use of authoritative course marketing information in faculty websites and internal value added services, for example for student advice systems.
top of pageMaking the decision to implement XCRI-CAP
The OU has been at the forefront of the use of broadcast media and the internet in higher education since its inception, and has led the way specifically in the management of course marketing information in the 1980s and ‘90s through the development of the government-funded Educational Counselling and Credit Transfer Information Service (ECCTIS) service. The University’s website was the key mechanism through which students were engaged and enrolled. The Communications and Marketing Teams in the University were very open to change in the systems through which they operated. The internal course management systems had been subject to significant development over the previous ten years, owing to the need to support the Open University’s website, one of the most visited educational websites in the UK.
The proposal to implement an XCRI-CAP development originated during a period in which the systems supporting the University’s website were undergoing rationalisation, with the replacement of several diverse databases and other sources of information with a single Content Management System (CMS).
The key decision-makers were the Director of Communications and the staff within the Communications Team who were to manage the XCRI implementation. Decisions were simplified to some extent, because much of the complexity of the new process would initially reside with APS Ltd, already committed to using XCRI. The decision fitted in well with the existing trajectory of development of processes and systems within the University, which were becoming more streamlined, more student focused and making greater use of centralised technologies.
An important element in the decision to implement was the overriding concern not to create extra dependencies between the XCRI-CAP implementation and the project to implement the new CMS. It would be critical for the time scales of each project (the XCRI-CAP being tiny in comparison) that one did not depend on the other. The University decided to ‘black box’ the XCRI-CAP service development, so that it would function with whatever CMS or alternative process existed as the back end to the service.
For this scale of work decisions did not have to go above the Director of Communications, and it was helpful that there were strong recommendations from the responsible managers in the University and APS to support the work. In addition the support of JISC with a small amount of funding through the Occam Project and a smaller amount subsequently to help to complete an XCRI-CAP 1.1 repository eased the decision-making process.
top of pageCoverage
The change covered the supply of OU course marketing information to third party services. The offerings that this covered included the vast majority of the OU’s credit-bearing and qualification-bearing courses, but not it’s increasing range of OpenLearn resources.
The OU’s policy was to handle all requests for information about OU courses from other organisations centrally via the Communications Unit. So, at least in theory, the implementation covered all third party services that carried significant numbers of OU courses or supplied significant numbers of students. The national services included:
- The National Learning Directory (via UCAS), now the SFA’s Course Directory
- Learndirect Scotland
- Careers Service Northern Ireland
- Graduate Prospects
- Studylink
- Foundation Degree Forward
Baseline position
Existing processes were modelled using Unified Modelling Language (UML) diagrams. The purpose of the modelling exercise was to aid the project team’s understanding of existing processes, so the team could confirm intervention points and actions for development. While the team intended to carry out a comprehensive business process view, it found that it was sufficient to create only Process Behaviour and Requirements Views. These gave a coherent overview of the current requirements and information flows in relation to courses information delivered to data collecting organisations.
The baseline position is given in the UML model of current processes (see OCCAM Report).
top of pageDescription of activities: Occam Project
To extend, enhance and standardise the existing methods through which the Open University supplies its courses data to third party aggregators, in order to provide the wider community with a model of good practice using the XCRI-CAP schema.
Occam Project aims, November 2006
The Occam Project implemented an XCRI-CAP 1.0 solution, and the project ran from March to September 2007. The work was managed by the Communications Team, who engaged internal developer resources.
The following activities were carried out:
- APS and Communications Team reviewed processes, analysed existing systems and business processes to confirm actions for development;
- APS mapped OU course data structures to XCRI-CAP;
- For data publishing, OU developers designed and implemented a SOAP web service to output data in XCRI-CAP 1.0 format;
- APS tested and validated the feed, which was then used as the basis for addition of further data by APS;
- Finally the new system was evaluated against the old.
Although the Occam Project was very useful for evaluating XCRI-CAP 1.0, one of the outcomes of the project was to decide that version 1.0 was not sufficiently mature and stable for use in a live environment. The decision was taken, with some reluctance, to postpone live implementation until the advent of XCRI-CAP 1.1, while in the meantime having an impact on its development.
top of pageDescription of activities: XCRI-CAP 1.1 implementation
Subsequent to the completion of the Occam Project, XCRI-CAP 1.1 was developed, partly influenced by Occam and other JISC-funded XCRI projects. The new version first became available in January 2008, but further work on XCRI implementation at the OU was necessarily delayed until the completion of the new CMS installation in 2009.
The OU decided to upgrade the web service to XCRI-CAP 1.1 in tandem with the migration to the new CMS. The development work for this was handled almost entirely by OU developers, with APS involvement limited to initial mapping of OU data to XCRI-CAP 1.1, and testing and validation of outputs from April to September 2009. The process was straightforward and only required a couple of iterations to complete successfully.
The team operated both the original and the new service in tandem for updates in June and August 2009, in order to check processes and outputs thoroughly. The XCRI-CAP 1.1 ‘native’ service from the OU was launched in August 2009.
Part of the role of APS in relation to supply of OU data to third parties is to add specific coding schemes, classifications and controlled text fields to the original data, so that it can be used much more easily by other organisations. APS has therefore developed a ‘value added’ XCRI-CAP 1.1 web service feed on behalf of the OU, which has this extra material in it.
top of pageIssues
The Occam project highlighted some issues in XCRI-CAP implementation that are relatively commonly encountered and described below.
Security
The OU has taken the view that the XCRI-CAP service should be publicly available with no security measures, although accesses to the services can be logged. Each implementer will need to decide on an appropriate security model, so that access to the data is available to authorised users only.
Project approval and management of small projects
A specific stumbling block the project discovered was the time consuming administration that was required for such a small project, both in terms of gaining project approval and engaging relevant technical staff. The project had good support from senior management in the University, but the nature of this type of small scale implementation meant that full scale engagement in detail at the most senior levels was probably not necessary. Engagement at a middle management level with light touch sign off at more senior levels can be a successful model, and possibly quicker.
Link to wider initiatives, for example MIAP spell out
Communication with MIAP and other initiatives will help to ensure that XCRI-CAP can be integrated with other information systems.
Supported open and flexible modes of learning versus ‘traditional’ face-to-face teaching
A major outcome of the project was to suggest the reduction in the number of mandatory elements in the model. Many elements were indicated as mandatory in version 1.0, for example qualification, start date, venue address, that were not relevant for the types of course that are offered by the OU.
top of pageXCRI-CAP in practice
The OU XCRI-CAP feeds have been available now for over two years. It migrated to XCRI-CAP 1.1 in 2009, so there has been a significant length of time for their operation. In addition the ‘value added’ feed has been divided into Postgraduate, Undergraduate and All sections, for ease of use.
Processes that supply the data to the XCRI-CAP feed have been entirely replaced by the new CMS system. The ‘native’ feed at the OU is refreshed daily, so that consumers of it can be assured that the most up-to-date information is available. As the ‘value-added’ feed requires further manual intervention for the addition of extra information, it is maintained six times per year, which is generally more frequently than required by the major national data collecting organisations. These processes are now integrated as part of the OU’s administrative systems.
Maintenance of the feeds has not been onerous, and a small amount of development work on the technical details has been carried out. Manipulating the XCRI-CAP data into an even more readily useful ‘final form’ for an aggregator can ease the transition to using a web service, bearing in mind that the aggregator may have to complete some significant development work on interfaces to consume the feed.
A further issue now of relevance is how organisations discover the existence of XCRI-CAP feeds. At present there is no nationally agreed protocol for the location of feeds on institutions’ websites, and the main register is a human-readable page of feeds listed on the XCRI wiki. It would be extremely useful for aggregation purposes for an agreement to be reached for publishing locations, so that new services could connect to XCRI-CAP feeds as automatically as possible.
In the absence of a widespread expectation that providers will publish their courses information via XCRI-CAP feeds, the take-up of the OU feeds depends crucially on informing data collecting organisations and other interested parties that the feeds exist, and making appropriate arrangements to satisfy any extra requirements that these partners might have, so that the transition from manual methods to interoperable ones can be made as painlessly as possible. Involvement in the XCRI development community has helped to make other organisations aware of the existence of the feeds, and the OU is well placed to be able to enhance them relatively easily in response to requests for more information or the data transformed in new ways.
1 Information drawn from The Open University’s website.
------------------------------------------------------------
OU Management, version 1.2, 25 June 2010
top of page
