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.
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.
This is not surprising. IBM could fix this overnight if it wanted to. How? By providing no-cost educational licenses for its mainframe software for use on Hercules. Why don't they do this? I believe that there are 2 reasons why: (1) they're terrified of people running their production mainframe workloads on a non-mainframe, and (2) I believe that some of IBM's existing mainframe customers keep pressure on IBM to prevent them from opening up the 'mainframe secrets to the world'. The second point is the belief in security through obscurity. I don't have any evidence to back up this belief, it's just my theory.
The other thing that IBM could do is provide low-cost (or even no-cost) options to real mainframe environment over the internet. I know that they have some of this, but it's too restrictive. I'm talking about opening it up like AWS did with free for 1 year. But that's expensive? It wasn't free for AWS to do it, and it wouldn't be free for IBM to do it. However, it would eliminate the biggest barrier to entry for new talent.
Getting back to my theory of security through obscurity, I believe that this is also in play with AIX and iSeries (AS/400). A number of years back, I bought a used RS/6000 workstation on eBay for the purpose of learning and I contacted IBM to get a licensed copy of AIX 4.3. It was as if I were speaking in tongues trying to get through to them.
IBM: "Sir, what's your IBM customer number?" Me: "Umm, I don't have one. I'm just an individual who bought a used RS/6000 on eBay." IBM: "We can't sell you an AIX license without a customer number." Me: "Ok, well give me one." IBM: "What's the name of the company?" Me: "There is no company. It's just me as an individual who wants to learn about the technology." IBM: "We have to have a company name." Me: "Put my name as the company name." ... ... ... Eventually, get assigned an IBM customer number and did finally get AIX CD-ROMs from IBM.
I can only imagine that it would be 10x worse to do something similar with their iSeries (AS/400). When you see this over and over, I'm left with the conclusion that IBM doesn't want individuals getting their hands on their hardware or their software.
You are absolutely right about how hard it is to do business with IBM. I worked for IBM for nearly 7 years, running a small datacenter. It was such a pain in the ass every time I needed to order something. IBM sales and support process is very high touch, and is designed for the large enterprise that has a team of IBM sales people supporting them. If you are that customer it is not a big deal because you have someone to navigate the process for you. If you are a smaller customer, they want you to go through a VAR. Which is still a pain in the ass.
Windows NT and the AS/400 are about the same age. This pain in the ass sales process is a big part of why Windows NT won. The IBM sales people didn't want to sell it because you didn't need to buy services with it and it was too hard to buy on your own. Where as if you wanted Windows NT, you just bought a copy of Windows NT and installed it on an easily available PC.
We won't even talk about the time I tried to use IBM Smart Cloud Enterprise.
Bootcamps saturating the market with webdevs armed with skills that barely last a year, when they could be training people with skills that would see them employed for a whole career.
It has nothing to do with bootcamps. If the mainframe knowledge was in sufficient demand, then they would be selling mainframe training too since people would be wanting to buy it.
A large part of that is probably due to American management practices, where the preference is to skimp on maintenance until they find themselves in a crisis. They don't want to pay for what they need, they want to pay for whatever is cheap.
Maybe, but it may also be true that people simply aren't aware that mainframes exist or these jobs exist.
What gives me pause for concern is the JEE/WebLogic platform is now as old as COBOL was in the 1980's when we were calling it "dead" and we're still looking at 5-7 years of development and migration time to get to the new system. What will we think of JEE/WebLogic in 2030? My biggest concern is they're going to spend all this money to get onto another soon-to-be-legacy platform that they're going to realize on day 1 they need to start planning on getting away from. This is why mainframes have been so "sticky."