More on the Systemic Risk of Bank IT Systems

[marmar]

from Naked Capitalism:


More on the Systemic Risk of Bank IT Systems
Posted on July 31, 2015 by Yves Smith


As we’ve written about how the complexity of payment systems and the creaky legacy which sits at the core of the transaction processing engines of banks, which perversely run fault intolerant, mission critical operations on such a shaky foundation, the more astute readers, once they get over their incredulity, quickly recognize that this combination isn’t just a Grexit obstacle, but also a source of systemic risk.

Our Richard Smith, who has extensive experience in capital markets IT, first mentioned this looming problem years ago, but it did not seem timely to make it a major focus. But we are seeing more and more evidence that legacy systems are starting to break down at major firms, both from media stories and some private accounts we’ve received.

Members of our audience who have technology experience but have not dealt with either large lumbering corporate and/or major financial firm information technology infrastructure and assert that we are exaggerating how bad things are have revealed that they don’t know what they don’t know. Some comments from recent posts:

[font color="orange"]Arthur Williams[/font]:

What many of you “it’s easy” people fail to understand is that mainframe programming is nothing like today’s coding. COBOL, PL/I etc. do not support modern concepts like objects, polymorphism or anything else. Think assembly language with nicer mnemonics. XML ? Hah, there is virtually no such thing for the mainframe. There’s no git, no mercurial etc. Virtually none of the tools that exist for Wintel/Linux are available to mainframers.

In large organizations there are hugely cumbersome change management processes. Where I am, a simple code change might take a minimum of eight weeks to deploy, and we only have a dozen systems. Actual application changes like envisioned here would take at least six to twelve months for coding and testing, and then another four months for deployment. For large banks, I would expect the timeframes to be even longer because the systems are so critical.

Anyone who says it’s trivial simply has zero knowledge of the large systems environment.

..................(more)

http://www.nakedcapitalism.com/2015/07/more-on-the-systemic-risk-of-bank-it-systems.html

[Erich Bloodaxe BSN]

1. Sounds sorta strawman to me.

Are there really any IT people out there who suggest that rewriting bank software is 'trivial'? If there are, they must be godlike coders. But, at the same time

COBOL, PL/I etc. do not support modern concepts like objects, polymorphism or anything else.

So what? Those are all things that have evolved since to make things EASIER. Those programs written in COBOL are already more tedious and bloated than any programming that will replace them. You don't want to go object oriented? Fine, just rewrite everything into C. It's decades old, but still works a lot better, and there are still more C coders around than COBOL coders. Once it's in C, THEN if you want to go object oriented, you can move it over into C++ pretty easily.

Yes, it's going to be a big job, and yes, it's going to take a lot of time. But that's no real excuse for not updating archaic systems to at least be only a few decades out of date instead of a half century or so.