Several years ago, pundits issued a dire warning: The impending retirement of COBOL developers, most of them baby boomers, would spell doom for big organizations that rely on mainframe apps. With young developers entering the workplace skilled in modern languages, not Common Business-Oriented Language invented in 1959, surely financial apps, reservation systems and the like would come crashing down.

But now it looks more like no big deal than doom. COBOL developers, born between 1946 and 1964, are quietly exiting the workplace in droves, and no one appears particularly alarmed.

There are two reasons why this is so. First, the COBOL apps that power core business operations today aren’t just COBOL. “They are COBOL surrounded by modern technologies,” said Ed Airey, product marketing director for COBOL tool maker Micro Focus. The core business rules may be written in COBOL, but that code is linked to user interfaces running on everything from a smartphone to a kiosk, he said. “No one is interacting with the green screen.”

Airey offered two examples: an insurance company that delivers a mobile app that lets prospects get auto insurance quotes on their smart phones; and an airport kiosk that lets passengers check in by swiping a credit card or scanning the barcode from a piece of paper confirming their itinerary. In both cases, COBOL is operating in the background, calculating the quote or zeroing in on the reservation, he said.

The second reason why developer retirement doesn’t spell disaster for COBOL-dependent shops is that COBOL apps in operation today are highly stable. They are, in a sense, walled off from the modern technologies that provide access to them, often interacting at only the database level, said Steve Gapp, president of LANSA, which provides legacy modernization tools and services. “COBOL code has been well maintained by COBOL developers who have been in their jobs for a long time.”

While the threat was clearly overblown, the retirement of COBOL developers is not without its challenges. “There is business risk associated with it,” said Gapp, noting that modernization of COBOL apps is a continual process, not a one-shot deal.
#!
The reality remains that these apps have been maintained by “a unique set of developers who are now leaving the workplace,” added Airey.

There are no simple solutions, but here are five options for moving ahead as COBOL developers head out the door:

Implement new requirements in modern technologies. Essentially a variant on the smartphone app described above, where a COBOL codebase interacts with modern tools. You can take this approach not just for user interfaces, but also for things like customer records, said Gapp. “The older customer records remain in COBOL, while more recent entries are developed using Web technologies.” This approach is obviously a stopgap measure, since the original COBOL code must be maintained, he said. “But at least you aren’t growing the COBOL codebase.”

Attempt an automated migration. There are tools on the market that migrate application source code to a new language (COBOL to Java, for example). But the resulting application is often cumbersome, said Gapp. “The [new] code is not very maintainable, largely because differences in how the two languages are architected.”

Forrester analyst Phil Murphy agreed. “The JOBOL code, as it is pejoratively called, tends to be poorly structured, but that’s an acceptable tradeoff for some firms,” he wrote in an August 2011 report titled “Mainframe Migration—Panacea Or Pandora’s Box?”

Replace the COBOL app with off-the-shelf software from Oracle or SAP. This is a valid option for COBOL apps that carry out HR or financial functions, for example. “But keep in mind that the new app may take many years to catch up with where the COBOL app was,” said Gapp. There are high costs associated with off-the-shelf software, added Airey, “especially if the app being replaced delivers a critical service.”

Outsource the maintenance of COBOL code to India, where COBOL developers are more readily available than in the U.S. “Some companies see this approach as a way forward,” said Gapp. “It’s an option, not a cure.”

Reengineer the codebase, using an incremental approach. Not a trivial undertaking, this option is the best strategy in the long run, said Gapp. Start by having COBOL developers evaluate the codebase and eliminate what’s unnecessary, he said. “In a COBOL app with 2 million lines of code, it’s likely that only half a million lines of code get used all the time.”

The idea is to look for areas of code that have not been touched, said Airey, offering an example: “An insurance app is likely to include some risk elements that are outdated and no longer relevant to the business.”

The next step is isolating “the important stuff so you can reuse it,” said Gapp. That might involve, for example, taking the COBOL code that carries out a pricing function and creating a SOA-based pricing module that modern technologies can easily call, he said. “Although you might eventually rewrite that module in a modern language, this approach gives you a way to move forward,” he said.

Reuse offers another key benefit, said Airey. “If you choose to rewrite everything, you may lose what is core to your business.”

What you’re doing with this approach is whittling your COBOL apps down to size and creating a path to move forward, said Gapp. “You’re figuring out which bits matter and which bits don’t,” he said. And if this can’t be accomplished before your COBOL developers exit the workplace, there’s always the option of last resort, he said. “You can call your COBOL guys out of retirement, but you will have to pay them a hefty fee.”