4 ms·

Why has it failed? Because of technology? Even building your own fault tolerant Linux cloud seems cheaper. Granted, an insurance company does not have the exp

Why has it failed? Because of technology? 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.

dahfizz 6y ago
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.
freedomben 6y ago
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.
zerkten 6y ago
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.
bronson 6y ago
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.
- blackrock 6y ago
  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.

dahfizz 6y ago

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.

freedomben 6y ago

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.

zerkten 6y ago

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.

bronson 6y ago

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.

blackrock 6y ago
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.