Blog

From Gonzo Banker: (2012)

Bankers seem to have lots of questions right now about the continued relevance of COBOL in their organizations. “When are we going to dump this old COBOL software and go to something modern?” “How can our bank compete using this old language, initially developed in 1959?” “What’s the matter with you, Mr. or Ms. CIO, that you haven’t moved us into the modern world?”

Our Gonzo take? Bankers, get over it! COBOL will be the most-used programming language for business applications, and for banking specifically, for the next 25 years, just as it has been for the last 50 years. While new technologies and tool sets will continue to proliferate around core COBOL applications, modern technology is not a “magic wand” that can instantly replicate the rich functionality built up over decades on banking systems. For those ready to call me an obsolete techie who’s out of touch with the times, I ask you to hear out my case for the immortality of COBOL.

Just a few days ago, I celebrated the 43^rd anniversary of the day I went to work for a medium-size bank in Austin, Texas. This bank had a small data processing operation in the basement, and programming was done in Assembler language, very much a second-generation computing environment – incredibly detailed, arcane codes were needed just to fire the damn thing up. We had no operating system – to initialize a program, we literally pushed buttons on a console that read in one and only one punched card. On that card were the machine language instructions to read in a few more cards, which in turn had the instructions to read in the rest of the program, which was all on punched cards. Can you say Neanderthal? Yet at the time, this process was state of the art.

Soon after I joined the Austin bank, so-called third-generation machines and languages came to our world. The programming language we used was COBOL – COmmon Business Oriented Language. COBOL had one compelling advantage then, which still exists today: it is easy to learn. It is a simple language that encourages a straightforward coding style. Every variable is clearly defined in detail, as are file formats. We routinely took staff with little or no computer training and had them productive from a computer programming perspective inside of a few months. And COBOL absolutely enabled staff to focus on the complexity of the business applications, not the complexity of the language.

What our bank found back then was that taking an experienced loan operations staff member, teaching him COBOL and then asking him to help program a complex loan business process worked extremely well. We also found that we could take computer operations staff, give them a 30-day training course, and then imbed them in user departments to learn the business processes before bringing them back to program some of those business processes. Sounds a lot like a Web-based workflow developer today! As long as we gave developers adequate time to work closely with business unit staff and thoroughly understand their processes, the programming was not difficult.

Another major factor that will keep COBOL relevant for a long time is that basic banking processes, once programmed, can be easily replicated. All of the business logic that has been developed in COBOL over the last 50 years is, for the most part, still relevant. Virtually all of it has already been ported to newer machines and newer environments along the way (such as structured language constructs, object-orientation, visual programming environments, calling conventions from non-COBOL languages such as C, support for execution within Microsoft’s .NET environment and Java, and XML generation and parsing).

One of the bigger success stories in porting banking software from one platform to another is Fiserv/Premier’s movement of a solution originally developed for a Unisys MCP environment to an IBM iSeries environment. Arguably, this would not have been possible with any language but COBOL because moving COBOL code from one platform to another is several orders of magnitude simpler than re-writing it in any other language.

Some COBOL code is relevant in different situations than that for which it was developed. The date calculations that figure out how late a loan payment is can be easily applied to figuring out if a safe deposit box payment is late, for example. The steps needed to accrue interest receivable on a simple interest loan can, with only minor changes, also be used to accrue simple interest payable on a savings account. Once a routine has been written and de-bugged, it has value for many, many years – and there is little payback in re-developing that logic in another language.

In the interest of equity, it should be noted that COBOL has weaknesses, some true and some perceived. It is verbose – COBOL code requires longer data names and procedural descriptions. This is because it was designed to be self-documenting. With proper training, any additional verbosity from COBOL is offset by legibility and ease of maintenance.

Had this 50-year wealth of banking automation been developed in some other language, then possibly that language would have survived, just as COBOL has. But because COBOL was (and still is) easy to write, developers can be productive with less training and can spend more time solving business problems and less time learning the language.

In 1997, the Gartner Group reported that 80% of the world’s business ran on COBOL with more than 200 billion lines of code and with an estimated 5 billion lines of new code produced annually. The fundamental constructs of the banking software world haven’t changed much since then.

There are many external factors driving discussions among bank techies regarding the geriatric age of COBOL including:

• the advent of smart phones using Android and the iPhone;
• continuing advances in technology as evidenced by the iPad, Google Satellite Maps, or Predator drone pilots nailing bad guys in Afghanistan while sitting in an air-conditioned office in Nevada; and
• the impending retirement of a whole generation of Baby Boomer developers.

But whatever the reason for the buzz, what we do know for sure is that some of the ongoing utility of COBOL is not due to the language at all (other than its inherent flexibility) but rather due to the ability of the mainframe world to adapt to and incorporate client-server, Web services and desktop computing innovations. For bankers, it’s about simplicity, ease of use, and rich functionality, which COBOL has in spades! New Web services and database tools have great potential for helping banks perform better. Bankers should let up on the COBOL-bashing sound bites and focus on the capabilities new and old technologies can deliver to support business goals. It’s all about the functionality!
-bMcF