Blog article
See all stories »

Cobol - do banks speak our language?

With yet another banking glitch affecting UK customers last week, the answer to that question must be an emphatic “no”! And with banking failures happening on a seemingly weekly basis, we perhaps should be examining the language they speak more closely.

Most of our banks are built on systems and programmed with languages that pre-date the birth of the Internet, let alone the birth of mobile banking. Cobol, a language created for business use, has been around since the year dot, in tech terms – I remember using it fresh out of college in the 70s and 80s. It’s the IT equivalent of hieroglyphics. 

Given the massive leaps that have been made in banking in terms of digital and mobile services in the last ten years, it is even more remarkable that these developments have happened, despite banks being built on systems using a language that was in use in the 50s and 60s.

 Back ten years ago when it was less “online banking”, more “pay a cheque in and wait five days for it to clear” it didn’t really matter if banks suffered a system failure. Or at least, system failures were not as apparent to the customer as we didn’t engage with banks the way we do now. But in the era where banking has become 24/7 and the sheer immediacy of it means that people want to be able to access their bank account any time, any place, anywhere, the cracks in Cobol and the technical glitches it causes, are clearly visible.

And the problem is that nowadays, it isn’t just a niggly issue between the bank and its customers. The birth of social media has meant that technical glitches and failures in customer service quickly escalate to become an onslaught of online customer anger, which inevitably makes front-page news.

Another problem with Cobol is that it rarely features on computing degree courses. These days it is all about Node.js or Python, languages that are more in tune with our current digital environment. But the fact remains that it is the third most widely used language in financial services applications, second only to the much newer tool Java (according to research from CAST Software). This means that the Cobol programmer – an increasingly endangered species – is more in demand than ever.

So what’s the solution? Do banks carry on patching up problems with Cobol and their legacy systems? Or do they cut their losses and replace their core banking systems? The cost to do this would run into the hundreds of millions, the main reason many banks haven’t taken the plunge. So maybe, the smart choice for school leavers these days is to opt for a course in Cobol. It’s going to be around for some time yet. 

 

3990

Comments: (2)

Murray Heldon
Murray Heldon - Tata Consultancy Services - Sydney 14 September, 2015, 03:00Be the first to give this comment the thumbs up 0 likes

The writer provides no basis for the assertion that COBOL is the cause of the data breaches. In fact there is no real analysis in the article at all.

Matt Scott
Matt Scott - Fiserv Inc - London 14 September, 2015, 15:38Be the first to give this comment the thumbs up 0 likes

I think the points are:

  • Dwindling (and expensive) resource pool of knowledgeable resources (COBOL Programmers with context of the systems implemented - their functional and non-functional requirements)
  • COBOL does not "fit" in an Agile and Innovation-driven business ecosystem.
  • Auto-Port's of COBOL to Java or C/C++ results in unmaintainable (unreadable by humans) code - problems in the porting mechanics will be hard to diagnose and resolve.
  • 4 Divisions of COBOL are unfortunately no longer taught at universities any more and isn't a "sexy" language for graduates to pursue.
  • The environments required to run COBOL applications are slowly losing favour to distributed commodity based hardware platforms.  Running COBOL applications on non-Mainframe Infrastructure makes use of expensive runtime environments.

There are modernisation strategies - such as building out call-outs from COBOL to Java components - such as the approach adopted by CSC with Celeriti (modernisation of CAMSII Card and Merchant from COBOL to a Java platform).