Columns

How Best to Extend Legacy Technologies?

As you extend mainframe systems to the Internet, should you start from scratch, wrap old code in Java, or just build a pretty front-end? The debate continues.

• By Joseph McKendrick
• 04/01/2002

Some IT executives prefer to rebuild or re-engineer their legacy systems from scratch in a language like Java. Others wrap COBOL code in Java or HTML. Another method, which I've often discussed here, involves building new presentation layers without touching the code at all. What approach works best for which situation?

A couple of studies shed new light on the effectiveness and cost of various approaches to legacy-to-Web integration. A Gartner Inc. report discusses the pros and cons of both "invasive" and "non-invasive" procedures that extend legacy data. "Non-invasive approaches leave the base process code, data, transactions and end-user interfaces the same and usually interpret one or more of these legacy sources for further actions—apparent integration or wrapping," writes Gartner analyst Dale Vecchio, lead author of the analysis. "Invasive approaches change one or more of these legacy sources. The changes can be slight or massive in nature."

"Massive changes" would include file expansions, technology ports and code restructuring, while "slight changes" might mean the extraction of workflow rules.

The report concludes that extending legacy technology may be a mix of both short-term tactical implementations and long-term strategies. IT managers need to look beyond infrastructure concerns to include process and workflow. "Think strategically when selecting a tactical legacy solution. Choose non-invasive extension strategies for tactical efforts; choose invasive approaches for more-strategic efforts."

A DePaul University analysis actually quantifies how much companies save by employing tools that transform current back-end applications to GUI front-ends. The study finds that employing automated Web-enabling tools can get re-engineered applications out 25 times faster than if they re-wrote the applications in Java.

This study compared a manual re-write of the legacy system in Java to the use of a legacy transformation product. Researchers found that the task was completed by the transformation tool in less than four percent of the time required to re-write the application in Java for about three percent of the salary cost. The typical salary expense of a Java programmer re-writing an interface was $1,040, compared with about $33 for a COBOL developer to run a transformation tool.

The learning curve is a big issue here. The Java re-write took the longest time because the Java programmer was unfamiliar with the underlying COBOL code and business rules, says Howard Kanter, co-director of DePaul's Institute for Software Metrics. Kanter found that COBOL developers were able to build Web-facing front-ends in a fraction of the time of Java developers. "This allows for quick implementation of Web-based front-ends," he says. "Knowledge of COBOL systems pays off."

The best time to use a Web front-end tool is when the organization needs to move an application out to the Web within a short time, or when either the skills or source code for the legacy system is no longer available. The bottom line: Back-end systems are a key resource that must be leveraged to the Web smartly and cost-effectively.