A good workman never blames his tools for a bad job; so when the half-century old programming language COBOL got some unwarranted press lately, I thought I should look into it.
Due to economic stimulus measures, government systems have seen massive strain under a crushing surge of unemployment applications. The call from the Governor of New Jersey for COBOL programmers to volunteer their talents led some reporters to grab the #COBOL momentum to question why these decades-old applications running on mainframes are even still in use?
Their criticism was quickly snuffed out. Why? Quite simply, it is because these systems were built and refined over decades to reliably work. As Klint Finley aptly notes his Wired Magazine article: “Don’t Blame COBOL, [the] more likely cause for those error messages was overloaded web servers.”
Just because something is old doesn’t mean it’s the problem and should be replaced. The reason so many governments, banks, insurers, airlines and retailers still use COBOL mainframe applications is because they are competitively unique and have proven reliable time after time.
In finance alone, mainframes process nearly $8 trillion in payments a year. And amazingly, 80% of the world’s corporate data resides or originates on mainframes. There is good reason that mainframe applications fuel the success of the majority of the global Fortune 500.
Unfortunately, what does ring true in many of the articles – aghast at the age of these applications – is that many COBOL programmers are approaching retirement. To compound the decline in talent, enterprises don’t invest in developing (or paying) for COBOL skills. Instead, some have attempted to re-write these custom applications into other languages such as Java – where programmers are a dime a dozen – only to fail after years of work and hundreds of millions of dollars wasted.
So, what’s to be done with these decades-old applications that just happen to work really well? It’s possible we will see a resurgence in COBOL programmers when companies realize they can’t just ask for volunteers to code their applications, and they must start paying for talent. But for now, there are solutions to improve the user experience and add capabilities to your COBOL applications – that also extend the existing application business logic and back-end mainframe data to new channels, apps and services … without having to know how to code in COBOL.
To learn more about using industry standards – such as Application Programming Interfaces (APIs) and Structured Query Language (SQL) – to connect your COBOL applications and mainframe data to the future of your business today, visit www.mainframeconnect.com and watch our webinar.