This is the key issue. You can migrate it off the mainframe or you can migrate it to sexier tech on the mainframe.
> and the new generation doesn't know them or have much of a desire to learn them.
One of the barriers is that these companies are not willing to pay the same money we (I think we are from the same generation - I was paid to write Apple II software) can get from working with anything that's not COBOL.
I'd love to spend some time with mainframes - they are the fastest Linux machines you can get - but don't want it enough to combine COBOL and JCL with a significant pay cut.
As a younger person (graduated 2012) who entered the mainframe space for my first job then left after 2y, I can very much vouch that compensation for software devs working on zOS systems writing COBOL or HLASM is peanuts. You'd be looking at 1.5-2x'ing your income even if you took a job at a series A startup writing CRUD apps in Rails/etc.
If banks routinely started paying Google salaries for good COBOL developers, you'd see those shortages disappear in a big hurry.
It's not pricing. As a consumer, it always seemed like the largest banks tended to be relatively non-aggressive on their rates. Isn't "we have economies of scale and pass the savings to you" the classic competitive play?
It's barely, if at all, public facing apps/websites. Okay, you've all got a branded app, you've all started offering Zelle, and you all let me take a photo of the (average of) five paper cheques I recieve in a year to deposit them.
It feels like for a while it was the vague promise of "we've got the largest network so you don't need to worry about finding a machine." A concern largely mooted by smaller banks refunding out-of-network fees and credit union networks.
Their competitive advantage is not in their software at all. It's in their relationships. The software helps them scale to large numbers of depositors. That's all.
On one hand, I'd say that this is true. But on the other, I'm not so sure.
15 years ago, I interviewed for a job that turned out to be for building software on OpenVMS running on Alpha.
I had honestly never heard of either thing.
The interviewer, who would be my manager, said that isn't a problem, it's just a computer that works a little different than others. Do you want to learn it? I said ok.
Over the years, the hiring process changed, and there is no way that someone like me would even be sitting at that interview where they could ask if I wanted to learn.
So companies can go ahead and spend all that money on legacy consultants and all that money on migrating their systems.
I really think big iron's customer's problems are that they don't want to pay for quality engineers, but for some reason will pay those higher rates or more for some overpriced consultants. Literally just accepting that the outsourcing dream of 2000 was not a great move and using that money on internal engineering would go soooo far. You see even .gov getting the hint with 18F and the US Digital Service building and supporting non contractor government engineers.
Cobol programming is a skill that is trivially taught. Any student with a Cmpt. Science degree from a credible institution, given a curriculum, can learn any programming language in a month with a bit of focus/appropriate curriculum. Can pick up the necessary frameworks in a reasonable period of time. Then it's just a matter of teaching them the line of business, and the practices and procedures.
I would claim that, given twelve months, you could teach a cohort of recent Cmpt. Science graduates all the skills they needed to be successful in any Insurance/Banking/Finance programing environment.
And these are developers that you can then pay a very reasonable salary - say, $150K/year - which is $75/hour, not $300/hr, at the cost of 1 year of salary as they come on board, come up to speed (say at an out-of-college salary of $100K/year.) - You need 1,000 of those developers - that's an up-front cost of $100mm, at which point you have your developers.
Compared to a multi-billion dollar transition cost off of a mainframe, I know which one I would chose if I were the PHB.
And this used to be very common. My first job out of school in the early 1990s was with a "big consulting firm" they had a boot camp where they taught COBOL to batches of new hires. You did that for a month, and then were deployed to a client site writing COBOL about 50 hours a week.
I've done some work in the financial space. It's interesting to compare, for example, expressing a credit card transaction in an ISO 8583 message versus a modern JSON/REST API format. The same data might be there, but one of them is going to be much harder to debug without a lot of specialized tooling.
Why don't people switch, then?
The mainframe gives you a predictible runtime. Long running jobs don't get rescheduled or hogged by other loads.
I know about a firm that uses a mainframe to control a factory line.
The problem with replacing stuff that works (and the mainframe does) is then your job is on the line if the transition fails, and there are a lot of business moving parts inside.
No top 50 CS program teaches these tech. No unicorn uses them. Not a single FAANG or FANNG+ if you include other large players.
Finally, no engineering-centric company uses these tech. That's the difference between learning Go vs COBOL.
There are only a couple of FAANG+, with crazy hiring practices, and most businesses aren't engineering centric, the world is bigger than that.
It sets the trends and build what's next. RandomBigCo just follows.
The reason given is it's getting difficult to find COBOL programmers and the platform isn't as agile as other platforms. I have to admit that IBM is working to make the platform more agile and you can do more than run COBOL - you can run Java and Linux on Z. I've been in IBM training sessions where I've been running Linux on Z and then running Docker on top of that and unless you had told me otherwise the experience was normal: you're running bash, running Docker and everything runs as you'd expect.
BUT - the problem is the core of our system is written in COBOL. There's still CICS, JCL, Copybooks and DB/2 and those who can work with those technologies are now within 10 years of retiring and the new generation doesn't know them or have much of a desire to learn them. Heck, I'm part of the first generation of PC developers from the mid-1980's and I've never done any mainframe development!
The thinking then is we'd better jump off before all these people retire and you end up having to pay $300+/hr for resources capable of working with these legacy technologies. Pay now and buy yourself a new technology set and new capabilities or pay later and just keep the system running.