Rethinking Mainframe Modernization

Not long ago, I was working with a big regional retail chain whose leaders envision one day being as large as Walmart. During one of our meetings, the retailer’s CTO told me that the company wanted to transition off of their mainframe. 

“It’s old technology,” he said. Well, if your sole measure is that mainframe technology was developed more than 75 years ago, then sure, I suppose. 

But what if I told him that Walmart is one of the largest (if not the absolute largest) consumers of mainframe technology in the entire world? Does that make it any less modern? Certainly, the company uses its fair share of distributed and cloud computing (very likely greater in scale than almost all other businesses), but for some of its use cases as well as those of other organizations, mainframes continue to make the most sense. 

Before IT decision-makers look at their mainframes and think, “We need to modernize,” they should consider whether their definition of modern has been reduced to tech that has the most recent born-on date. The real question should be, is that tech the best vehicle to help the organization function in a modern way?

Here’s a little-cited alternative definition of modernization, taken directly from Scott Fagen’s Cynical IT Dictionary: “The process of extracting money from a customer for improvements in coolness and bragging rights, with little regard for actual business value.” Are there situations where our customers would be better off by transitioning a particular application off of the mainframe? Absolutely. But is the vague pursuit of modernization always the best, most cost-effective way for organizations to solve their business problems? No way. 

The most glaring example of a wrongheaded mainframe modernization move is probably when organizations rewrite an entire application, shifting from COBOL to a newer, sexier programming language like Python or Java. No matter how old the COBOL code may be, it’s not going to wear out or rust, and rewriting it almost always represents a hugely expensive and risky lateral move, not real modernization.

In many ways, the mainframe’s promise of compatibility over the decades since the introduction of the System 360 is at the root of the modernization conundrum.  Unlike other platforms, which have a propensity to deprecate existing functionality on release boundaries (effectively forcing upgrades to applications and other software along with the hardware, operating system and middleware), mainframe applications may have been left alone, running without any major (or even minor) modifications for many years.  This complacency complicates the issue when a change is desired; often, that change is based on multiple technology improvements that have not been exploited and may seem daunting when taken as a whole.

Some customers ask us about Mainframe as a Service. MFaaS is an option, but it’s important for people to understand what it is — and what it isn’t. In reality, there’s no such thing as a true mainframe or zCloud MFaaS offering comparable to serverless models from cloud providers, enabling organizations to migrate their mainframe applications to the public cloud. 

Instead, these offerings are really managed service engagements, some form of the promise of “your mess for less.” An outside party will manage a mainframe environment on behalf of the customer (sometimes owning the physical infrastructure and sometimes not), often at a colocation center. Again, this might be a fit for organizations looking to reduce their internal management burdens, but it’s no more an example of modernization than outsourcing your help desk.

The most effective form of modernization is often simply a switch to cloud software. We recently worked with an insurance company that had been running a particular application on its mainframe for decades. Over time, application support had become increasingly difficult, not because there was anything wrong with the code or the physical infrastructure, but because the application needed to integrate with more and more new systems. 

Getting the right application programming interfaces (APIs) in place to support this integration was becoming an untenable management burden. Rather than suggesting an expensive, time-consuming application or infrastructure modernization effort, we helped the company find an alternative delivered via Software as a Service (SaaS) that could replace their existing application. 

Don’t think this integration issue is endemic to mainframes — this cuts across the IT spectrum.

Many companies have bespoke software that would require far more programmers than they can hire to make ready for some new software initiative; hence the desire or outright need for packaged applications, with SaaS being the next simplification to further relieve the burden of managing infrastructure. 

APIs are one issue. Others include finding and plugging all the potential security holes and dealing with the many deprecated interfaces and functions that occur with newer releases of software.

Finally, the only modernization move that some organizations need to make is to replace their aging, out-of-support infrastructure with a newer (but otherwise not modern) mainframe. 

We recently worked with a state government whose mainframe hardware had been out of support for five years. It is unlikely that they would have let that happen with a Windows or Linux server, but the IT leaders seemed somewhat surprised that they were now going to have to spend a little extra on hardware and software to get their application running on supported equipment. If they’d simply tended to their mainframe over time the way they do with virtually all of their other IT systems, they never would have hit a crisis point. 

I continue to hear people talking about the need to transition off of mainframe technology by a certain date. I know of projects that are in the seventh year of a three-year conversion. These deadlines come and go, while the bulk of organizations stick with what’s served them well for so many years: the mainframe.

Story by Scott Fagen