Within the realm of technology, one thing that could generally considered a static rule of thumb is that things are constantly changing. Innovation, especially in the cloud era, is constantly occurring and hard to keep track of, as one trend displaces the last in an ever-quickening game of technological leapfrog. This is equally true when it comes to software development, as cloud native organisations chase seamless CI/CD pipelines, DevOps, and agile development practices.
Bucking this trend, though, is the COBOL programming language, which — despite being developed in the late 1950s — still fulfills a fundamental role for many organisations running transaction-based legacy business applications. The aging language is still remarkably pervasive, to the point where news reports surface every few years denouncing its existence within business-critical systems while highlighting the various issues that COBOL code presents to organisations and developers.
The persistence of COBOL has been illustrated recently as the Coronavirus pandemic puts increased strain on wide range of IT infrastructure. The programming language was highlighted as a major issue in the US government's $2.2 trillion CARES stimulus program and within the processing of increased unemployment claims, with state agencies blaming delays in cheque handouts on COBOL, and in particular a lack of available talent (which is often a real sticking point). IBM even sought to address this issue by teaming up with the Linux Foundation's Open Mainframe Project by launching a free COBOL training program as well as a technical forum allowing COBOL programmers to provide free advice and expertise during the outbreak.
While this may seem to paint a picture of a hopeless old language that is unnecessarily stifling innovation, the persistence of COBOL is more nuanced that it may seem. There are many relevant factors that contribute to why organisations might want to keep COBOL around and it's not just as simple as gutting and sending it into oblivion. Although that's not to say that there aren't some serious issues with the language — and the culture that surrounds it — that need to be addressed.
Why is COBOL still so prevalent?
COBOL was initially developed in 1959 as a business-orientated programming language that ran almost exclusively on large mainframe computers and served as an incredibly useful tool in modernising what were often paper-based business processes. The language was commonly used for transaction-based processing and continues to power many finance and administrative systems used by banks and the public sector.
According to Reuters, 220 billion lines of COBOL code remain in use today and this is showing no signs of slowing down. The reasons behind this are mixed, but a lot of the time it comes down to the fact that it's quite difficult to present a compelling business case to rip and replace COBOL. It's incredibly expensive and complicated to do so given how entrenched it is within the mainframe environments, and the decades-old monolithic nature of the applications themselves - as illustrated when the Commonwealth Bank of Australia replaced its core COBOL-driven banking platform in 2012 at a cost of over 1 billion Australian dollars (749.9 million USD).
Another reason COBOL has carried on so long is simply that the applications can actually work exactly as they need to and the language isn't necessarily obsolete. Derek Britton, global head of product marketing at COBOL custodian Micro Focus illustrates this point, arguing COBOL's original use-cases are still just as relevant today as when it was first developed.
"For COBOL, the classic use-cases for a language - which is famously designed for 'business applications' - are fairly self-evident and remain as true today as they were throughout COBOL's history. COBOL applications are the lifeblood for some of the world's most successful organisations and also run countless government departments across the globe," Britton says.
"These are applications that match COBOL's capacity for data-heavy work (needing to access, process, manipulate, and report on large amounts of clearly-defined, structured data), significant arithmetic or processing activities (handling complex numeric calculation, without error), and working at speed and scale (handling millions of transactions in a short space of time). It is no surprise COBOL remains a bedrock in banking, insurance, healthcare, logistics and many other industries."
Which industries are still reliant on COBOL?
As mentioned, there are a few key industries that rely on COBOL infrastructure, with application footprints being significant within the financial sector, government services, telecommunications and healthcare. Bola Rotibi, Research director at Analyst firm CCS Insight says these sectors are the ones that are most hungry for COBOL developer talent, due to the nature of the language and its proficiency within their business dealings.
"COBOL applications are mainly used in transaction processing applications, hence a staple of the Financial Services sector and other industries that rely on processing a large volume of transactions quickly, and often in batches," Rotibi says.
"Government services responsible for calculating tax receipts and returns and making benefit payments to citizens, as well as airlines handling the ticketing of passengers, rely on transaction operations that need to be highly performant and reliable. This is a key reason why their COBOL applications remain crucial to their business operations."
As one of the major COBOL implementors, the financial sector was one of the most evidently impacted as a result of the COVID-19 pandemic. According to Vilve Vene, CEO and co-founder of European fintech Modularbank, COBOL reliance and the associated skills challenge was one of many issues that became evident as a result of the outbreak.
"The issue that comes with systems running on COBOL is that opening up these systems to the outside world is a very lengthy, complex and costly process," Vene explains.
"So far, we have seen banks investing huge amounts of money to revamp their legacy systems by building additional layers on top of it. However, this is not an effective solution to the problem as COBOL was not fundamentally built to support the flows of real-time demand."
While Vene argues that COBOL, as well as all legacy bank infrastructure, should be eventually replaced with more modern architectures for competitive reasons, she says this will have to be done gradually "in order of priorities" as replacing the whole system would be too disruptive.
The extent of the skills shortage
While the skills shortage may be most evident during major demand ‘spikes', such as those driven by COVID-19, the issue has remained a concerning talking point for decades now. The lack of talent is driven by a few key factors, but one of the most significant ones the scarcity of education, considering computer science courses at universities largely don't teach the language anymore, resulting in a serious lack of new, younger developer talent.
The skills shortage around COBOL remains quite a serious issue for many organisations, not only because many developers aren't familiar with the language, but because COBOL work generally requires a high-level, specific, and intricate understanding of the COBOL application environment. Keith Banham, mainframe R&D manager at Macro 4 and 40-year mainframe technologies veteran elaborates on this issue, framing the skills shortage as a "crisis" that does deeper than the language itself.
"It's important to recognise that the skills crisis is not simply about a shortage of people who understand how to code in the COBOL language. The deeper issue is the lack of application knowledge. Being able to code in COBOL is the first step. The really hard part is understanding what an application does. If you don't have that knowledge you run the risk of making mistakes," Banham says.
"An experienced COBOL developer with knowledge of an application will understand, for example, how changing code in one part of a system will affect another part. When you lose that experience, new developers are unaware of the implications of making changes."
One example of this is the use of copybooks by COBOL programmers, which allow them to insert the same section of code into numerous places within the system. Anyone who updates that shared code needs to understand exactly how their changes will affect all of the different parts of the system. This kind of extensive previous knowledge is massively important in the world of COBOL, to the extent where organisations have previously clung to elderly COBOL programmers because they hold the "keys to the kingdom", so to speak.
Should developers be learning COBOL now?
From a developer's perspective, COBOL can be a very useful language to learn, as it is still so widely used by some of the world's largest enterprises, with the vast majority of business applications running on IBM mainframes containing COBOL code. Sean Farrington, SVP of EMEA for SaaS technology training platform Pluralsight says the continued popularity of COBOL presents an attractive opportunity for prospective developers, as having an understanding of both COBOL and more modern languages is a skillset worth having.
"Despite its age, COBOL still underpins many of the finance and administrative systems used by banks and the public sector. Without the skills to work with COBOL, this legacy code cannot be maintained - and it cannot be modernised or updated either," Farrington explains.
"For example, if traditional banks want to keep up with agile fintechs, having the talent in place that can work with both COBOL skills and newer languages is key. Whether it is translating COBOL into a modern language like Java or Python without losing functionality, or integrating COBOL with new tools, expertise in the language is still required. And with billions of lines of COBOL code still in use, it will likely be a skill that developers will benefit from having for years to come."
However, while the job opportunities can be solid and extremely safe options for COBOL developers, the work can be relatively uninspiring. As developers are sought after, COBOL talent can often be pigeonholed in a sense, with little opportunity to expand their horizons. For those devs looking to work in a fast-moving, modern ‘start-up' like environment, a job maintaining decades-old COBOL architecture can be a hard sell. It can also be quite difficult to get started with for developers, as the syntax varies quite considerably to other languages.
Longevity of the language moving forward
Given it's widespread, permeating nature within key industries, it's unlikely that COBOL will be disappearing altogether any time soon. Fundamentally, there is a whole ecosystem of tools and services that have grown to support and maintain the longevity of COBOL applications.
According to Rotibi, while there have been extensive efforts to streamline the language for modern development approaches, she still expects a subtle, gradual move to update COBOL infrastructure across the board.
"I do think that there will continue to be a steady long term move to modernising existing COBOL applications. But this will come in the context of an organisation's digital transformation strategy and also in weighing up the cost benefits for redesigning an existing COBOL solution," Rotibi says.
"Many COBOL applications continue to be fit for purpose with regards to the business logic and transaction they support. Great strides have been made in evolving the core platforms that run COBOL applications enabling them to meet the operational performance requirements for modern transactions and application solutions. Even though some effort has been made to modernise some aspects of the COBOL language, I think that there are plenty of modern software application technologies available today that more than meet the needs for the kind of applications required going forward."
However, Rotibi reinforces that this won't happen overnight, and that the language will not fade away, noting the billions of lines of code still in production environments. The efforts to modernise COBOL itself she refers to have also cemented themselves amongst CIOs as extremely viable alternatives to ripping out the language and associated mainframes completely, due to the associated cost savings. Many efforts have been made to bring COBOL into the 21st century, including solutions that facilitate COBOL to run alongside JAVA on mainframes and even a recent push to get the COBOL applications to run as containers on Kubernetes.
As a further example, Sam Knutson, vice president of product management at Compuware says IBM's efforts to update COBOL's compiler has allowed the language to persist through the ages.
"What's unique about COBOL is the compiler, which IBM has done a masterful job at continuously improving every few months," Knutson explains.
"These improvements have ensured COBOL's consistent speed and performance and helped to fine tune machine code so that it can most effectively and efficiently drive the latest and greatest compute resources on the mainframe. That's why the world's economy rightfully runs on more than 220 billion lines of COBOL code, and that number is increasing every day."
However, regardless of whether COBOL has a bright, bland, or bleak future ahead of it, one of its major issues is around the culture that generally surrounds it. If organisations want to maintain an adequate talent pool of COBOL developers, the language and associated infrastructure needs to be modernised somewhat so that it's an easier sell to developer talent. At the end of the day, the last thing modern developers want to do is work on a single, aging, idiosyncratic language, doing maintenance work for the rest of their careers.
"If the traditional developer experience on the mainframe is still in use - notorious for siloed culture, rigid, experiment-averse processes and text-based ‘green screen' tools - organisations can't expect to attract the talented next-gen programmers they desperately need to commit as the next stewards of their mission-critical COBOL applications," Knutson continues.
"They cannot count on talented new developers to pay a personal tax in time, effort and inspiration for digitally subpar culture, processes, and tools in the face of escalating expectations. This is the same as hoping competitors will throttle their own innovation to ensure a rival organisation has time to catch up; it's never going to happen."