On Cobol and Legacy Systems: Covid-19 Turmoil Calls For Change

“LONG LIVE COBOL,” wrote Wayne Linksman in a LinkedIn message. “It keeps me employed at 65 years old.”

Linksman has been a senior Cobol programmer at Bank of America, where he worked on its credit card system; Fidelity Investments, assisting with application development and maintenance on its mutual fund accounting system, FIS InvestOne; and most recently at Infosys, a consulting and IT services firm.

The pandemic has brought Cobol, a legacy programming language, back into the limelight in arguably the biggest way since its celebrated inception in 1959. This time, however, Cobol has a problem—or rather, there’s a problem due to Cobol. First, it’s big—but evidently, not too big to fail.

There are 240 billion lines of the code still in operation, and 5 billion more are added every year, reported IBM Systems Magazine in October 2019. According to a 2017 graphic by Reuters, 43% of banking systems are built on Cobol. The language underpins many of the legacy systems and mainframes used by large banks, corporations, and government agencies, most notably, at the moment, in unemployment systems. As more than 20 million Americans filed for unemployment benefits in the last month, systems are overloaded in some states.  

Cobol’s second problem is its age. Though it’s withstood the test of time—a remarkable feat in tech—the programmers who know it best are nearing retirement or have already aged out of the workforce. Additionally, college courses teaching it are few and far between. That means when things go wrong, there are fewer people who have the expertise to quickly fix these issues.

As of early April, IBM and the Linux Foundation jointly introduced three new programs: Calling All Cobol Programmers, which connects fluent coders to municipalities in need of help; Cobol Technical Forum, a temporary resource for experienced coders to provide free advice throughout the crisis; and Open Source Cobol Training, a new open-source training course that’s available free on IBM’s training platform.

The Covid-19 outbreak has brought forth a 100-year flood scenario, and almost no one was prepared. While some, like Linksman, are firmly positioned in the pro-Cobol camp, others are asking if the crisis is all the proof needed to start overwriting—and fast.

Digital Transformations: What’s In A Name?

North of the US border sits a cautious Alex Benay, partner in digital and government solutions at KPMG Canada, and former chief information officer and deputy minister for the Government of Canada. Cobol-run systems piling high with Covid-19 measures are still working—albeit not perfectly—and more than 1,500 programmers have answered the call from IBM and Linux as of April 24, a spokesperson for IBM said.

Those are “amazing accomplishments,” Benay tells WatersTechnology. “But the question still needs to be asked—did you just double down on a technical debt?”

Technical debt is a term used to describe the cost of repeatedly putting off system maintenance or upgrades, and the opportunity lost. It can swell and swell, but go largely undetected, until a sudden shock to the system has the power to break everything.

“[When the pandemic is over] I’m hoping we don’t go back to the analog days. If we’re going to stay digital, then this technical debt has to get looked at something fierce,” says Benay, who you’ll never hear using the word “transformation.”

WatersTechnology has reported extensively on the digital transformation projects underway at institutions such as BNY Mellon, Northwestern Mutual, Bank of America, Brown Brothers Harriman, and many more. But if banks and tech companies are really two birds of the same feather, Benay argues such a concept shouldn’t even exist.

“I think it’s a load of crock,” he says. “If you use that word, when are you ever going to be done? You’re never done. If you’re really a digital business—whether that’s a bank or your government, it doesn’t matter—you’re never done.”

Another who’s familiar with the crossroads of government, finance, and technology is Matthew Van Buskirk, co-founder and co-CEO of Hummingbird Regtech, which specializes in anti-money laundering solutions. Van Buskirk has also been a bank examiner at the US Treasury Department, as well as director of compliance and regulatory affairs at Circle, a Boston-based fintech helping companies utilize stablecoins and public blockchains for payments and commerce.

“I have not seen any financial institution or government agency that I’ve interacted with that had what I would consider to be a good implementation of Cobol,” he says.

As an anecdote, it’s rare to find a bank that can definitively say how many customers it has. Without naming names, some of the big banks he’s worked with have as many as 10 core systems, especially those that have gone through mergers. As a result, those systems don’t natively talk to one another, and the same person may be represented in multiple systems. The only solution is to run manual queries throughout each one.

In another Cobol implementation he’s seen at a government agency, a database ran on a version of Cobol that could handle only capitalized text. If the agency were producing a report, for example, and someone entered a sentence with both lowercase and capital letters, the output was 1,000 or so pages of unformatted, block text with no paragraph breaks. The solution was to send someone in and manually insert all the spaces on each report.

“I think we probably reached the point 10 years ago that we should have been ripping all this legacy stuff out,” Van Buskirk says.

New Frontiers

The landscape for alternative programming languages is vast, with many specialized codes for specific use cases. Swift, for example, powers Apple iOS; Rust is ideal for embedded programming, such as for computer chips; Python is versatile, and suits areas like artificial intelligence and machine learning well, but isn’t commonly found in game design and mobile apps, where Java and C++ shine.

Jason Tatton, a former algo trader from JP Morgan, recently developed a new language called Concurnas, meant to help financial services firms tackle common problems with concurrent programming, and having to switch between languages when moving from building to implementing a trading model. Taking an all-encompassing approach, Concurnas is open source and Java-based, and aimed at retaining the performance advantages of languages like Java and C++ with the easy syntax of Python.

Similar to Tatton, engineers Jeff Bezanson, Alan Edelman, Stefan Karpinski, and Viral Shah set out to combine the bests of C, Matlab, Java, Ruby, Python, Perl and R in 2009—culminating in today’s programming language Julia, a potential solution to the so-called two-language problem, which happens when developers must write and rewrite a program in different languages.

Shah, co-founder and CEO of Julia Computing, says that to the extent you can keep an old system going, it’s always worthwhile, as re-writing software is extensive, time-consuming, and introduces new bugs. When the system stops doing its job, it’s time to kick it.

“If you’re writing a new system today, it’s important to think really carefully about the foundations on which you build your new system because that thing has to last for the next 30 years,” Shah says.

While the open-source movement has taken off in the last decade—the Fintech Open Source Foundation (Finos), a nonprofit whose purpose is to drive the adoption of open-source software, standards and best practices in financial services, was founded in 2014—the coronavirus is casting a harsh light on closed-source software and mainframe-based applications, used in instances such as bulk data processing and transaction processing. Open-source software is really the only way to ensure underlying code will be maintained for years to come, Shah says.

Additionally, the amount of data is growing exponentially. It was a data-driven world before the pandemic, and it will be even more so in the future. One day soon, the oldest of systems will not be able to handle the influx. That will create not only operational issues but regulatory ones too. Certain fairness and lending regulations require banks to keep a trail of what data their algorithms touched and if and how they transformed it. Banks need to be able to prove their algos aren’t biased, or giving fewer loans to minorities or women, for example.

“The amount of data is just too high. The old systems are simply not going to do that at this point,” Shah says. “And they might as well embrace the new world and the new regulations with the new systems.”