Which is a bad attitude in general, but an especially bad one for an industry known to use exceedingly old tech.
In all honesty: why is COBOL so prevalent in the finance sector? It can't seriously be SO GOOD as to be completely un-replacable?
In all honesty: why is COBOL so prevalent in the finance sector? It can't seriously be SO GOOD as to be completely un-replacable?
Most big banks have a bunch of security people whose sole job is to make people’s life hell by spreading as much FUD as possible[2] — that’s what keeps their jobs secure, after all. And they are the only “engineers” who are heard. They make sure that anything new is not adopted till the rest of the world has already started abandoning it.
The primary focus in the technology departments of big banks is to maintain the status quo. New development is rare. New ideas are crushed before they can see the light of the day. As a result, good engineers leave as son as they can and the only ones left behind are the ones who are content living a life of mediocrity — maintaining the status quo.
[1] I know someone who was told something along those lines when they joined a big financial institution as an engineering manager. And not all financial companies work that way. Those who embraced technology reaped the benefits and continue to do so.
[2] I am not suggesting that security is not important. But security people at these institutions take it to a whole different level — to the point where things that should not take more thane a few days end up taking months — if they allow it, that is. Funny how all their objections vanish when someone from upper management asks for the same thing.
Imagine that you need to replace a live system, downtimes are not allowed, probably provide a new UI while offering 100% of existing features.
There is no documentation available, or even if there is one, you won't find anyone in the building that will put their hand on the fire for how much of it actually maps to the running application.
So a project of reverse engineering existing application into a requirements document or updating the existing documentation usually takes several months.
Now just for a very basic project cost, consider the monthly salary of everyone involved, multipled by the amount of months.
And we are just speaking of phase I, then there is the actual re-write, followed by verification that 100% of the old features are still present on the new system.
Naturally it is cheaper to keep existing systems running.
This applies to any old platform, not only COBOL systems.
Which by itself shows how much money such re-write would eventually cost.
You can't just throw it away.
It is not un-replacable in itself, I'd imagine it is just a huge undertaking and many higher ups are afraid to do it and risk something going wrong.
As above, may be these COBOL systems have been battle tested for a long time and they are good. Other reasons could be, "if it ain't broke then why fix it?" or that there aren't enough people to act as a bridge between the old and new systems so it is hard to do such projects (as other comments have pointed out)
So at any specific time, the safer and cheaper option is to stick with the old system, despite the growing risks and costs in the long run.
To use hip modern buzzwords, it’s a DSL. In addition, it runs on hardware specifically designed around its idioms.