I’ve been working on mainframe development for over thirty years, and a large portion of that has been on COBOL, writes Misty Decker, Micro Focus. It’s funny, when I say that I work on and recommend COBOL to people in industry, frequently it’s met with a mix of scepticism, confusion, and also a strange reverence. “Oh really? That is interesting. Old school.” It’s a deeply ingrained attitude – an unconscious bias toward a technology that is a product of historical ‘scandals’ that have long-since proven false and simple marketing tactics to convince prospects to buy new services, infrastructure and solutions. On the other hand, I have CIOs flat out rejecting any notion of legacy or outdated systems – “these are not legacy; they are my core business”.
In most cases like this, an organisation has made significant investments in their COBOL systems over time, including developing additional IP and processes to support it. Ripping them out and starting from scratch is simply not an option without accruing mountains of technical debt.
See also: Big Iron to Big Cloud?
It’s a strange world of binaries to operate within and a challenge to rise to. More often than not, when looking at mainframes (the typical home of COBOL), what people actually see are the applications that sit on top of it. The operating systems are current, the hardware is current, but it’s those applications that can be old and further impress this idea that the entire stack is out of date. But age itself doesn’t mean inherent redundancy. The idiom of “if it isn’t broke, don’t fix it” stands true in IT teams just as much as it does elsewhere. And this isn’t a problem until you try and plug something brand new into it, running in different environments and in different languages and with new functions.
Fortunately, COBOL’s core design required it to be portable across computing devices. That core principle remains intact such that COBOL can even now compile and execute on any server environment. But COBOL hasn’t sat still for these past 60+ years. Continued investment and innovation from all manner of communities, private companies and individuals have enabled it to coexist and integrate with a wide array of contemporary technologies, including JVM, .NET, AWS, Azure and, Containers, as well as more established production server environments such as the Mainframe, Linux and AIX. Scalability and resilience of those systems is a key part of why they are adopted as production platforms, and COBOL applications can take advantage of such environments to provide the performance, scalability and resiliency that system needs.
When you recommend COBOL: Keep it open & current
At a cursory look, suggesting COBOL raises two immediate questions: Where can and should COBOL itself be used? And how do I ensure my DevOps teams can build on top of and leverage it? But for both, it’s about enabling choice: Diversity of languages used, the environments (IDEs), development specialisations, and functionality demands of applications. Recognising and supporting the preferences of the individual.
Thanks in a large part to a community called the Open Mainframe Project (OMP), developing on top of COBOL and the mainframe affords this diversity. The OMP believes that the mainframe is an active, integrated, and essential part of modern enterprise IT, consumable by mainstream developers and users, and actively driven by a vibrant open source community. Projects like its Zowe program and framework, for example, are there to provide a high level of common functionality, interoperability and user experience, and are actively supported (and contributed toward) by mainframe enterprise entities including Broadcom, IBM, and Micro Focus.
Zowe’s application framework, API mediation layer, command line interface, explorer, SDKs and more, along with its vendor conformance program, means you can have one person using ISPF and another VS Code sat in the same team, each playing to their strengths and delivering far more than if they’d been pigeonholed into one IDE. It’s interoperability and diversity at technology’s finest.
Modernise for interoperability
What many COBOL apps don't do well, I confess, is change quickly to respond to new business needs—and that's a requirement in today's environment. But this isn’t a written rule. Many companies modernise 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. Modernising provides the needed flexibility and extensibility that the enterprise demands. They just need a bit of TLC to get there!
Again, bringing it back to free resources from OMP and contributing vendors, modernisation is fairly straight forward these days. Analysing the application, identifying your service candidates, isolating and packaging the desired lines of COBOL, and finally connecting them to your new UI are the same core steps you would take to modernise any programming language and shouldn’t imprint any kind of bias against COBOL specifically.
By modernising these core applications, you can in turn take advantage of all the benefits of modern programming environments—DevOps, continuous integration and continuous delivery (CI/CD), and modern front ends. You can take advantage of all that without having to rewrite your entire core infrastructure. You might even choose to run the application in the cloud, or just use the cloud for dev and test.
That's a big benefit. It allows organisations to deploy new functions without having to rewrite all of those monoliths in a new programming language, which can cost millions of dollars only to deliver the exact same customer experience in the end. There is also the risk element to consider. Extensive research has shown rip and replace tactics achieve only a 26% success rate, and those that choose to go ahead with such a tactic frequently report low or very low returns on investment.
The right benefits
The challenge and opportunity lies in getting the best out of any technology investment (existing or future) and delivering business value. It comes down to appropriateness, defining where something is useful, where it makes most sense for the organisation. So do you have the people with the necessary skills? Do you have the technology that easily connects to the right other pieces of other, newer technology? Is it working on the right platforms? Does it provide the right throughput and robustness and reliability? COBOL ticks many, many of those boxes, and a fair candidate for a host of systems - the grown up stuff that if they fail, it matters.
But ultimately it comes down to making the right choice. COBOL is “a” choice. One that, thanks to the huge library of open source support and software from the mainframe community, still presents a compelling argument that should not be discounted.
