Written by Cameron Seay, Open Mainframe Project Governing Board member, co-chair of the COBOL Working Group and Adjunct Professor at East Carolina University
This content was originally published on the ASG Technologies’ blog.
Why are Large Enterprises Still Using COBOL?
Large enterprises – public and private – made enormous investments in automation over the past few decades, starting with COBOL (COmmon Business Oriented Language). At the time (the 1960s), COBOL was the best available tool. It was, and is, well suited to the typical data processing that enterprises in insurance, banking, financial services, and public services (e.g., government) do:
- Personally identifiable and demographic information management
- Accounts and balances management
- Abstracting and formatting reports, statements, and other communications
It is an indisputable fact that these programs capture and execute much of each enterprise’s unique commercial and public service posture. It’s equally indisputable that it may be difficult to abstract those unique business rules and port them to another application language or operating system – and hold innumerable exceptions to those rules, as applied over years of short-term objectives.
Having said that, we must recognize that these mission-critical applications just work. Despite all the complaints, they accomplish the tasks efficiently and effectively. They should be viewed the same way we view the roads in the interstate highway system – there are stretches that were laid decades ago, and, while imperfect, they are recognizably adequate for the amount and type of traffic they carry. Should every mile of concrete and asphalt be torn up and re-laid along the same paths, just because there is newer road surface technology available?
This is not to say that coding practices for applications developed decades ago – yes, there is still mainframe code from the 1970s that is still executing today in the financial ecosystem – were as elegant and thoughtful as they should have been. Decades ago, there was a lack of internal code documentation, decisions to cut corners for short-term financial benefits, spaghetti logic from poor coding practices resulting from poor training, and overburdened coders.
Still, while the IBM/mainframe line item(s) in the budget may be sizeable numbers, the financial benefits of deconstructing these large programs so they can be refactored in other languages and deployed on other technology stacks are questionable. It can take years, sometimes decades, to break even – and that’s before accounting for the institutional risk to reputation, failures, false starts and incorrect outcomes, as well as the professional risks for individuals who are responsible for the projects. It is a hard balance to find, particularly for the largest enterprises with the greatest dependence on them.
All that said, there are enterprises who bite the bullet and take the risk, with varying degrees of success – from seamless transition to abandoned efforts. While my above stance may seem parochial, I do see some positive, impactful trends. Namely: encapsulating mainframe applications behind APIs so that changes don’t have to be made all at once. Once encapsulated, complexity analysis tools can be applied to help automate the deconstruction of large COBOL programs as a first step to making changes. Results of the analysis can be used to help IT professionals make informed decisions about what functions can be better served from a less expensive – though possibly less reliable, available, and serviceable – technology stack. Those functions can be refactored as microservices that stand behind the API and minimize the disruptions.
Are Younger COBOL-skilled Professionals Emerging?
Certainly! Nature abhors a vacuum, and the market will drive what skills are available and the compensation they will command. Some changes – in terms of geographic location, cultures, and customs – are inevitable, though rest assured that young IT pros are recognizing the opportunity that working with mainframe represents.
In fact, I see them stepping up to the challenge everywhere I go – at SHARE in the U.S., Guide Share in Europe, at our customers’ data centers and in our own ASG development sites in Chennai and Hyderabad. If you want to see and hear some of the successes, follow Cameron Seay, Ph.D., on LinkedIn and other social media. I am greatly impressed with his posture and voice to all of us.
It is fair to say that an IT pro with five years of experience with COBOL programs may not be able to sit down and immediately understand all the COBOL of an application that originated 30 years ago. Though it is equally fair to say they likely come better prepared by their education and with better tools than their retiring predecessors did at the same five-year mark in their careers.
My Take?
We can decry decisions and poor coding choices made by our predecessors in the enterprise. However, things are what they are. Our best path forward is to set aside that negative thought and apply critical thought to what works well in the enterprise – and what can continue to work cost-effectively.
For more COBOL Resources:
