Why the Problem with COBOL Isn’t COBOL

by | Dec 10, 2020

There’s been a lot of talk this year about COBOL and the systems that run it. As a recent InfoWorld article explains, IT’s dirty little secret isn’t all that dirty.

After all, there’s nothing wrong with COBOL. It’s merely a programming language, like Java or Python. Some even argue that a COBOL talent shortage isn’t a real problem. It’s relatively simple to learn. Any modern programmer would have an easier time learning COBOL than someone who only knows COBOL would have learning an object-oriented programming language.

In reality, the expertise missing is the experience to read and write for technology that is many decades old. What’s needed is understanding all the ins and outs of a specific business’s unique IT environment as it’s evolved over the decades. When something goes wrong, this is exactly what you need someone to know.

According to the article, there are several ways to tackle this problem. You could:

  • Develop just enough skills internally to make it work
  • Bring in a retired programmer to mentor the younger ones
  • Outsource the talent from a third party when needed
  • Update your COBOL applications
  • Integrate the old with the new

Of course, we help with the latter. We suspect that many horror stories associated with COBOL happen when someone tries to integrate the mainframe with a modern system without the right tools. If it appears systems are overloaded, that’s probably attributable to all the connections to the other systems designed for 1% of the volume they’re experiencing. According to Adaptigent’s President:

“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.”

This way, you’re not asking a system or a programming language to do what it was never designed to do.

Click here to read the full InfoWorld article.