Modernising COBOL without the barriers

  • Daniel Kroening, Professor of Computer Science at the University of Oxford and Co-founder at Diffblue

  • 05.08.2019 11:45 am
  • FinTeh

COBOL (formally, the Common Business-Oriented Language) underpins the business-critical applications in most large banks and financial institutions. COBOL has something in common with Latin: it’s omnipresent even though few remain who are fluent in it. Its ubiquity seems benign until something needs to be modified and nobody knows how to do so without introducing new problems—and then the benefits of modernising suddenly become clear. 

But if upgrading legacy code were easy, everyone would have done it already. Instead, the IT departments at large, historic institutions face a few familiar bumps in the road when trying to replace COBOL code with modern systems, which new digital transformation tools are working to address, in some cases with help from AI.

1: Debugging legacy code

Most banks are running on applications composed of millions of lines of code, only a fraction of which is accessible, documented and covered by tests. And for the institutions that flourished in the 70s and 80s, a lot of this code will be legacy (COBOL and other languages)—the price they continue to pay for their early success.

Tracing the source of bugs in legacy code can be compared to embarking on an expedition: it can take hours or days to sift through primarily unmapped territory in search of a cause. This partially explains why developers have to spend about half of their time debugging, rather than working on developing new features for the business.

2: Lack of COBOL literacy

One of the main barriers to modernising COBOL is the inability to edit or maintain it when so few developers can understand it. The majority of engineers who spent their careers working with COBOL have since retired, and there is no indication that more new developers will be jumping in to take their places.

As a result, the banking industry is quickly running out of junior engineers with mainframe experience who can carry these applications forward. In a few extreme cases, experts in their 50s and 60s have even been called out of retirement to maintain applications in the companies they used to work for, which is expensive and unsustainable.

3: The cost of overhauling the system

The slow-moving disaster of having whole teams retire without replacements makes rewriting core applications in other languages look appealing, until the time and cost requirements are estimated. The Commonwealth Bank of Australia spent five years and hundreds of millions of dollars replacing their outdated IT systems, and they’re an outlier—most wouldn’t have the resources or high level buy-in to dedicate to such a momentous effort.

The other option is translating COBOL into modern languages, such as Java, Javascript or C#. This has recently become possible using any of several tools depending on the language you want to translate into. The caveat is that if there were any tests in the original code—which is unlikely; COBOL was introduced before testing became a best practice—they’ll be lost in the process.

4: The need for more tests

Working without tests is inefficient, uncertain, and unacceptable to most financial institutions. When legacy code doesn’t have tests, every new line of code written (including attempted bug fixes) has the potential to introduce new bugs, and bugs in critical code can cause untold damage.

Manually writing unit tests is slow and tedious, both for COBOL and translated code. One way for IT departments to speed up software application development is by automating the writing of Java unit tests with AI for code, a new category of technology that uses an AI engine to immediately increase code coverage for all areas of the code base, including those that are sparsely tested. This process can generate tests for an entire application overnight, making it easy for developers to work with the newly translated Java systems.

Driving quality and efficiency with new solutions

Businesses have been implementing these modernisation tools to overcome the roadblocks that have kept their core applications from being agile. For most global banks, Java code by itself would be useless, because they need the reliability and certainty provided by a test suite; the ideal COBOL translation process would also create accompanying tests, ultimately improving the efficiency of software development.

The tools for clearing these hurdles have finally made it possible to upgrade, and the time has come for financial institutions to embrace a future of active participation in tech innovations.

Other Blogs