Devil's Advocate: Who's to blame for IT failures?

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.