Every August, A-Level exam results make the headlines as
the grades go ever higher and a political debate
ensues.
So far the computer system at the Universities and Colleges Admissions Service
(Ucas), the central organisation that processes student tertiary
education applications, has not made the news - for all the right
reasons - but has quietly crunched the 15 million transactions that
match students to university places each year.
With the processing burden increasing and an arcane system in
place, Ucas feared that the computer system could not last forever
and opted for a complete overhaul.
Paul McClure, special projects executive at Ucas, says, "More by
luck than good judgement we had got through the exam season every
summer. But we were concerned that we would reach a point where the
clearing system would break down and not recover."
This anxiety was not helped by two episodes when the system went
down for 48 hours. Fixing it was a big job.
"The problem at Ucas is that we had a Cobol-based system that
was developed 20-plus years ago," says McClure. Specific parts of
the system needed esoteric skills to support it - right down to the
machine code level. Some of the experts were approaching retirement
age and this was an additional worry.
Connectivity was another concern - specifically, staying
connected to multiple third parties, many of whom were not
technically up to speed. Ucas connects to higher education
institutions (HEIs) and supports their different interfaces. As a
result, applications had been added in non-standard ways.
"It had grown of its accord over the years as different features
have been introduced. The result was a system that had become
increasingly unwieldy, unreliable and almost unmanageable," says
McClure.
Finally, there were difficulties associated with an
old-fashioned batch system. Inherently, batch processing is
inefficient and cannot meet the demands of operating in a 24x7,
business critical environment.
This limitation of the underlying architecture also constrained
any advances that were introduced, such as an online application
service for students.
Given the scale of the challenge - its biggest to date - Ucas
decided to recruit outside help but did not want to hand over the
project wholesale to a third party. Instead it went for a
partnership approach and shortlisted six suppliers to manage the
task of drawing up a specification and overseeing the roll-out.
Ucas chose LogicaCMG, chiefly for its track record of work
in the education sector. "We have an educational practice and have
done work with Ofsted," says Alan Teece, educational practice
manager at LogicaCMG.
The key factor was LogicaCMG's understanding of the sector's
constraints and levers. "Many of Ucas's customers do not have great
technical expertise to implement the interface, for example,"
explains Teece.
A J2EE n-tier architecture was designed to provide secure
server-side Java applications, replacing the Cobol batch system and
transaction processing engine. Dubbed Topaz, the architecture
comprises presentation logic, application layer and database. Each
of these tiers comprises Oracle servers hosted on Sunfire
hardware.
The biggest part of the overhaul was designing a flexible
interface that all third parties could use, and that would support
the evolution of admission applications into the future.
Richard Entwhistle, LogicaCMG project manager, says, "There was
a strong requirement to modernise the interface and make it
flexible enough to support new channels and technologies."
The original interface, Marvin, was written in Cobol. Based
around batched files of transactions, it was modelled on an
80-column punch card system. "There were real physical limitations
of the interface - its rigid and defined structure meant it could
not support additional information such as electronic attachments,"
says Entwhistle.
Some colleges had upgraded from Marvin to open database
connectivity (ODBC) standard, thus gaining a flexible query
interface into a secured database. ODBC allows institutions to
write their own queries into Ucas's database, but a more flexible
interface was required.
It was important that any new system continued to support Ucas's
existing Marvin and ODBC users with as little change as
possible.
The new Marvin was rewritten in J2EE to integrate with the
redesigned, online services being implemented as part of the
project.
"The solution [to the need for a flexible interface] was to
design a single entry point for all transactions into the system
that supports multiple channels," says Entwhistle. This entry point
handles all the business logic and functionality required for the
interfaces in one central module.
A key advantage of this approach is that consistent behaviour is
ensured across all interfaces. Also, new functionality can be made
available to all interfaces. "An additional benefit is that the
interface for each channel can therefore be quite thin, usually
requiring little more than the communication, data integrity
checking and validation," says Entwhistle.
While the original Marvin and ODBC users will continue to be
supported, HEIs are being nudged along the XML route, says McClure.
XML is the technology chosen to enable information to be exchanged
between Ucas and educational institutions, and Ucas is providing
support to facilitate this transition.
Ucas is also working with third-party software houses to ensure
the applications used by universities to automate offer processes,
interface with the new XML services Topaz provides.
Scalability was another critical aspect of an architecture that
has to be able to cope with the August results-weekend peak.
Three million sets of results are processed and communicated to
different HEIs, whose offers - received in separate files and
processes - have to be processed and communicated to the students.
All this must be done in time for Monday morning.
These transactions, plus the subsequent enquiries on the Ucas
website, result in a peak in processing approximately 100 times
greater than usual.
"One of the key requirements for Ucas was to provide a service
with zero downtime, but with the flexibility to cope with this peak
in processing during the academic cycle," says Entwhistle.
To provide the necessary resilience, the multi-tier architecture
was designed for optimum fault tolerance.
"Each tier operates a load balanced cluster of servers, and as
there is no single point of failure within the design, this
provides a very resilient infrastructure," says Entwhistle. The use
of clusters also provides scalability by allowing additional
processors to be added relatively easily to support peak times.
Security and contingency were other considerations. With several
education institutions opting to use a web browser interface
instead of linking to their own on-site systems, security required
a rethink.
A two-tier authentication system is in place for these users. A
secure perimeter around Topaz adheres to the BS7799 standard, and
in case of major disaster, offsite back-up mirrors the entire
configuration.
One of the disciplines that Ucas has taken on board from the
project is a proactive approach to testing. For the project,
automated and load testing was done using a tool called eLoad.
"We decided to look at testing as an ongoing service model
rather than a specific project-based activity," says Entwhistle. A
full-time test team now runs the key events in the academic cycle
three months in advance. This allows scenarios to be tried out and
any issues to be addressed before they would have otherwise been
encountered in the "real world".
Ucas's processing of applications, offers and acceptances
relates to a particular academic year and tends to be a discrete
exercise. So far there has not been much overlap between data
relating to different academic years.
This made the project roll-out easier because the new system
could support a brand new application without compromising the
current batch of admissions.
It was simply a case of running two systems, while one academic
year wound down and the next cranked up, explains McClure.
While Topaz launched successfully, in October 2006, there were a
number of "hold your breath" moments, mostly to do with meeting
rigid deadlines within the academic year.
"Because we were delivering within a cycle there were pieces of
system functionality we did not need from day one," says McClure.
However, he adds that these modules, such as exam processing,
became urgent later down the line and the stress was prolonged over
a longer period.
It is not just the IT team and the HEIs that have benefited from
Topaz, but also the customer service centre. As well hosting
university admissions, Topaz handles three other admission schemes
for Ucas: nursing and midwifery, teacher training and
conservatoires of music.
Staff dealing with enquiries use separate log-ins for each of
the systems but now move between them with ease.
As part of the implementation Ucas undertook a number of
training issues to start training staff and customers in the new
J2EE and XML-related technologies.
LogicaCMG staff remained on site for several months after the
project to support staff in gaining the knowledge and skills to own
and maintain the system going forward.
The biggest skills shift for Ucas, according to Entwhistle, was
a shift in thinking. "The move away from more traditional
development languages to an n-tier J2EE architecture can be a
fairly fundamental shift," he says.
Related article: Online admissions system cuts uncertainty
Comment on this article:
computer.weekly@rbi.co.uk