Banks, hospitals, aerospace industry, retail operations, states and governments mostly run on IBM main frames.
These entities refuse to upgrade because “it just works”. IBM charges an arm and a leg to these companies because they know they can’t migrate off.
I happened to come across an invoice from IBM to our company and each server/appliance cost $250K or more. I believe the total cost for the order was a few million dollars. This doesn’t even include the support contracts.
Actual quote from a major insurance company CIO to me: "We've tried to migrate off the mainframe every few years for two decades. Every attempt has failed."
I wonder how many times they try hiring consultants to do it for them. I tried consulting and it was mostly bs. I imagine if they hired good people internally they could do it. (But finding good people I probably the biggest problem...)
In my experience this is because of old and entrenched organizations built around mainframes.
If you have a mainframe it is very likely to be supported by a small army of people who are not at all very happy to be replaced but at the same time are the only ones who knows how the stuff works and the stuff is very opaque to general developer population.
Even building your own fault tolerant Linux cloud seems cheaper. Granted, an insurance company does not have the expertise to build massive computer operating systems.
Or because of money, and other vendor lock-in’s? Then, with all the proprietary stuff, I can see how a migration can easily fail.
It's usually because the software accrues warts, procedures, and special cases that get baked into the company's very core. They're all different and all valuable. Replacing them requires someone who fundamentally understands why it's all screwed up before they can find a workable fix (Chesterton's Fence).
But that's boring, awful work. It takes zillions of meetings trying to pry information out of unwilling participants who just want to do their jobs. And Reports! Acres of impenetrable reports trying to document what you found.
Nah, it's more fun for consultancies to roll in and rewrite everything, and then send every department through crazy change management. Suddenly there's a showstopper that nobody noticed until now, the project is already millions of dollars over budget and years late, so it craters.
A few years later another CIO does it all over again.
Good to know. This provides job security for the CIO. If this project is canceled, then just jump ship, join another company, and do the same thing all over again.
One reason these types of projects fail is that they are asking the people running the system today to do the migration and put themselves out of jobs. It's rare for people at the individual level to deny there is better tech, but as a group they know their situation. This was the same for migrations of ancient eRoom deployments to SharePoint in the mid-2000s. It's a pattern of working in big organizations.
The way many do this type of migration is to bring in another set of people (or outsource the system.) These new people have no attachment to the old system, but you lose the knowledge of the people you are replacing. This ends up being worse a lot of the time, but if it's too late then the organization won't rollback, and just spend a lot of time fixing their mistakes.
It's rare to get partnerships on the level that is required to change these big systems. In smaller projects, I've had the pleasure of working with some old-timers to update their technology, but it needs to be a collaborative effort.
There are a variety of reasons that I've heard. For some they simply can't match the level of performance of COBOL on the main frame. For others the code is so complex that re-implementing it with feature parity is nearly impossible. It took decades to get to where it is, it won't be replaced overnight.
Another fascinating explanation I heard about was the way floats and numbers are represented in the different architectures. Due to minor differences, a non mainframe/non COBOL implementation produces incorrect results.
I read a great article about it a year or so ago, I'll see if I can find it and link to it.
Mainframe applications are very different from "regular" Linux server applications. Migrating would almost certainly mean a complete redesign and rewrite of existing software. For industries where stability is paramount (banking, hospitals) it just isn't worth it.
Keep in mind that the applications running on these mainframes were written in COBOL 30+ years ago, often with poor documentation and specification. It is a tremendous task to port something like that and have the new system behave 100% like the old system.
Same with a major retailer I worked for. They recently succeeded... by moving to a mainframe emulator in the cloud. The crusty batch software written in the early 80s is still running unchanged.
I would love to hear about a study on the longest continuously-running pieces of enterprise software. I bet there's code in production written closer to the invention of flight than to today.
It's primarily a consulting business, main competitors are Accenture, Tata, Infosys. Revenues from the Q1 2020 form 10-Q: https://imgur.com/a/dEccmvi (Services: $11.4B, Sales: $5.9B).
Also, consulting is not going to die so easily - IBM will perform its usual round of layoffs and continue existing.
Consulting as a service may not be but remember when times are tough companies like to reduce capex and enjoy short term flexibility with opex. As those synergies between consulting and product disappear then those clients may jump to IBM's competitors.
Imagine being the CEO of Redhat, and forging your own way, and blazing a trail of freedom and independence, to make open source software available to everyone, so that they can build their own applications on top of it.
And then, selling out your soul to IBM, and just dying a slow death.
It's important to remember that IBM isn't really one entity. They're not just mainframes, or Red Hat, or Watson, or any other one thing. To butcher a TV quote: "IBM is just a convenient name for a group of unrelated corporate interests."
So of course they're doing layoffs: at least SOME of the orgs that operate under the brand name have to be struggling. It gets a lot less impactful when the news just bubbles down to: "someone made a bad bet somewhere."
It was always coming at a company like this. Now is just the time when these things happen.
The theory is by cutting the bottom and always hiring you constantly improve your workforce.
The reality is then you will always fill reqs, sometimes as quickly as possible, to make sure there is a sacrifice for the gods. Perversely, a team of high-performers is actually punished, as everyone is also ranked against each other, so even if you have the top 10 performers in the company, one or more of them may be fired and will often have their compensation effected (less/no RSUs etc.).
Certainly that was how it felt about 5 years ago, not sure about today.
To be honest, I've been on both sides of the fence for this one, and it's a tough call:
1. The "periodically cull the bottom" way of doing things invariably leads to a toxic culture with people looking over their shoulder.
2. Conversely, I've been in tech companies where it was EXTREMELY difficult to fire anyone who wasn't outright awful. Over time that can really erode your culture because people who are on the poor side of mediocre hang around and weigh everything down.
The best solution is to always have high standards, but evaluate people against those actual standards, and don't be afraid to take action if necessary, but don't have arbitrary X% cutoffs.
Without risking some random Intel lawyer reprisal, it was often worse than that. At one point, Intel had the 'ranking and rating' that was once used at Microsoft. I think this is called 'forced ranking' today. My god.
I worked at UHG’s tech arm called Optum and layoffs/churns were very common. Entire teams can just disappear off the floor without a moment’s notice. They’ve offshored most of their work to other countries and most of the offices stateside are ghost buildings. UHG execs are just focused on its stock ticker.
A family member of mine has to deal with their Phoenix payroll disaster regularly and directly because they work for the government. The rest of Canadians still had to deal with the price tag in terms of noticeably affecting the national debt.
It's a business decision. With the economy tanking they'll be able to hire better grads and a recent grads than they normally could, work them like dogs for twenty five years and then wait for a convenient recession for a big layoff. This has been going on since the '80's at least. Rinse and repeat.
How does that make sense? Can the "grad" do good enough job compared to a senior? I've seen my fair share of "senior" developers, who had insanely high salaries for some strange reason yet their output was mediocre at best. Laying off these people I can understand.
That said, management is notoriously bad at spotting these people. Chances are they lay off the only person who knows how some crucial piece of SW works...
"Essentially, you lay off some of the people without the skills you need and who can’t be re-educated and you bring in people with certain skill sets".
So what's the criteria for who can't be "re-educated"? Too old?
Welcome to on demand remote IT Labor. Pretty much anyone one IT can be replaced with a cheaper offshore resource thanks to the acceleration of remote work.
Since that thread took for granted that the layoffs were happening, I see no SNI here. https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...