"Banks are full of war stories trying to migrate off their old mainframe codebases, and often giving up."
Most of the time it's a question of trying to apply "death by a thousand cuts" to their codebase, which works well enough as long as you're in the periphery, but eventually they start moving into "core business", you know that entangled mess that has 60 years old code that still runs today, and they realize they need to rewrite all of it, which will take a long time, and cost a lot of money, and they forget about it again for a few years.
It's the same problem everywhere with large and old codebases. You can easily amputate a tentacle here and there, but as soon as you get to the core of it, it is basically one giant monolith, and with age there has been added loads of "integrations" or "shortcuts" between various subsystems, and nobody in the company today has any idea why it is like it is, it just is and it works.
A bank I used to work for had somewhere around 50000 batch programs running nightly. Some were the same program running multiple times, but at least 20000 were "unique" programs. All of those programs had to fit like pearls on a string, each working off of the output of the previous program in the chain.
Untangling that mess is like peeling an onion one layer at a time, with the added bonus that the output of one program might be the final result for some report, and at the same time the input for some other program that needs to do something else.
Add to that, that there's no inherent problem with the mainframe or COBOL. They both work, and reliably as well. Both can push some serious IO through the system, loads that many x86/x64 builds would struggle with.
The conventional answer to IO problems is eventual consistency, which doesn't really work well with finance, at least not if applied broadly. You can get some of the way with slicing / partitioning, but you will still have to deal with a lot of traffic between partitions.
Most of the time it's a question of trying to apply "death by a thousand cuts" to their codebase, which works well enough as long as you're in the periphery, but eventually they start moving into "core business", you know that entangled mess that has 60 years old code that still runs today, and they realize they need to rewrite all of it, which will take a long time, and cost a lot of money, and they forget about it again for a few years.
It's the same problem everywhere with large and old codebases. You can easily amputate a tentacle here and there, but as soon as you get to the core of it, it is basically one giant monolith, and with age there has been added loads of "integrations" or "shortcuts" between various subsystems, and nobody in the company today has any idea why it is like it is, it just is and it works.
A bank I used to work for had somewhere around 50000 batch programs running nightly. Some were the same program running multiple times, but at least 20000 were "unique" programs. All of those programs had to fit like pearls on a string, each working off of the output of the previous program in the chain.
Untangling that mess is like peeling an onion one layer at a time, with the added bonus that the output of one program might be the final result for some report, and at the same time the input for some other program that needs to do something else.
Add to that, that there's no inherent problem with the mainframe or COBOL. They both work, and reliably as well. Both can push some serious IO through the system, loads that many x86/x64 builds would struggle with.
The conventional answer to IO problems is eventual consistency, which doesn't really work well with finance, at least not if applied broadly. You can get some of the way with slicing / partitioning, but you will still have to deal with a lot of traffic between partitions.