Banks' Big Upgrade: Meet Real-Time Processing 89
CWmike writes "It has been years since the banking industry made any large investments in core IT systems, but some of the largest financial services firms in the U.S. are now in the midst of rolling out multi-million dollar projects, say industry experts. About a decade ago, they began replacing decades-old Cobol-based core systems, with open, Web-enabled apps. Now, they are spending more than $100,000,000 to replace aging systems, converting to real-time mobile applications for retail services such as savings and checking accounts and lending systems. The idea behind going real-time: Grab more business — and money — from customers. 'Five of the top 20 banks are engaged in some sort of core banking replacement and we expect to see another three or four in next 12 months,' said Fiaz Sindhu, who leads Accenture's North American core banking practice. 'They're looking at those upgrades as a path to growth.'"
And yet I bet they still hold our checks... (Score:4, Insightful)
None of this should be taken as meaning they should not modernize. It is just that they have taken this long to realize that they might make more money by being fast than by being slow. I expect they have figured out how to be either, depending on how it benefits them.
Re:Evil (Score:3, Insightful)
If you have to borrow money for a car, you are spending too much on that car.
Debits are already real time. (Score:4, Insightful)
Deposits? Pneumatic tube to the abacus room.
Comment removed (Score:4, Insightful)
Re:Apples, oranges, confusion, and enlightenment (Score:2, Insightful)
Sorry mate:
It's a hard change for them to make as a very large percentage of the old mainframe folks just don't consider anything but the batch approach.
The old mainframe folks are likely employed doing the sort of work they have done for longer than you have been alive. They know from experience what works and what does not. The batch approach is reliable, understood and suitable for the problem they have been tasked to solve.
I don't know the number of times I've tried to explain the concept of queue based 'as soon as possible' processing or some other non-batch approach to those that grew up in the lameframe/COBOL world.
I would like to hear what the mainframe programmers thought when they were told that everything they have been doing for the past thirty years is wrong by a Slashdotter that uses the term "lameframes".
I hope they're taking the opportunity to decouple things and rewrite things in a more maintainable manner.
Batch processing is all about decoupling, much more so than a queue based 'as soon as possible' system that fires off new processing as quick as it can.
Those old COBOL systems have generally turned into monolithic nightmares of spaghetti code.
No more so than brand new systems that were maintaned by poor programmers.
Even determining what they're really supposed to be doing in the code must be an epic task.
No more so than brand new systems that resulted from poorly-managed projects with undocumented requirements and business rules.