3 ms·
You are correct. There was a time when companies ran projects to replace their mainframes. They all largely failed. The trend now is to integrate around the mai
by josho 3y ago
You are correct. There was a time when companies ran projects to replace their mainframes. They all largely failed. The trend now is to integrate around the mainframe. Build new functionality on modern systems and leverage the mainframe where it makes sense.
I worked at one company that is trying to replace their mainframe. The project is now in its second decade. The company has the burden of supporting the mainframe application and now the 'modern' application. The project is still a few years away from being able to completely shut off the mainframe.
Oh and the modern application is also showing its age as the business has changed and the modern system built assumption in from the mainframe system and in many ways is just as inflexible to change as the mainframe app was.
This is why companies aren't scrambling to replace their mainframe systems. They are happy to continue paying for the high cost of compute on these systems because its still cheaper and less risky than replacing the system.
- technofiend 3y agoI've been on a couple of successful migration projects, both of which moved things to unices. One was motivated by the $5 million/yr costs to maintain the mainframe, which was replaced by a handful of lowest cost bidder unix boxes. The second was regulatory-agency-mandated cleanup after a financial fallout, and unlike the previous two or three times that company had tried and failed to consolidate their risk reporting onto a single system, this time it worked. Because it had to. The threat of an external regulator was sufficient to break down the previous barriers of balkanized system owners protecting their turf.
- elzbardico 3y agoI bet that the "modern" application, given its 20 years vintage, is probably a J2EE application running on whatever is the modern incarnation of IBM Websphere and it was written as a mind-boggling soup of EJB 2.x Entity and Session beans.
- Melatonic 3y agoExactly. Java layer written on top of COBOL.