It’s a truth that many large organisations would rather not face up to. Deep within their software inventories are applications that are 15, 20, 25 years old or more, applications that are so critical to the running of the business that their wholesale replacement would be either too risky or too expensive – or both.
Even if the will to retire many of these legacy applications existed, in the current economic climate, the funding for their modern equivalents is simply not there. A typical example is British Airways. It spent several months in 2008 planning to swap out a hotchpotch of business applications it had built up over the years in favour of a modern, integrated ERP system based on either SAP or Oracle Applications. Those plans came unstuck in October, when a review of spending priorities and an assessment of whether the business could ‘live with’ the existing applications concluded the ERP overhaul could wait.
Antiquated applications put organisations in a bind, though. Firstly, simply to maintain the code – perhaps a pensions application that needs to take account of new legislation or a manufacturing package that needs the addition of a new currency field – is no minor challenge. Often these older applications are mainframe-resident and written in third-generation languages (3GLs) such as Cobol, PL/I and RPG or any one of a long list of obsolete 4GLs like Mantis or Natural. They are also sewn through with calls to aged data and transaction systems such as DL/I, Datacom/DB, VSAM and CICS.
Finding skilled individuals happy to focus their careers on maintaining these code bases is proving an increasingly tough task. Indeed, many of the engineers who understand how such systems work within a given business are reaching retirement age, forcing companies to accept the need to upgrade or be left without vital systems maintenance capabilities as these skills disappear for good.
Certainly, they cannot rely on documentation to tell them how systems are structured or related to other applications: in almost all cases, that is patchy or long gone.
As a result, the risks associated with tampering with such code increase with its age, capping any notion of agility and even putting companies in breach of compliance obligations to ensure systems viability.
But if application replacement is a lost cause, there is only one alternative: so-called application modernisation – the use of automated logic discovery, documentation and code conversion tools designed to ease the cost, pain and risk of leaving behind the old code base or platform.
Companies that provide such tools and services – Micro Focus, Compuware, Software AG, Transoft and others – report booming demand as businesses that would have hitherto bitten the bullet on an overdue replacement decide they are willing to live with a stopgap solution.
Fear of tampering
“In the current economic climate, organisations will increase applications modernisation – not cut back on it,” says Jim Close, UK country manager for Software AG, the service-oriented architecture, integration and development tools vendor. “[Rather] it is the major capital investment in renewing hardware or replacing core applications that will be cut.”
In such situations, customers look at two alternatives, says David Stephenson, UK country manager at application modernisation specialist Micro Focus. They either want to update the application, because the systems software or hardware platform that it is written for is no longer supported. Alternatively, if they believe there is nothing wrong with the platform, they might still need to modernise the application to make it viable for Internet front ends or to integrate it with new facilities.
Luckily, today most of that can be addressed through automated processes. There are tools that can analyse tens of thousands of lines of code and function points to create a structured understanding of the application and so generate fresh documentation.
“That [alone] takes away the fear people have of not knowing what might go wrong if they touch an application that has been running well for years,” says Stephenson.
For customers who need to move away from a legacy platform, the next stage is to convert it to a more up-to-date technology base. For example, vendors like Micro Focus offer tools that convert applications written in a legacy 4GL running on a defunct Unisys, IBM, ICL or Bull mainframe into Cobol that can then be targeted at a Unix, Linux, or modern IBM mainframe platform.
That alone is a cost-justification for many. “A lot of those mainframe applications run well on modern platforms” says Stephenson, “And that brings with it a strong ROI.”
In fact, companies might actually not want to change the application at all, but merely re-host it in order to reap the ROI of running it on a lower-cost platform. “We have decommissioned many, many mainframe applications in this way,” says Stephenson.
By moving Cobol on to x86, though, customers have access to many of the modern-day toolsets that link to .Net and the Eclipse development framework, enabling radical steps in application modernisation.
“It gives you a set of development tools designed for 2009 that you can use on applications that were build 25 or 30 years ago,” says Stephenson.
Manx migration
A case in point is the Isle of Man Government. The authority found that the cost of maintaining its ageing Unisys mainframe was becoming increasingly uneconomical, and it wanted to take advantage of commodity server platforms. Moreover, the cost of keeping the specialist mainframe skills was high, says Allan Paterson, director of the information systems division for the Manx government, especially as it had committed to providing a highly integrated range of IT facilities using a Microsoft-based shared service architecture.
The option of rewriting such critical applications as the island’s stand-alone systems for National Insurance, companies’ register, rates and vehicle licensing was rejected outright because of the high cost and risk involved. Instead, its IT organisation chose to use Micro Focus Net Express to migrate the business logic “essentially unchanged” to a commodity Intel platform, while moving from Unisys DMS database system to Microsoft SQL Server.
The upshot was a £1.5 million saving over six years simply from the elimination of mainframe support and licensing costs – and that did not include the specialist skill sets it would have had to maintain. Five developers migrated 1.5 million lines of code resulting in a positive ROI in less than a year. That compares with the five to ten man-years of effort that would have been required to rewrite just one application.
The Isle of Man covered the costs of the migration in the first year, says Paterson. “In effect, it means that we can switch the mainframe off,” he says. “It hasn’t run since the end of December and is just sitting in the data centre waiting for us to do something ceremonial with it.”
All wrapped up
Atul Bhovan, a technology manager at Compuware, has had similar experiences. “In the mainframe arena, we are seeing people with 20 to 30 years background being asked to take voluntary redundancy as a way of companies cutting overall head count. That means they are losing the skills for things like CICS and DB2. The people who know the applications well are the ones they’re losing.”
That means the remaining developers are faced with the task of maintaining those applications, “unravelling the spaghetti code and trying to understand what is happening with it, simply to maintain it,” says Bhovan.
To make that someone else’s problem, many companies have looked to outsourcing. But such outside help often lacks the necessary experience of the application itself and how it relates to the business. They are often making changes to the application without realising the full impact of the change, says Bhovan. With mainframe skills in shorter supply, that has pushed companies to “tool” a new generation of in-house mainframe developers.
In that context, automated conversion of code to a modern platform is not the only option for legacy applications. With a clear understanding of how an application works and its related data flow, key parts of old applications can be wrapped using web services, leaving their logic intact and opening up links to modern front ends and to other applications, says Bhovan.
Are such measures all a stopgap effort until budgets are freed up? Or is there a serious intention by some to sustain legal applications in perpetuity? “Many customers absolutely continue to believe that their legacy application will live on for decades to come, that there is no end in sight for these technologies,” says Stephenson.
Renewal rates for Micro Focus modernisation products, at around 95%, back the assertion that modernised applications are still very much in demand.
And it becomes clear when the cost and timescales are analysed. According to Colin Cobain, the ex-CIO at Tesco who is now interim Group CIO at SABMiller, if the cost of a major application modernisation is rated as 1x, then the cost of rewriting that same code base is 4x and replacement with a package application is 10x. In terms of timescales, the comparison is about four months for modernisation versus two to three years for a package implementation.
With economic constraints forcing many companies to live with their legacy applications for longer than anticipated, that option will come as som