This is Part 2 of a two-part feature on the future of COBOL. Here we'll look at training and job prospects for COBOL developers and the question of whether a COBOL replacement truly exists. There’s another investment companies have to consider. And that is what kind of employees they invest in. How many COBOL programmers are left? And is it worth it to hire one?
Dovid Lubin, president of Veryant, a company that develops software for COBOL platforms, says COBOL programmers make up “a dynamic, vibrant, active community.”
“Some companies have their own team of COBOL developers. We have some companies that have hired Java programmers or .NET programmers and trained them in COBOL to continue to maintain and enhance the existing COBOL code that’s so valuable."
However, Israel Gat, a Cutter Consortium fellow and director of its agile product and project management practice, sees a major COBOL skills gap opening up in the near future. “I actually believe we are facing a potential crisis in terms of COBOL skills because a lot of those guys are simply retired.”
In the past, new COBOL retirees would continue to do consulting work for their former employers. But Gat says this kind of arrangement is becoming harder as some are moving to places like “sunny Florida.”
“I believe that this is an important consideration as it’s not only that the generation that knew and did COBOL is retiring, but they are probably retiring to many places where they might not be available.”
And many of the 60-something full-time COBOL developers who are still employed might not even have the option to stay at their jobs much longer, says Evan Weaver, chair of Seneca College's School of Information and Communications Technology in Toronto. “Increasingly—I know a bunch of people down in the New York area who have been the COBOL people for a zillion years—they’re starting to get laid off, finally.”
“While they used to keep the COBOL people around, [now] they’re keeping around just enough to keep the COBOL stuff running. And because many of those people haven’t taken an active part in becoming familiar with the new languages, the new programming environments and so on, they’re finding that the company’s got nothing for them to do.”
Don’t expect a large new cohort of COBOL developers either, says Weaver. While Seneca College is one of the few institutions in Canada that still offers courses in COBOL, students who take it as an elective aren’t necessarily very gung-ho about it.
“Really, it’s almost sort of like an enforced elective for us in that they either take an advanced C++ course or they take COBOL. We give them that choice and often what we’ll find is the weak students will take COBOL because, well, the kind of problems you solve with COBOL are straightforward business problems—a little bit easier to understand.
“The kind of things we’ll attack in an advanced C++ course are usually quite complex. So we’ll find a lot of our people who aren’t very ambitious in terms of programming will take COBOL to avoid taking something else, and end up doing business-type programming rather than complex technical programming. “
Finding a successor
So what, in the end, will replace COBOL? Not one language, the experts say, but rather a series of different languages.
“There will never be a single preferred language,” says Weaver. “I know in the late 1990s everybody was saying Java was the way everything was going to go. And then it didn’t.
“A lot of the sort of enterprise stuff that used to be done in COBOL by the large organizations is often being done in Java now. Of course, it’s completely different kinds of applications—the things that COBOL isn’t good at, like distributed processing and Web interfaces, and so on.”
Phil Murphy, a senior analyst at
Forrester Research Inc., says that for better or worse, COBOL is on its way out. But companies may be deceiving themselves if they think their lives are going to be much easier once it's gone.
“Have firms gotten rid of COBOL and replaced it all with Java? Yes. But now instead of having a COBOL problem, they have a Java problem. So they got rid of COBOL—they didn’t get rid of the problem."
Again, Murphy says we should focus not on finding answers, but rather on asking ourselves better questions.
“It’s not 'what, oh what, can replace COBOL?’" he says. “It is, 'what workload are we trying to do here?’ Based on the characteristics of that workload, what’s the right platform, language and database combination for it to be as performant and flexible as it can be?”
And if the old system worked better, he says, don't be afraid to go back to it. Migration can be done in more than one direction.
"I talked to a credit card processing firm that was moving from distributed platforms and
databases to the mainframe because every time they added a new customer, the credit card processing for the new customer, they were spending money on Oracle licenses, on HP licenses, on server racks, and the startup of each new client was too expensive.
"The mainframe represented economies of scale that it needed. So, it’s kind of happening both ways."