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).
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.
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.”
Return to 'Open Comments' index page