Turning old into gold

Turning old into gold

Why throwing out legacy information systems and putting in new ones is not necessarily good for the business.

How much do you think a business system is worth? The usual answer to this question would be the purchase price minus any depreciation. Yet in my experience that is rarely a true reflection of the value of these applications to the business. These systems are embedded in the organisation. Processes flow from them. They are instinctively utilised by employees. They are frequently adapted to specific business requirements. If they stopped working tomorrow it would create havoc in many companies. The reality is they are worth considerably more than many executives appreciate. Yet even the name given to established business systems highlights a certain lack of appreciation towards them. The term ‘legacy applications’ implies something old fashioned, inherited or long-in-the-tooth. Unfortunately in IT there can always be a temptation to confuse the new with the better. There is a lot to be said for a robust, dependable legacy application. You know it works and you know changing from it will bring significant disruption to the business. Replacing an application can require extensive staff training and modifications to work practices while, at the back of the mind, is the uncertainty as to whether you will be any better off in the long run.

The problem of overhauling applications is highlighted by one of the most salient pieces of research undertaken in the IT industry. The Standish Group have been monitoring the success rate for thousands of IT projects since their seminal 1995 research titled ‘The Chaos Report’. This highlighted the lamentable track record IT has with software development. Standish defines a project as successful if it is delivered on time, on budget and with all the functionality that was originally promised. If it is cancelled it is regarded as failed. If it is delivered either late or over budget or without some of the promised functionality then Standish classifies it as challenged. Standish publishes the results as the ‘Chaos Chronicles’ on a regular basis. They make sobering reading for those of us in the IT industry who like to see ourselves as ‘agents of change’.

In its first report in 1995 Standish found that only 16 per cent of software development projects could be regarded as a success, 31 per cent failed and 53 per cent were challenged. Standish has discovered that things have improved since then. The 2006 report indicates that the success rate now is 35 per cent. However, while that shows substantial progress for the industry since 1994 the reality is that the growth in success levels has tapered off markedly in recent years. In the 2003 report 34 per cent of projects were classified as successful. In effect, there has only been a 1 per cent improvement in success levels in the last three years. Yet this timeframe coincides with an era when the IT in business has been under considerable scrutiny. Moreover, this still means that 65 per cent of business executives who sign off on a software development project are going to be disappointed. It makes you wonder why they bother. Part of the reason is the disproportionate amount of money companies spend on maintaining their legacy applications. Research by Forrester among North America and European enterprises show that they spend, on average, 75 per cent of their software budgets on ongoing operations and maintenance, leaving just 25 per cent for new investments. With an increasing corporate focus on innovation many executives are questioning whether prolonging the life of legacy applications is worthwhile.

Typically, businesses are attracted to new functionality. A popular current requirement is the need for better integration between what is commonly called the Web 2.0 and the back-end financial systems in an organisation. Increasingly businesses are constructing an eCommerce element within their web sites, usually in the form of an online shop. As a result, a need emerges to integrate this web site with financial systems and warehousing so shipping can be activated, stock levels can be adjusted and payments can be recorded. However, further analysis by Standish highlights that it pays to be modest in your aspirations for software change. Their findings reveal that those projects most likely to succeed cost under US$750,000, involve fewer than six people and take less than six months to complete. Conversely, large projects costing over US$5 million had a success rate of only 7 per cent. Therefore, it stands to reason that CIOs should be especially wary when they encounter executive aspirations for a complete overhaul of the core business systems. Is this level of redevelopment necessary? After all, no one would knock down their house if they wanted to renovate the kitchen.

Encouragingly many CIOs are recognising the dangers of rewriting or replacing their legacy systems. A recent study by Software AG among its customers revealed that CIOs have an increasing preference for modernising their installed applications through adding functionality and improving their look and feel. Yet 60 per cent of those surveyed were concerned about the flexibility of the legacy system to be quickly modified to meet changing business requirements and a similar number of respondents had issues with the real-time interaction between the legacy system and other applications. In effect it appears that CIOs know their legacy environment needs to be updated and they know this is not simple to do. However, they would still prefer to go down this path than tear out an old application and install or develop a new one.

For me the real issue highlighted by the Standish research is not the number of projects that fail. It is the number of software development projects that end up being challenged. These have remained stubbornly around 50 per cent since Standish began its research. Restricting software development to modernisation puts parameters around user aspirations but also means these changes can be made while the existing applications still function for the business.

Projects are usually delivered late or over budget or without intended functionality because the scope keeps changing. Frequently, this is indicative of poor project management. User requirements are either not flushed out effectively at the beginning or else IT keeps agreeing to new functionality requests without understanding the impact these will have on the project delivery schedule. The larger the project, the bigger the aspirations people have for it and the greater the likelihood of such scope creep. However, if the project can be more modest then scope creep can be curtailed. CIOs seem to be recognising that limiting software overhauls to the modernisation of legacy applications is a way of giving a framework to user requirements.

In the end, the value of a legacy application is determined by how well it supports the business. Many CIOs and their users can envisage what an ideal set of business systems might look like. Yet building and implementing such applications while the wheels of the business keep moving is, in reality, fraught with difficulty. The existing legacy applications may not be ideal but usually they work. Furthermore, with a little modernisation, CIOs might well find that they could turn something old into something gold.

Peter Hind is a freelance consultant and commentator with nearly 25 years of experience in the IT industry. He is co-author of The IT Manager’s Survival Guide and has been running enterprise IT executive events for more than a decade across the Asia-Pacific. He will host the CIO Conference 2007 on September 18 and 19 at the SKYCity Convention Centre in Auckland (See for details).

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags legacy systems

Show Comments