Who's to blame for IT failures?

In this issue of Industry Insider, guest columnist Martin Brampton points out the two principles that could have helped prevent recent IT meltdowns.

Soon after I wrote a column about infrastructure, the systems at the UK 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.

biography
Martin Brampton is founder of Black Sheep Research, an independent consultancy providing research, writing and speaking services on a wide range of business and technology issues. Brampton was previously a director at Bloor Research, and has worked with IT as a user and analyst for over 20 years. He is a long-term contributor to silicon.com through videoed debates and his weekly column, which tackles a wide range of issues. He can be contacted through his Web site. This article first appeared on silicon.com.

Advertisement

Talkback 0 comments

Latest Videos

Sponsored content

Power Centre - Content from our premier sponsors

Blogs

  • Suzanne Tindal Sick of broken tender sites
    Some of the state governments desperately need to invest in more user-friendly tender sites so that looking for information on government tenders doesn't have to be a game of blind man's bluff.
  • Array Cyberwar: What is it good for?
    In this week's episode, Cyberwar. What is Australia's place in the world of digital warfare? What are the implications for the NBN?
  • Array Is wholesale-only backhaul just a pipedream?
    The potential acquisition of Pipe Networks by SP Telemedia has raised the question about whether vertically integrated backhaul providers will mean higher wholesale prices for ISP customers.
  • More blogs »

Tags

Back to top

Featured