For BNY Mellon, those Cobol batch and transaction processing programs on the mainframe represent an enormous investment. And while Gartner says it's technically possible to move mainframe workloads of up to 3,000 MIPS, the workload at the bank, which relies heavily on Cobol, consumes 52,000 MIPS of processing horsepower, spans nine mainframes and is growing at a 10 percent clip each year.
"The business wants us to make investments in programming that buys them new revenue. Rewriting an application doesn't buy them any value-add," Brown says.
Instead, the strategy is to "rightsize" some non-core applications off the mainframe where there's a business benefit, try to keep mainframe MIPS growth under 5 percent, and stay the course with the bank's core Cobol applications by passing on the business knowledge to younger programmers the bank will need to recruit and train.
Other functions, such as general ledger and reporting, are moving onto distributed computing platforms, where they are either replaced by packaged software or reengineered into Java or .Net applications.
But Brown still needs Cobol programmers to replace those expected to retire, and the learning curve can extend out for a year or more. That means adding staff and having a period of overlap as Cobol's secrets get passed on to the next generation. "I'm trying to get those people onboard and do the knowledge transfer sooner rather than later," Brown says.
But that kind of proactive approach, and the extra costs it incurs, can be a hard sell. "We haven't gotten to the point of feeling the pain yet. When we do, it will happen," he says.
Brown wouldn't specify the number of people he's hoping to hire, but said that the "real heavy need" will happen in the next five to 10 years, as the original mainframe programmers are expected to retire en force during that period. BNY Mellon currently has "a few hundred" Cobol programmers on staff, Brown says.
Brown's concerns are well placed, says David Garza, president and CEO of Trinity Millennium Group, a software engineering firm that has handled code transformations for large businesses and government organizations. "Almost every job we get has Cobol in it," he says, and most of the calls come from organizations that have already lost their collective knowledge of the business logic. At that point, he says, "it's a big risk."
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 the 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 ten 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."