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.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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: firstname.lastname@example.org