Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Why enterprises are adapting their COBOL apps vs. ditching them

public://pictures/johanna.jpg
Johanna Ambrosio Contributing Editor, TechBeacon
 

If 60 is indeed the new 30, COBOL is still in its prime—and many customers are taking advantage of that fact by modernizing their legacy applications to use today's technology, from cloud to XML and DevOps.

COBOL's been in the news recently, blamed for delaying some US states' unemployment payments in the midst of the worldwide pandemic. But some observers say that COBOL has taken the heat unfairly and that the fault lies instead with stodgy hardware, website overload, and other front-end-related problems.

Nevertheless, the COVID-19 pandemic has raised questions about the status of COBOL apps in general. And, it turns out, most of these apps are not going away anytime soon. More enterprises are adapting their legacy COBOL systems to the needs of the digital enterprise than ditching them. COBOL is becoming part of digital transformations.

Here's why making the decision whether to replace or modernize doesn't really have anything to do with the perceived COBOL programmer shortage, and some approaches enterprises are taking.

Why COBOL persists

Some 220 million lines of COBOL code continue to run major transactional systems, reports Reuters, primarily in financial institutions, government agencies, and healthcare firms, among others. And some 43% of banking systems still rely on the language.

Generally speaking, these apps are core to the business, run without any problems, and are tied to critical data, said Bill Henshaw, founder and CEO of COBOL Cowboys, which provides technical support and programming expertise to clients.

"COBOL is running the world because it's very stable."
Bill Henshaw

Mainframes, the back-end computers on which COBOL apps run, are also prized for their resiliency, security, and scalability.

Plus, the apps (and the mainframes they run on) represent a significant investment that most companies are loathe to shelve; it's difficult if not impossible to make a successful business case for spending millions of dollars to re-create the same app on a different platform. There's also a significant amount of risk in trying to do so.

Another factor is that COBOL is updated regularly and is overseen by the ISO standards group. It's not controlled by any one vendor.

What COBOL apps don't do well, however, is change quickly to respond to new business needs—and that's a requirement in today's environment. To address that, many companies plan to modernize their COBOL apps, some as part of their overall business transformation efforts and some as a means of aligning legacy systems with their digital transformation strategies.

Overall, 71% of companies using COBOL plan to modernize the apps themselves, the delivery process, or the underlying infrastructure, and 63% plan to modernize legacy COBOL systems this year, according to a February 2020 survey by Micro Focus. Nearly 600 COBOL-connected architects, software engineers, developers, development managers, and IT executives from 40 countries participated in the survey.

Certainly, some COBOL apps are being replaced or retired (36%, the survey said), and some are being simply maintained as they are, with no major changes planned (48%). But the COBOL application codebase is also growing among respondents, to 9.9 million lines of code, up from 8.4 million lines of code in 2017, the last time the survey was conducted.

What COBOL programmer shortage?

One factor that doesn't really play into this situation, at least any longer, is the idea of a COBOL programmer shortage. The theory was that as baby boomers retired with their COBOL knowledge, the apps they created would be stranded, with the existing workforce not able to fully understand either the source code or the underlying business rules.

While the original subject-matter experts and programmers are still preferred when it comes time to transform the apps, there's no major shortage of COBOL programmers. (A large part of the brouhaha can be traced to the Y2K issue, when there was understandable concern that vintage apps would not be updated when January 1, 2000, rolled around. Hospitals, financial institutions, and government agencies were seen as particularly vulnerable.)

The COBOL programmers' Facebook page counts over 14,400 members, and it continues to grow. Dice, the employment site, has 4,000 COBOL specialists and another 8,000 who have some experience with the language, according to Paul Farnsworth, chief technology officer of DHI Group, Dice's parent company. Many of today's COBOL programmers are cross-trained in Java; cloud systems, including Microsoft Azure and Amazon Web Services; and XML.

"[Most of the current crop of COBOL programmers] are likely working in a role practicing another set of more current skills, although it's fair to say there is still a need."
Paul Farnsworth

