Cobol – do banks speak our language?

Graham Smith is a director of Certeco

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

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 programming language for business use, has been around since the year dot in tech terms – I remember using it fresh out of school in the 1970s and 1980s. 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 10 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 1950s and 1960s. No-one can say Cobol is solely responsible for banking glitches – of course it isn’t – but in an era where technology is evolving so quickly, we have to ask ourselves what Cobol’s role in the future will be.

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 legacy systems and Cobol are under considerable scrutiny. Social media means technical glitches and failures in customer service quickly escalate to become an onslaught of online customer anger and front-page news.

A key problem with Cobol is that even though it is the third most widely used languages in financial services applications (research by CAST Software), only a dwindling pool of developers is Cobol proficient, particularly those with the knowledge of the context in which the systems were implemented. They have become a relatively endangered species. It has been said that IT workers with Cobol in their kit bags have the safest – and some of the best paid – jobs in the City and financial institutions are terrified of facing up to the day when these people might retire.

Computerworld conducted a survey back in 2012 and of the 357 IT professionals who were questioned, 46% said they were noticing a Cobol programming shortage and 50% said the average age of their Cobol people are aged 45+.

And apparently the offshoring of banking services compounded the issue. When the trend for large swathes of IT development work being sent offshore was at its peak in the early noughties, banking executives didn’t anticipate the brain drain it would cause. Development jobs in the UK began to dwindle, so the last thing people were doing was learning Cobol programming. So now, if something goes wrong that is Cobol related, the source code is in the minds of people whose jobs were offshored or “redeployed” years ago.

Attracting new Cobol-educated talent isn’t easy. It isn’t very cool. Node.js is cool. Python is cutting edge. And apparently, Millennials are chomping at the bit to learn Objective-C blossom. But even though Cobol does feature on some university curriculums and companies like IBM are funding Cobol educational programmes, it isn’t attracting the number of people the banks need it to.

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 of which is the main reason many banks haven’t taken the plunge.

Maybe the smart answer is to target the youngsters, educate future coder wannabes on the financial benefits that await should they opt for studying computing languages like Cobol. According to industry say-so, Cobol developers straight out of university can demand a considerably higher salary than, say, their Java counterparts.

And it’s not just the money. The challenge for them is considerable – developing modernisation strategies, moving Cobol on to the next level, integrating it with newer languages and creating a Cobol for the future. Perhaps the answer isn’t replacing legacy systems – it is regenerating them.