COBOL has a certain seniority in the IT world. Nobody can get it to retire—and nobody can find a replacement either.
The question of when COBOL will meet its demise has been debated for years now. But there is general agreement that the Common Business Oriented Language, first developed in 1959, will be alive and kicking well into this century.
Over the next couple days, we’ll look at what COBOL’s life expectancy might be, whether COBOL programmers are in demand, or even still employable, and what, if anything, will end up replacing COBOL.
Part 1 of this two-part feature will focus on efforts made to modernize COBOL beginning in the early 1990s.
Some people say that COBOL isn’t dead yet.
"I cannot foresee a date before the very late 2020s or 2030 where the dead part of that could possibly become true,” says Phil Murphy, senior analyst at Forrester Research Inc. “Here’s a mechanics analogy: the metric system is arguably a much better system than, you know, ¾ inch, ½ inch, linear measures, right? [It has] been for decades upon decades upon decades. We [in the U.S.] have not switched over. Why? Well, the cost, the sheer cost and size of the effort don’t result in an acceptable return on investment.”
Dovid Lubin is the president of Veryant LLC, one of the few companies left that develop software for COBOL platforms. Much of his business derives from the massive prevalence of COBOL in enterprises and the difficulty in replacing it.
“They’ve invested so many years and man-hours and millions of dollars in it,” he says. “So they want to preserve that investment."
And besides the massive expenditure it would take, says Murphy, often there just isn’t a practical reason for companies to switch.
“There will always be some allegedly better technology. Forget allegedly. There will always be better technology. The question is the install base and how badly or well COBOL does in comparison to the new thing and what’s the net benefit, and is it really worth upsetting the entire world to have something that’s a little better.“
On a global scale, the sudden death of COBOL “would be greatly detrimental,” says Israel Gat, a Cutter Consortium fellow and director of its agile product and project management practice. “Not only in terms of…not doing new applications with COBOL, but more importantly, perhaps, in terms of the huge amount of COBOL that is still there up and running.”
Estimates put the number of business transactions done in COBOL at between 60 and 80 per cent of all transactions performed worldwide. The number is significantly higher for financial transactions.
Does modern mean better?
Indeed, if there’s one industry whose lifeblood is COBOL, it’s big banks, one of the first sectors to implement it and, perhaps, one of the last ones that will abandon it.
But in an indication of how much things are changing, consider the case of ING Direct, a bank founded many years after its larger peers, in 1997. At ING, COBOL doesn’t have a presence —or at least it appears so.
Charaka Kithulegoda, ING Direct CIO, says his IT infrastructure runs on a combination of Java and Windows-based tools. However, he says “even some of the backends we use, without getting into specifics, are based on fairly older technologies.”
Here Kithulegoda cautions against thinking newer is always better. These older technologies “do things that are extremely effective and efficient,” he says. “And that’s unfortunately referred to by the term `legacy.’ But one of the reasons that people have stuck with these things is because they are extremely effective and efficient.”
Murphy agrees there is a tendency to want to replace technology without first considering the cost-benefit ratio of doing so. “The vendors get hung up on modern and not-modern. All one’s got to look at is does the COBOL, whatever it’s doing for the ultimate customer, is it doing a good job or a poor job at accomplishing that? Oftentimes it’s the IT folks who want to say `well, it’s doing a good job for them but it’s not Java, so ...' What? If it’s doing a good job for them, leave it alone and find a place where it is both COBOL and doing a terrible job for the end-user client and really needs to be modernized.”
This is all the more true given the type of applications COBOL was designed for, says Evan Weaver, chair of the School of Information and Communications Technology at Toronto’s Seneca College.
"For the most part, the COBOL programs that are out there are the kinds that take data from a database somewhere, crunch them and print out reports on a big printer somewhere, or print off cheques, or something like that.
“It’s the real pretty straightforward applications that don’t have a lot of technical complexity, that haven’t changed. Like, if you have employee records somewhere and you have a payroll run to run, that whole process hasn’t changed that much since the 1950s. That’s why companies haven't changed the stuff.”
There have been several efforts to modernize—not quite replace—COBOL over the years. Most recently, Veryant has released a new version of its flagship software, isCOBOL Evolve, which can perform a few novel functions like compiling programs in Java, and has a graphical terminal that can be launched from a command line.
“The isCOBOL graphical terminal allows you to take an existing COBOL application that was written to run on terminals in the last 30, 40 years, however many years COBOL has been around,” says Lubin, “[and] now you can run that on a graphical window that at first looks like a terminal, just like the original application, but can then be modernized by adding a menu bar, a toolbar, a status bar, push buttons—you name it—mouse support. And it can be done at whatever pace the developer chooses.”
Weaver says tools like this certainly have some value to COBOL developers. “If you’re having people who are programming using modern development tools for their other work…to have the same programmer interfaces to COBOL makes as a lot of sense rather than having them use some junky old tools for the COBOL part.”
But beyond some minor tweaking, he’s not convinced much can be done to improve a language that is now pushing 60.
He remembers a somewhat bold attempt by Microsoft [NASDAQ: MSFT] to do so around a decade ago: “They wanted to show that you could program .NET in any language, and created a COBOL .NET and gave examples of COBOL programs that could do the GUI stuff in Windows and so on.
“But it had the feel of the dog walking on its hind legs: it’s not how well it walks but just the fact that it can do it at all that people are fascinated by. I don’t know of anybody who is developing new applications in COBOL and I don’t think putting a pretty face on it is really going to change that.”
Gat says COBOL is fundamentally the product of a different era, a different way of thinking. He predicts that it will fade away slowly unless tremendous work is put into reviving it.
“The basic philosophy and certainly the technology under which COBOL had been conceived many years ago—I think it’s 50-something now—is very, very different from the way we see things today and certainly from the way we are doing things today.
“Unless someone really puts a lot of effort into a quote-unquote new generation COBOL — and I do not see that this is happening — I would expect that little by little the language should evolve and little by little various elements of the language will be implemented by other languages."
The most dramatic changes in COBOL over the years have not come in the form of GUIs or terminal emulators but through the movement to make it more object-oriented, he says.
“What we have now is a COBOL that wasn’t conceived as an object-oriented language. However, it has a fair amount of object-oriented elements, or aspects to it. So in that sense, while I would not quite compare it, let’s say, to Java, which was conceived from Day 1 as object-oriented, it has caught up on possibly the most important aspect of a programming language. So to me, the renewal, if you please, of COBOL…is quite remarkable.”
Part of this renewal has meant migrating COBOL from mainframes to distributed platforms. “We’ve seen an increasing number of migration projects, taking legacy mainframe COBOL and data to open and distributed systems like Linux, UNIX and Windows,” says Lubin.
Murphy, however, warns that enterprises pining to get rid of COBOL are often the same ones that want to trash their mainframes, often without thinking about why they’re doing it.
“You can’t separate the distributed-versus-mainframe from the COBOL/non-COBOL,” he says. “They always come up together. I think what folks who believe that leaving all of COBOL and mainframe behind is the definition of modernization, what many of those folks don’t realize is that it doesn’t replace your green-screen character interface.”
The size of the company and nature of its operations should be what determines the value of making the switch, he adds.
“If you’re a small firm, running a very very small mainframe and your environment is fairly simple — COBOL, JCL, VSAM files — then the odds are really good that you can move to a distributed environment and save a ton of money.
“The minute that simple environment gets really complex with languages like assembler and maybe databases like IMS or ADABAS or CA-Datacom, the services expense—because none of those translate well to the distributed platform—the services expense to get rid of the stuff that isn’t simple starts to erode the return on investment from moving.”
Tomorrow, we'll look at the dwindling COBOL talent pool, and what, if anything, will replace the programming language.
