CASE IN POINT
The UK National Insurance Recording System: High-Profile, High-Stakes and OPEN
The open systems movement has received a huge boost over the last few years from public-sector organizations that mandate or strongly recommend firms competing for contracts to use systems complying with industry standards such as OSI, POSIX, XPG4, UNIX, and other elements of the X/Open Common Applications Environment.Not everyone is happy with this policy of demanding open systems, however. Some suppliers and systems integrators argue that making open systems virtually mandatory is a form of arm-twisting by government. Better a first-rate proprietary system that delivers the goods than a mediocre solution based on open standards, goes the argument.
A major new system build in the United Kingdom, however, shows that insistence on open systems by government departments can indeed be justified on purely business and technical grounds. The IT project is the new UK National Insurance Recording System, known as NIRS2, which was commissioned earlier this year by the Contributions Agency, part of the UK Department of Social Security (DSS).
Background on the NIRS2 Project
National Insurance in the UK is an income-related payment collected by the Contributions Agency to pay social security and retirement benefits for UK residents. Payments are unique for each individual, so NIRS2 must record accurately the cumulative national insurance contributions of every single UK resident.NIRS2 is the first major IT project being built under the British government’s new financing policy, the Private Finance Initiative (PFI), under which suppliers plan and build IT systems at their own cost. The suppliers recoup their investments and running costs solely through charging for the system on a per-use basis; for example, charging for each transaction or query. Under such schemes significant risks are transferred to the supplier, including development, financial and technology risks.
When it goes live in the first quarter of 1997, NIRS2 will have some 60 million national insurance accounts requiring a database of 400 gigabytes. The system will have approximately 5,000 users in the Contributions Agency at the National Insurance administrative headquarters in Newcastle, England, and in field offices around the UK. NIRS2 will have to cope with some 200 transactions a second, for both batch and online processing. By the time the initial seven-year operating contract ends in 2004, the database will contain an estimated 800 gigabytes of data.
In April 1995, the Contributions Agency awarded the NIRS2 contract to Andersen Consulting, after running a large procurement. For their part, Andersen Consulting considered a range of solutions including proprietary mainframes. In the end, they chose to build NIRS2 using an open systems architecture.
Project Details Point to Open Systems.
In the NIRS2 installation, central processing is based on a cluster of open application and database servers from Hewlett Packard. The eight application servers have four processors, and the four database servers have six processors, all running under the X/Open UNIX specification. The client workstations are industry-standard PCs which communicate with the servers using the DCE communications standards.HP and the relational database, Sybase, were chosen by Andersen Consulting after a competition with other vendors. “We believe that the costs over time of the open systems approach are lower than if we had selected a traditional proprietary mainframe solution,” says Guy Morgan, an associate partner at Andersen responsible for the NIRS2 architecture.
Security, which is often seen as a weakness for UNIX-based systems, is ensured using dedicated communication lines and secure communications protocols, along with strict authentication procedures.
The architecture designed by Andersen provides the processing capacity by partitioning the database across several database servers and by splitting the application load across several application servers, effectively creating a virtual mainframe. An open transaction processing monitor, Encina, is used to manage the transaction integrity between the application and the database servers.
“If you drew a line around the central processors, it would look like we had a mainframe. But we haven’t paid mainframe prices for providing that functionality, and we have more control over the design and upgrading of the system by using this architecture,” Morgan says. “The architecture is very scalable; we can add more disk, RAM, and processors to the individual servers; and if even more capacity is required, we can introduce another application or database server. This scalability is achieved at a much lower cost than if we were adding new mainframe nodes. The architecture was designed to be inherently scalable to cope with the changing business volumes over the duration of the contract.”
Andersen has taken the open systems approach a stage further by avoiding proprietary fourth-generation languages (4GLs) and instead using industry-standard third- generation languages (3GLs), such as C and C++, to develop the NIRS2 applications.
“It is important to be able to own the architecture you are using and to be able to get down under the covers of an application to fix and tune it where necessary, which is not always possible using 4GLs,” notes Morgan. “We also wanted to avoid being dependent on environments that belong to other companies, which is what can happen when you rely on 4GLs and their development tools. 4GLs are effectively more proprietary than 3GLs.”
Reinforcing the Open Systems Choice
“When we looked at price performance, development effectiveness, flexibility, and scalability coupled with the skills available within the firm, open systems was a natural winner,” adds Morgan. “We can provide the security, availability, and performance of traditional mainframe systems using an architecture based on UNIX and open systems.”
Return to 'Open Comments' index page