By Martin Brampton, 30 November 2004 10:00
COMMENT In analysing recent IT meltdowns, Martin Brampton points out the two principles that could have helped prevent many of today's problems.
Soon after I wrote last week's column about infrastructure, the systems at the Department for Work and Pensions apparently fell apart. While official spokespeople have played down the problem, internal documents suggest near panic.
Advice from outsourcing provider EDS apparently veered from a solution being 'imminent' with service to be restored 'very soon' to a statement there was 'no known solution'. EDS, it seems, blamed Microsoft, while Microsoft blamed EDS.
The official story emphasised that regular payments of pensions and benefits were unaffected. Limited comfort can be drawn from that fact, as the regular payments run on mainframe systems. If the trend is to migrate away from such systems, one is entitled to wonder what kind of problems may ensue.
Many commentators have pointed to the pressure on limited upgrade skills brought about by a last minute rush to move away from Windows NT in the light of Microsoft's withdrawal of support. It would be interesting to know where these migration costs fit into cost justification calculations for the systems affected.
Of course, we in the IT sector have brought these problems upon ourselves. Two fundamental principles have been ignored. One is the principle that desktop computer systems need to be designed to work in an increasingly widespread network. The other is that one of the best ways to manage software complexity is layering of both functions and implementations.
Personal systems have been a wonderful liberation in many respects. But as soon as such systems became available in quantity, attempts to join them together in networks began. Sadly development continued almost as if every personal computer was the sole property of an individual. Dealing with security and management issues was left aside, while every effort was made to add new functions.
At the same time, the ability to layer systems was destroyed. While DOS was the dominant operating system for personal systems, it was possible to put the bare minimum of software on the desktop machine, with applications and data held on central servers. Rapid strides in networking technology made this ever more feasible than previously, especially combined with network architectures that delivered both programs and data efficiently.
But in the move to a more sophisticated user interface, these principles have been abandoned. It has become ever more difficult to run applications locally while holding them centrally. Support of hardware and software has been merged and critical interfaces have evolved in an uncontrolled fashion.
Java was a brilliant attempt to reverse those trends. It aimed to create an application layer that was independent of the underlying hardware and basic software. At the same time, it incorporated a security model that accepted that programs run in an uncertain environment which may at times be hostile. Naturally, it had limitations but it was heading in a positive direction.
Unfortunately, Sun kept too close a grip on Java, undermining its universality in favour of making it a weapon in proprietary battles. And competitors were only too keen to respond by finding ways to promote their own proprietary interfaces and to undermine the vision of Java everywhere. Much the same thing has happened with the browser, where the idea of a universal standard has been transmuted into the actuality of dominance by a single proprietary product.
It should now be clear that we are paying a heavy price for transgressing these principles. There are obvious efforts being made to remedy the security issues, although they involve costly and risky upgrading. There is little sign of software layering being applied widely and even less of universal interfaces.
One has to hope that despite the unpromising situation, evolution towards a more robust structure can be achieved. Otherwise, we are likely to look forward to even more spectacular disasters and the frustration of government schemes to gain efficiency through automation.
Comments
There are 4 comments. Join the discussion
1. anonymous
So is it just coincidence that EDS were again involved in yet another government system problem. Coming on the back of the CSA fiasco, it just strike me someone somewhere that many of the systems failing to provide a reliable service are supplied or maintained by this outfit. Perhaps one day someone will realise the benefits of keeping support in-house.
2. Hugh Grant
All is not lost. Although Martin Brampton did not mention Linux I'm sure he had it in mind. With the various brands of Linux, especially those that conform to the Linux Standards Base, IT systems designers have the tools to construct robust systems .. and those that do not need to be upgraded simply because a monopolist provider wishes to generate a few megapounds worth of revenue.
Linux has a "DOS" and can be made as lean or as fat as the users need. The various Linuxii (!) can be used for desktops , servers , clusters and even embedded systems. Security is inherent in the system since it was designed from the outset as a multi-user multi-tasking system. Linux's ability to utilize a variety of filesystems both local and networked (including the Windows types) means that the systems designer can glue togeather multiple operationg systems and hardware types. Linux is as free as in speach .. but not as in beer. The code may be free but there is still a cost in using it. The freedom gained is well worth the initial cost because the ongoing costs are controlled by the user and not by a monopolist supplier.
3. anonymous
When, oh when, will companies realize that you don't cut costs by employing "cheap" labour? This same problem could have occurred equally well on Linux or z/OS (the current IBM mainframe OS) if the outsourcer had had the same sloppy attitude as this one. Mainframe systems don't have so many problems, not just because they use a more mature OS, but because mainframe personnel have internalized correct procedures.
4. Brian Catt
This is correct but earnest hand wringing. Professional IT people know how to do this properly but those left are not in a position to deliver, particularly in government where politicians and civil servants with only their own careers of interest to them and zero real technolgy grasp are in charge - and the vendor sales people will say what the customer wants to hear to they get their commission before the techies can tell the truth . We live in society where greed and short termism are rewarded and reasoned professionalism seen as obstructive to the short term term personal greed of exploitative capital and the people who want to become a member of that group through manipulation of a business. So this will always happen when professionals are not consulted in the first place, or ignored or overridden in implementation, e.g. in every major project. Its no different in privatisation of the Railways or Hospital Services for example. Lots of people get rich and the public get worse services, and in the worst cases killed, as a direct result. More hand wringing from the people in power while they count their pile or attend their sinecure directorships. If it ain't joined up it don't work. Joins across contractual interfaces don't work, joins between disparate islands of computing intelligence owned by different groups with different objectives similarly don't work.
Plus ca change.