And while traditional COBOL has a different structure than modern languages, it's not hard to learn, said Mark Conway, director of the office of the CTO at Micro Focus." Once you've cracked data division, you're largely there. The concepts are far easier than lambdas, promises, and async, found in other languages."

And modern COBOL is even easier to learn, which is another reason why Conway says COBOL code isn't going anywhere. It supports many of the language features from C# and Java, and can run directly on .NET and Java platforms (compiling to respective byte code representations). "This allows in-process mixing of languages, and the ability to naturally exploit the power of these ecosystems. It's also fully backward-compatible with old COBOL."

Conquering COBOL transformation

The first critical task in modernizing is to understand and translate the COBOL apps' underlying business rules into English, and that's something that can be "crazy complex," said Rob Terranova, president of AveriSource, which sells software to automate legacy source code analysis and business rule extraction. His company's process can take from one to four months, and that doesn't include the time needed to incorporate the business rules or source code into other, newer programs.

One reason is the number of lines of code involved—which can run in the millions for any given application—and missing or nonexistent documentation.

A COBOL program with 10 million lines of code may yield 2 million to 5 million business rules, and from 30% to 70% of old programs are typically dead or redundant code.
Rob Terranova

Several companies provide this as a service or via on-premises software toolkits.

However you approach it, skip this step at your peril, said Derek Britton, product director for mainframe solutions at Micro Focus. And it's not just about discovering the composition of the core applications but the interrelationships between programs, data layer, UI, and other application assets.

"Automating that process is vital."
Derek Britton

This is especially true for refactoring, Britton said, "which automates the process of discovery, isolation, extraction, and reuse of business rules as new API-level services." Automation is key for a process that can be akin to reading "more than a dozen copies of War and Peace"—and that's for a relatively "modest" application of only 1 million lines of code, he said.

How AI will help

Artificial intelligence stands ready to assist with this challenge. COBOL Cowboy's Henshaw is working with an R&D organization (which he declined to name) whose tool will launch in around a year, he says. The app documents details of the code, and draws pictures of interrelationships so a new employee can "go through all the lines of code and see what they need to know."

"It gets down to which programs touch which data fields—customer names, last purchase dates—and which routines do what," he said. The goal is to reduce the need to train new programmers specifically on COBOL, although there is more help with that. The free-of-charge COBOL Training Program was launched in April, from the Open Mainframe Project, to help get new programmers up to speed.

There is also at least one commercial AI-based COBOL discovery tool in beta, he said.

Other modernization steps you can take

Once the original source code is translated or discovered, there are many different paths to modernization, Micro Focus' Britton said: UI improvements, agile methodologies, cloud adoption, containerization, test automation, API creation, web services, microservices, connecting to mobile apps, and others.

One way forward is to create REST-based APIs to extend your legacy applications. Some commercial integrated development environments (IDEs) include COBOL alongside Java, Eclipse, and/or other languages. GitHub and SourceForge offer several open-source IDEs and compilers for COBOL.

Another option is to use containers to "wrap" the apps so they can run in the cloud, among other things. For the really ambitious, some suggest that breaking existing monolithic apps into microservices is the only way to go, so that legacy applications are architected to be fully extensible in any platform the business ultimately decides to adopt.

Whichever path you take, don't underestimate the time and effort required. COBOL Cowboys' Henshaw remembered one app he was asked to help modernize; it helped authorize hunting and fishing licenses in 15 US states and Ontario, Canada.

"They decided to move off COBOL and figured they'd do it in a year. Five years later, they were still at it."
—Bill Henshaw

The tools have improved since then, but even so, it's best to think of this more as a journey than a one-and-done project.

Finally, it's important to have C-level buy-in, something that seems to be happening more of late. Up to one-third of COBOL modernization undertakings are driven directly by top executives, according to the Micro Focus survey, "which suggests the ongoing strategic nature of those projects," Britton said.

"COBOL appears to be a more and more valuable weapon in the arsenal as organizations fight their way toward digital transformation."
—Derek Britton

Keep learning

Read more articles about: App Dev & TestingApp Dev