Is Old Tech Putting Banks Under Threat Of Extinction? (bbc.co.uk)
Matthew Wall from the BBC has written a fascinating piece detailing our reliance on banks in today's connected and ever-changing world of technology. The premise: "You put your card in the cash machine but nothing comes out. The bank's IT systems have crashed again. But you need money fast, so what do you do? It's an unsettling scenario that is likely to become more common over the next few years as the big banks try to upgrade their IT systems, experts are warning."
Bruce66423 writes: In the old days everything was batch programs and reconciled once a day. Now, online access and the expectation that money will be immediately available makes the old systems obsolete, but impossible to replace because there are layers upon layers of complexity...
Bruce66423 writes: In the old days everything was batch programs and reconciled once a day. Now, online access and the expectation that money will be immediately available makes the old systems obsolete, but impossible to replace because there are layers upon layers of complexity...
What the current banks shall fear is new upcoming banks that have thrown off the old Cobol yoke and started to look at modern languages with strong typing and strict bounds checks.
No, I think what both banks and customers should fear are banks switching from old flow-oriented languages to modern languages that abstract everything in dozens of layers and black box libraries outside your control, making it near impossible to troubleshoot what's actually happening.
And when they switch from real time systems, which are slow but you're guaranteed a result by a deadline, to the best effort systems that are all that modern programmers know.
What banks need is certainly modernization, but not to the popular programming methods of today. They need full transparency, strict operating deadlines, atomic operations, containment, a focus on worst case, and testing algorithms more than runtime.
Perhaps replacements for COBOL, Ada and Fortran are needed, but I think it needs to be engineered by someone who understands what's different, and why.
It's not good enough for a bank to make 99% of customers happier. If software causes problems for 1%, they risk losing major customers or licenses to operate.