Some programming languages come and go, while others come and stay for a while. In the case of COBOL, “a while” means more than six decades: The language debuted in 1959 and is still alive and kicking. In fact, the consultancy COBOL Cowboys says that roughly 90 percent of Fortune 500 firms have production systems that rely on COBOL code.
COBOL is a great litmus test of your notion of “legacy” applications: If you’re using the term as synonymous with “old,” you’re right in the sense that the language is now, in human terms, in its golden years. But if you’re using “legacy” to automatically mean “outdated,” that’s far from a given.
“COBOL is an established programming language,” says Bhabani Misra, an associate dean at the University of St. Thomas in St. Paul, MN, where he oversees graduate programs in the software engineering department. “Applications written in this language touch everything we do, from airline reservations to healthcare and phone calls. These applications solve thousands of problems every day.” COBOL is also widely used in government IT organizations.
[Which IT jobs will position you well for the future? Read also: 5 flourishing and 5 fading IT careers. ]
COBOL is not going to excite developers who write cloud-native applications to run in Kubernetes. But that doesn’t negate the value of many longstanding and often mission-critical applications. Is transaction processing – especially when the volume of those transactions is high – a fundamental requirement of yours? Guess what, COBOL still does that well.
Jeff Hall, senior consultant at Wesbey Associates, cut his teeth in IT writing COBOL applications. He notes that because there will always be newer, shinier languages, some mistakenly assume that COBOL has become obsolete. Worse, they assume it was “abandoned” because it was a poor language. Not so, according to Hall: “It was not a poor tool and never was.”
Two reasons COBOL gets a bad rap
Two big factors underpin the misconception that COBOL is “bad” in some way.
1. COBOL applications tend to be large monoliths – very large, in the case of decades-old systems.
“The biggest problems organizations face with COBOL is the amount of code they have written in COBOL,” Hall says. “ In an organization with applications written in COBOL, there are typically tens to hundreds of millions of lines of code.” Those millions of lines of code represent years of business rules and logic, which is why many companies are reluctant to replace those systems, Hall explains.
Mike Loukides, VP of content strategy at O’Reilly Media, notes COBOL was born before more flexible approaches to software development, such as microservices architecture.
“COBOL was invented before we understood the importance of making programs that were modular or had the tools to do it,” Loukides says. “Monoliths aren’t necessarily bad, but they’re certainly hard to understand. They’re hard to modify as you need new features – and they tend to become even harder to modify over time.”
2. COBOL seems stuck in a perpetual cycle of skills shortages. It most recently made headlines again as unemployment claims skyrocketed during the COVID-19 crisis, and state systems sagged under the weight of the demand. The governor of New Jersey, for example, put out a public plea for COBOL programming help. (In response to that talent need, IBM is offering free open source training on this skill.)
“Every few years an alarm goes up about the shortage of COBOL programmers. And then it dies down,” Loukides says. “It’s hard to tell whether that’s because programmers are found, or because other solutions are found.”
Misra says there’s a relationship between COBOL’s age and the age of most programmers with deep expertise in the language.
“Individuals with a COBOL skill set are nearing retirement, and many companies are realizing they don’t have the candidates with the appropriate skills to keep COBOL functioning,” he says. As a result, companies are being forced to get creative and redirect talent from elsewhere in the organization, sometimes working in partnership with universities like Misra’s to develop new skills. The other choice: Application modernization projects.
4 factors to weigh before modernizing a COBOL application
For IT leaders weighing COBOL modernization projects, these are rarely simple go/no-go decisions. There are plenty of legitimate reasons why an organization might opt to stick with their COBOL systems, just as there are plenty of reasons why it might decide it’s worth the costs and effort to modernize – or replace – a COBOL application.
With that in mind, experts shared four important questions to consider when you’re evaluating whether or not to modernize a COBOL system, starting with the talent concern.
1. Do you have the talent /skills needed to properly maintain the application?
First, some good news: There are plenty of resources for COBOL training, including university courses, boot camps, online education, and other options, Loukides notes. (O’Reilly, known in the tech industry for its publishing, conferences, and training programs, offers Beginning COBOL for Programmers, for example.)
But that doesn’t mean there’s a bountiful supply of COBOL talent out there itching to keep your systems running well.
“If we’re having trouble finding COBOL programmers to maintain code today, what will that look like in 10 years?” Loukides asks.
There’s another way of looking at the talent question: How many COBOL programmers do you currently have working on your application(s)? Do you have a large cohort of programmers nearing retirement? Conversely, if the answer is “one COBOL programmer,” you should ask: What happens if that person leaves?
Software engineer Randy Ryschon was the sole developer responsible for a billing system written in COBOL that he’d maintained and updated for 24 years. The company’s eventual decision to replace it was based on that basic reality.
“Although deemed legacy, it successfully billed $80 million per year with growing revenue,” Ryschon. “I was the sole developer, which drove the decision to migrate.”
2. Why are you modernizing or migrating?
“Because COBOL is old” is, on its own, not a great reason to undertake a modernization effort. In fact, it might be a terrible reason.
CIOs and other IT leaders need to look at this choice from a cost-benefit perspective, Misra says. The latter should significantly outweigh the former; otherwise, you might be undertaking a heavy-duty project to achieve outcomes that don’t produce significant business value. Ryschon points out that you also need to consider how much time you have to devote to the project: Depending on the particulars, you could be looking at a multi-month or even yearlong-plus process.
If you’re looking at a COBOL system as part of a broader modernization of your application portfolio, then you also need to answer the “why” question in relationship to “when.”
“I always point people to Figure 2 on page 28 of the Federal CIO Council’s Application Rationalization Playbook when prioritizing what should and shouldn’t get modernized,” says David Egts, chief technologist, North America public sector for Red Hat. “Is the application providing critical business value? Is it going to be retired soon? No sense modernizing something that adds little value or will be replaced with something else in the near future. The same goes if you have applications in need of modernization that would have a greater impact on service delivery.”
There are various ways you can frame the big picture questions of “why” and “when” to potentially modernize or migrate a COBOL app. Todd Loeppke, lead CTO architect at Sungard AS, shares two examples: “Are there better ways to accomplish the same outcome?” and “What is the current solution lacking?”
“There could be a need for improved security, zero downtime upgrades, improved performance, better resiliency, better integration with the company data lake so that AI/ML tools can be utilized, et cetera,” Loeppke says. “Can we accomplish this with the existing platform?” If the answer is “no” or “only with great pain and difficulty,” he says, you might have a modernization candidate.
Ryschon shares some related development-oriented questions to consider: “What is the system doing or not doing that warrants the need for change?” and “What is the general quality of the code?”
Evaluating your project should start with a robust list of such questions; then you can appropriately weigh the answers against the alternative of sticking with the current system, Loeppke says.
Let’s examine two more important questions you should ask:
Comments
As the article states, "legacy" is a statement of origin date, not any actual evaluation of fitness; many such systems are long-lived and represent a laboriously evolved, detailed understanding of the business involved. Often, the effort required to replace such a system is woefully underestimated.
By contrast, it is frequently possible, at far less cost and disruption to undertake a modernization project which provides more up-to-date interfaces and capabilities, while retaining the hard-earned knowledge embodied within the existing codebase. Since the re-engineered result can preserve its place in the existing application ecosystem, qualification of the improved application is less complicated and costly.