Slashdot Mirror
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...
no banks do lend the money they get from deposits.
creation of money happens when this process continues-
X deposits $100. bank after keeping (say) $10 due to statutory requirements, lend $90 of that. Y who got it(either from bank or after transactions from persons who got it from bank) then deposits $90 in another bank. that bank keeping $9 for statutory requirements lend $81. and this goes on. so from that $100 banking system create another $800(if statutory requirement is 10%). that is what is meant by creating money by banks.
Luckily various governments thought of that and guarantee deposits up to a certain amount.
The Microsoft Azure cloud comment did make me laugh but if you think bank systems are well designed I've got a bridge to sell you.
IBM's architecture is solid but the banks have 40-50 years of terrible ideas and shit code held together with duct tape and chewing gum.
As it gets harder to find COBOL developers because people like me were discarded for having the nerve to want to be paid well we're going to start seeing some serious banking problems as a lack of staff forces system upgrades.
Either that or the banks will need to offer us huge incentives to come back much like they had to when the Y2K bug could no longer be ignored and they'd "rightsized" too many people.
Let me know when bitcoin can handle 2000 transactions per second, which is just equivalent to VISA average.
IBM's architecture is solid but the banks have 40-50 years of terrible ideas and shit code held together with duct tape and chewing gum.
Fair enough; I admit my knowledge is more of the systems and software than of the applications the banks have written. But Wall had nothing to say about the bank applications and their quality. I addressed the issues he did seem to touch on.
As it gets harder to find COBOL developers because people like me were discarded for having the nerve to want to be paid well we're going to start seeing some serious banking problems as a lack of staff forces system upgrades.
Yes, I can well believe that. The technical problems are rarely insoluble - whether it's a banking system or the Space Shuttle. It's the failure of executives and other decision-makers the understand computing that causes most of the trouble. I once met an IT recruitment company CEO who, quite seriously, told me that programmers were "like bricklayers". In other words, the difficult part was done by analysts and the like, and the programmers simply had to "code up" their designs. I managed to refrain from assaulting him, although it was difficult. FWIW, in my opinion it's more accurate to compare programmers to lawyers (at a coarse level, in terms of the difficulty, level of abstraction and appropriate pay level). But then lawyers are paid to obfuscate and confuse matters, whereas programmers do the opposite. No contest.
I am sure that there are many other solipsists out there.
makes the old systems obsolete, but impossible to replace
No. It may be (difficult | expensive | unprofitable | complex | a pain in the ass | a (herculean | sisyphean | Korean | Crimean | many eon | diahrrea'in) task), perhaps.
But impossible? No.
Nothing posted to
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.
This MEME really needs to die. Old Cobol code isn't an issue any more than old ASM is an issue to Windows.
Banks didn't update their backend cobol systems for this shit, they put new front ends in front of it. Haven't done some brief contracting for a couple who essentially write everything in C# and have literally one guy that knows Cobol and 'the mainframe' that helps them interface to it with VERY MINIMAL IF ANY code changes at all. You make the new front-end interoperate with the back-end and you leave the back-end the fuck alone until its completely replaced.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager