HomeLatest ThreadsGreatest ThreadsForums & GroupsMy SubscriptionsMy Posts
DU Home » Latest Threads » Forums & Groups » Topics » Economy & Education » Economy (Group) » More on the Systemic Risk...

Fri Jul 31, 2015, 11:14 AM

More on the Systemic Risk of Bank IT Systems

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.



1 replies, 786 views

Reply to this thread

Back to top Alert abuse

Always highlight: 10 newest replies | Replies posted after I mark a forum
Replies to this discussion thread
Arrow 1 replies Author Time Post
Reply More on the Systemic Risk of Bank IT Systems (Original post)
marmar Jul 2015 OP
Erich Bloodaxe BSN Jul 2015 #1

Response to marmar (Original post)

Fri Jul 31, 2015, 11:30 AM

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.

Reply to this post

Back to top Alert abuse Link here Permalink

Reply to this thread