The cost of waiting
Trinity Millennium Group and other vendors like it have established processes for analyzing and extracting the business rules embedded between the lines of Cobol code. "The solutions have come a long way in terms of the ability to extract logic and rules," says Burden.
But the process is time-consuming and costly. One Millennium client recently spent $1 million to have its Cobol programs analyzed and business logic reconstructed as part of a migration project off of a mainframe. "If they had the legacy programmers there and we had done the exercise with them, it would have cost $200,000 and taken one-tenth of the time," Garza says. If you wait until that institutional knowledge is gone, he warns, the costs can be as much as 10 times higher than it would have been beforehand.
Compounding the loss of skills and business knowledge is the fact that, for some organizations, decades of changes have created a convoluted mess of spaghetti code that even the most experienced programmers can't figure out. "Some systems are snarled so badly that programmers aren't allowed to change the code at all," Garza says. "It's simply too risky to change it. They're frozen solid."
Package deal
That's the situation faced by Jim Gwinn, CIO for the U.S. Department of Agriculture's Farm Service Agency. The USDA's System/36 and AS/400 systems run Cobol programs that process $25 billion in farm loans and programs. "We have millions of lines of Cobol, and there's a long history of it being rewritten," he says. "It has become increasingly difficult to change the code because of the complexity and the attrition of the knowledge base that wrote it." That's a big problem because laws that govern farm programs change every year, driving a need to update the code to reflect those changes.
Gwinn hired consultants from IBM, who concluded that rewriting the programs in a different language or rehosting them on a distributed computing platform would be complicated and costly. But the System/36 hardware had to go, so Gwinn decided to bite the bullet: The FSA will move off of its end-of-life mainframe systems by rewriting some of the code in Java and replacing the rest with packaged software from SAP.
But Gwinn says he'll miss Cobol. "It has been very stable and consistent, with little breakage due to code changes, which you see with Java-based changes," he says. "And in a distributed environment, you have to balance your workloads a little more carefully."
Going for a rewrite
The anticipated exit of institutional knowledge and the resulting shortage of Cobol programmers were also primary drivers behind NYSE Euronext's decision to re-engineer 1 million lines of Cobol on a mainframe that ran the stock exchange's post-trade systems. While Cobol was dependable, it wasn't viewed as maintainable in the long run.
Steven Hirsch, chief architect and chief data officer at NYSE Euronext, cites the need to make changes very rapidly as another key reason the stock exchange abandoned Cobol. "Ultimately, the code was not easily changeable in terms of what the business needed to move forward. We were pushing the envelope of what it took to scale the Cobol environment," he says.
So NYSE Euronext rewrote Cobol programs that run its post-trade systems for Ab Initio, a parallel-processing platform that runs on Linux on high-end Hewlett-Packard DL580 servers. The new environment allows for more rapid development, and the rewrite also eliminated a substantial amount of unnecessary and redundant code that had crept into the original Cobol programs over the years.