5 ms·
These systems can be at the very core of the company's operations, so you're talking not just a revamp of a bunch of COBOL programs and mainframe servers, but a
by shepardrtc 9y ago
These systems can be at the very core of the company's operations, so you're talking not just a revamp of a bunch of COBOL programs and mainframe servers, but a significant portion of the company's workflow would potentially need to be refactored or replaced. The mainframes themselves sit in a box, but many other systems rely on their data and their guaranteed processing. And all of those connections and data structures are custom. Even if you were to figure out some way to completely emulate the system (and that itself would probably take several years), you would then need to integrate your emulated system into other real-time systems. A bank just can't shut down for a day. And if they screw up a few minutes worth of transactions, then things get very bad. So your testing and integration will be slow and methodical and expensive. And even then, you're still emulating a crappy, old system. If you wanted to actually replace the entire system, how would you do it? These things aren't modular. They were custom-built with no intention of ever being parted-out. You would have to completely re-architect the company's infrastructure and workflow.
Or you could not do any of that. You could just accept your situation. Mainframes are essentially a subscription service. For a yearly cost, IBM has offered you guaranteed performance and guaranteed hardware (they fix it immediately if there is a problem). So, all you have to do is pay your subscription and pay some people who like to have a steady, unexciting job and your business will continue to run like clockwork.
- scrollaway 9y agoI understand what you're saying, but does this logic hold over decades? I'm obviously not saying banks should just switch today cause it's easy and all, but if the ROI on switching is 10, even 20 years, it still makes sense to do if you're a bank.
- semi-extrinsic 9y agoIt's not 10 years, it's probably closer to 100. Reasons being a) the ridiculously large cost of rewriting and testing the new system on a real-time system that can't be taken down, and b) the ridiculously low cost of maintaining the current systems.
- scrollaway 9y agoHow do newer banks do it? It certainly doesn't take 100 years to bootstrap a bank. I also mathematically can't get behind the concept of reproducing a known state taking longer than the time it's taken to get to it. I can't find the post now, but some folks from the US govt who frequent HN talked at length about the ongoing replacement of mainframe-type services with newer tech. What I gathered from that is that the cost isn't ridiculously low at all when you take into account the impact it has on the organization's ability to get things done.
- lovich 9y agoWhile I'd agree that its easier to start a new bank, thats not the case here. What you are doing is trying to recreate something that currently exists, and if it goes like almost every job I've had then there is no budging on any of features, they want stuff duplicated down to the same bugs, and none of the features are documented. You end up spending half your time just reverse engineering what currently exists before you can even begin work
- lovich 9y agoWhile I'd agree that its easier to start a new bank, thats not the case here. What you are doing is trying to recreate something that currently exists, and if it goes like almost every job I've had then there is no budging on any of features, they want stuff duplicated down to the same bugs, and none of the features are documented. You end up spending half your time just reverse engineering what currently exists before you can even begin work
- eggestad 9y agomost moves from mainframe to *nix, windows or others are a port of existing code to a new OS. NOT a complete rewrite.
- semi-extrinsic 9y ago> I also mathematically can't get behind the concept of reproducing a known state taking longer than the time it's taken to get to it. What you have to remember is that when the COBOL code was written, it replaced hundreds, maybe thousands of people doing manual data entry and manipulation, maybe even pen-on-paper. That gives you a fantastic ROI. After that's been done, replacing one computer system with a newer one is completely different, a spectacular case of diminishing returns.
- shepardrtc 9y agoYou're absolutely right. But to start a decades-long project that may or may not work and has no near-term ROI is a hard thing to rally for. The cost of the project would eclipse what is being paid to the mainframe provider and to company personnel. And these companies have a difficult time bringing in top talent, so they don't really have many tech-savvy people to preside over it. I've seen it attempted first-hand and it was a dismal failure. And it was their third or fourth attempt. And it wasn't even a full replacement! Just a simple data lake to dump things into. Google or Facebook or Amazon could do it, but few companies are like them.