Commenting on a recent Attachmate Survey, Gregg Willhoit explains why companies are opting to modernize their mainframe applications rather than replace them. This podcast runs for 4:54.
First of all, I think the Attachmate survey is really interesting, a lot of salient discussion about SOA and legacy modernization, and recommended reading for anyone interested in the topic.
I think the main reasons why companies are opting to modernize is that the mainframe is still the most secure and reliable platform, first of all. And I think the sub-systems that run on the mainframe, like IMS and CICS and DB2 and products like our own, Shadow, are extremely reliable, 24-by -7-type reliability. I think not insignificantly is also the virtualization aspect of mainframes; the ability to instantiate multiple copies of operating systems on a mainframe platform allows for significant amount of flexibility on the part of the organization with regard to what they’re implementing.
I think most companies that have mainframes have significant investments in applications, extremely significant. There’s basically a lot of business intelligence in these applications. As you can tell from the survey, most of these legacy applications are the CICS type COBOL applications. I think after that would be IMS and after IMS would be a plethora of some of the smaller players in the mainframe database subsystem group.
These applications of course have been written over many, many years. They’ve been maintained, upgraded, enhanced. They started out as basically either batch applications or terminal oriented applications, applications accessed from the old green screen 3270 terminals. Yet these applications are a goldmine of business intelligence.
The cost of rewriting that business intelligence is extremely significant compared to the cost of exposing that existing business intelligence using SOA for example. So for one, it’s an economic decision. That is, how much does it cost us to rewrite the majority or a significant portion of our applications? And then again, what’s the opportunity cost of doing so? I mean, you know, we could spend time and money building newer applications, etc. And then what is the risk?
I mean, one of the things as a software developer, is it really worth the risk to rewrite millions or billions of lines of code, and which is basically going to be used for some number of years? And I’m usually hard?pressed to find a good reason for doing so, especially when you look at the viability and the strength of the mainframe platform. Mainframes are becoming more efficient. They’re more energy efficient. The implementation of virtualization on mainframes is so much superior to anything off the mainframe. IBM’s been doing virtualization for more than four years now, I think.
So it’s just hard to find a good reason for re-factoring applications on some other platform. And then with the viability of the tools, the availability of the tools to expose existing legacy applications, CICS transactions, programs, IMS transactions, IMS databases, VSAM expose those assets to the SOA architecture, this is quite easy to do these days. It’s nowhere near as difficult as it was four or five years ago. There’s a plethora of tools out there, some of them better than others. But with the viability, availability of these tools to allow you to keep the applications on the mainframe and to expose them as SOA assets, while maintaining the integrity of the application as well as the reliability and the serviceability of the mainframe, I mean it’s understandable why most folks are looking at keeping the data on mainframe and architecting solutions which expose mainframe assets as SOA resources.
View all posts from Gregg Willhoit on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.