Early in the 2020 coronavirus pandemic, the New Jersey state government had a very specific IT staffing need—and it got a lot more publicity than hiring moves usually get. The recently passed CARES Act had added $600 to weekly unemployment payments nationwide, but New Jersey’s archaic unemployment software, written in COBOL, couldn’t incorporate the extra money without reprogramming, and there was nobody on staff capable of doing the job.
The incident was a very public glimpse at a dirty little secret within IT: There are billions of lines of code written in COBOL still running mission critical applications, but the great wave of COBOL-trained programmers who wrote all that code are aging out of the workforce. That story isn’t new—we wrote about it eight years ago, and eleven years before that.
But the COBOL era has persisted to present day, and many legacy systems have muddled on, only half understood by the companies that rely on them, after the expensive “big bang” projects to replace them failed. And now many experts are thinking of new ways to approach the problem COBOL applications present—and to develop the skills necessary to work with it.
COBOL is easier (and harder) than you think
One of the problems with conversation around the COBOL skills gap is that we often assume the existence of a distinct breed of person known as a “COBOL programmer,” as if COBOL itself is something so different from the rest of the programming world that it needs its own specialized caste. But that simply isn’t the case.
“COBOL is a red herring in this whole debate,” says Mark Cresswell, CEO of LzLabs. “It’s just a syntax for expressing business rules. Most programmers are polyglots. You might have a specialization or you might be better in one language or another, but you’re not going to say to yourself, ‘Well, I’m not going to do C++ because I’m a Java programmer.’ COBOL, as a language, is no different from any other language, really. It has its own idiosyncrasies but so do all languages.”
Keep in mind that COBOL (which was created in the 1950s) was specifically designed as a way for non-specialists to program the computers that were starting to enter the business world. “The BOL is business-oriented language,” says Emad Georgy, CTO of Georgy Technology Leadership. “It’s meant to be easy to read and easy to understand. I think there’s this huge fear around it because it does run some fairly mission critical systems, but actually, as a programmer, it’s very easy to learn.”
COBOL isn’t built around object-oriented programming and lacks inheritance features, so those who have cut their teeth on modern systems will actually have an easier time picking it up than an old COBOL hand would trying to learn Java or C++. (Although “modern” object-oriented versions of COBOL do exist, they aren’t used in the legacy systems where you’ll actually encounter production COBOL in the wild.)
In truth, when we talk about a “COBOL skills shortage,” that’s usually shorthand for something more complicated. You could, for instance, download GnuCOBOL and start tinkering with code that will run on a familiar Linux machine, but that wouldn’t prepare you for the experience of working with production COBOL code in its native habitat.
“To learn COBOL is easy, but its applications require rare expertise with legacy technology, such as IBM’s IMS and CICS database systems,” says Michael Yurushkin, CTO and founder of BroutonLab. “The key challenge is not learning the language, but having the expertise in technology that is many decades old.”
LzLabs’s Cresswell emphasizes that the modern set of tools developers have come to rely on over the past decade simply don’t apply to mainframe environments. “If I want to compile and test a program, I’m not pressing the little green arrow on the toolbar,” he says. “I’m running a thing called a batch job that does a compile and a link. When it comes to setting up a test environment, I can’t just spin up a container on my workstation to test my changes. I have to speak to systems administrators to configure partitions with arcane subsystems and configurations. All of this elongates the development cycle and is so idiosyncratic that it’s very difficult for somebody that is used to developing at internet speed on cloud platforms to get their heads around it.”
And if you’re dealing with a long-running, mission critical application, untangling the program logic may end up being your primary challenge. “All these systems have been crafted over decades,” says Ben Stevens, lead engineer and solution architect at Art+Logic, who worked for years at government agencies that relied on COBOL. “If you don’t know those ins and outs, knowing the language is only going to do so much. It ends up becoming a reverse engineering project where you’re acting as an archaeologist. Even if you know the language, it’s like you’re reading these ancient texts without any context: Okay, I can translate this word by word, but what does it mean?”
Developing COBOL skills within
So imagine your organization has a mission critical COBOL codebase. How can you make sure you have access to the skills you need—in terms of programming and mainframe environments, as well as the underlying business logic—to keep the system up and running, at least in the near term? One strategy is to work on developing skills internally. That doesn’t mean hiring fresh COBOL programmers right out of college (since those don’t exist). It also doesn’t necessarily mean retaining the graybeards full-time when they’d rather retire.
“My goal for my team would be not to teach them COBOL. It would be to teach them my system,” says Georgy. “The context is key. You want them to learn just enough COBOL. You probably won’t be doing any new projects in COBOL, so you have to be judicious about the level of investment.”
To that end, you would pair up interested internal developers with whatever resources you have on hand, with a laser focus on your particular business needs. This may involve having older developers who have worked on the application in question—maybe still on staff, maybe brought back in as contractors—mentoring younger ones.
“I like to have very specific use cases or problems that we’re trying to solve with the training,” says Georgy. “Like, ‘Look, you three, you’re going to work with this retired person who’s going to come in and spend a few hours every week. Our goal by the end of the month is to resolve this bug.’”
Developers will need to pursue a more general education in COBOL and mainframe programming as well to supplement what they learn about their own systems. IBM has an obvious interest in keeping a critical mass of COBOL programmers in the market, and offers a variety of educational resources, like free COBOL programming courses and mainframe programming certification badges. Taking these courses will occupy staff time, but you may find the investment worth it.
“Our clients also need to remember that maintaining mission critical applications that have been optimized over the past several decades does require upkeep,” says Barry Baker, vice president of software at IBM Z. “While it can be easy to cut corners or think you can squeak by without investing in talent, that is simply a recipe for disaster.”
Don’t be afraid to ask for help
Nevertheless, you may find yourself in a situation where you simply don’t have the internal resources to deal with your COBOL crisis. In those cases, you may want to turn to an outside consultancy that specializes in working with COBOL systems. Pravin Vazirani is vice president of operations at Chetu, a company that does just that, and the situations where they’re brought in to help are often fairly dire.
“There have been many cases where the core developer of the legacy platform is no longer with the company,” Vazirani says. “And the maintenance of the system is being done by a developer who has limited knowledge of the system but just enough expertise to successfully run the COBOL apps. This is usually in places that are running legacy platforms with little to no proper documentation.”
Vazirani believes that many organizations—especially smaller ones—will save in the long run by using specialist third-party companies like his. “COBOL development expertise is not as common outside of custom development firms, so in many ways, hiring an efficient, low-cost development firm can be more cost-effective for companies rather than hiring and cultivating in-house talent,” he says. “And many companies may be looking to transition away from their COBOL apps in the near or distant future, so more emphasis would be placed on bringing on in-house talent to address the future needs of the company, while a third-party handles the current system.”
Peering into the COBOL future
And what does the future look like for organizations that rely on COBOL? One glimpse comes from Misu Tasnim, executive director of digital service at the U.S. Department of Health and Human Services. She’s part of a group that’s focused on migrating government agencies away from outdated mainframe systems, and their current client is the Center for Medicare and Medicaid Services. It’s a complicated mission: these systems may be clunky to use, but they do work now, and a failed rollout could be disastrous. Government clients (like many in the private sector) have become gun-shy of attempts to replace outdated systems all at once in a big bang.
“The way the government has traditionally modernized,” Tasnim says, “is you put up this $100 million contract for 10 years, and hire a large firm because only large firms know how to navigate that size and complexity and have the staff to do it. They come in, they burn $100 million dollars, and then a decade later, you don’t have a modern system.”
Instead, Tasnim’s team is working incrementally. “We’ve decided that it’s going to be API first and it’s going to be cloud,” she says, “but you can’t move this entire monolith up into the cloud in a day.” Some components of the system are being converted to Java, while others still run on the mainframe, and no doubt will for some time.
In fact, virtually everyone we spoke to for this article saw some variation on this technique as the way forward: Functionality will be broken off of legacy systems piece by piece, with rewritten code and COBOL code running in parallel. We live in a world of distributed systems, with loosely coupled containerized microservices communicating via APIs, and mainframe COBOL applications can participate in that modern ecosystem.
Many COBOL applications already do, with varying degrees of success. Steve Hassett, president of GT Software, a provider of mainframe integration tools, says that many horror stories you hear about COBOL failures, like the New Jersey unemployment situation, may actually be about attempts to integrate mainframes with more modern systems. “When they say the systems are overloaded, that’s probably attributable to all the connections to the other systems that were designed for 1% of the volume that they were seeing,” he explains.
Hassett’s company is one of many in the industry looking for ways to do these integrations right. “Accept your legacy COBOL mainframe system, understand what it’s good at and give it more of that to do,” Hassett says. “Don’t try to take away the things where it’s just doing repetitive transaction processing and then build your new capabilities in the cloud, still connecting to a modern cloud-based system. If you’re trying to do accounting at a bank and keep track of deposits, you can do that really well on COBOL. If you want to initiate a real-time payment, you probably need to connect to an outside system.” GT Software provides tools to help clients make those connections, using a drag-and-drop GUI.
Mark Cresswell’s LzLabs approaches the problem from a different angle. They’ve developed a virtualization layer that serves as a “software-defined mainframe” and allows COBOL code to run in a standard Linux environment. “The program can make file calls using a mainframe file access syntax,” Cresswell says. “It can access relational databases using a mainframe relational database syntax. It can interact with online environments using the same syntax that it would if it was running on a mainframe. But under the covers, you’re just using open source all the time, which means you can containerize it and you can flow it through a CI/CD pipeline in a standard way.”
Containerizing the application is the first step towards breaking off bits of functionality and rewriting them with more modern languages, while maintaining some components as COBOL as needed. In fact, LzLabs’ technology allows you to port over binaries from mainframe systems—something that’s often necessary for truly long-running legacy systems. “There are a great many companies out there that can’t reliably find their source code for these applications,” Cresswell says. “It’s just like a black box. They can identify that 30 or 40 applications are dependent upon it so they’ve got to have it. They’re just not quite sure what it’s doing.”
The time to learn COBOL is now
This is the future of COBOL, then. These systems won’t be replaced in the next year or two with something shiny and new, as the result of a triumphant, transformative project. Rather, COBOL applications will fade out slowly, with some components replaced but others still humming along for years, either on mainframe hardware or perhaps in virtualized environments.
Companies that depend on COBOL applications need to stop pretending that the COBOL era will end any day now and start making decisions for the near-term and medium-term futures. Either they need to budget for the outside consulting services they’ll need, or they need to start developing those in-house skills, identifying developers interested in being mentored on the legacy systems’ business logic and diving into COBOL’s quirky syntax and operating environment.
Not everyone will be interested, but for some developers COBOL will represent an intriguing challenge.
“Learning new programming languages—and specifically learning programming languages that are significantly different from the ones you already know—is a great way of exposing yourself to new ideas and new ways of thinking,” says Mike Loukides, vice president of content strategy at O’Reilly Media. “From that standpoint, COBOL fits the bill perfectly. It’s different, it looks strange, it has a lot of important ideas about financial computing embedded in it, and you probably haven’t been exposed to those ideas if you’re limited to JavaScript and Python.”
Those who want to take the COBOL plunge will have a bankable skill in an important niche for years to come.