The world runs on mainframes. Sure, pure-play digitals may live on the cloud—but, their partners, the world’s biggest banks and insurance companies, as well as, government agencies trust their systems-of-record exclusively to COBOL on IBM z Systems. So even when you flag a ride on Uber, you trigger a mainframe transaction.

The status quo for so-called “legacy” code, however, is no longer acceptable. Existing mainframe applications simply can’t be modified quickly enough to keep pace with the relentless demands of the digital marketplace.

So should you pull the plug on your mainframe and re-platform your critical systems of record? Or invest in mainframe Agile and DevOps?

Let’s consider both.

Re-Platforming: Like a Brain Transplant, Only Harder

For decades, the party line from purveyors of distributed/cloud technology has been that enterprises must abandon the mainframe because it’s a “legacy” platform running “legacy” code.

This is an unsupportable position. In fact, the mainframe is alive and well—and the total worldwide mainframe MIPSs keep growing.

Here’s why:

  • The mainframe is the most advanced platform on Earth for systems-of-record. Only someone completely unfamiliar with the supreme feat of engineering that is today’s mainframe would call it “legacy.” No platform delivers comparable reliability, performance, scalability, security and workload economics for critical transaction processing and systems of record. So moving those systems off the mainframe hurts the business, rather than helping it.
  • Re-platforming is prohibitively risky, expensive and disruptive. The history of re-platforming projects is utterly dismal. Most fail—costing millions without delivering functional re-platformed code. Even projects that somehow manage to replace COBOL-on-mainframe with another codebase on another platform merely wind up producing systems that are invariably slower, more expensive to operate, more susceptible to downtime and far less secure. And, there's no participation trophy for being successful at being unsuccessful.
  • Zero benefit to customers. At the end of a re-platforming effort, all you have is similar business logic running on different binaries. You haven’t delivered any new value to the customer. And you’re not even necessarily more agile. Agility, after all, is a function of how you manage code—not the particular syntax you use to write that code. And if your new Java codebase is gigantic and complex (which it often is) you’ve actually created a hindrance to agility.

Mainframe DevOps: Orders of Magnitude Greater ROI

Now contrast re-platforming’s massive cost, unacceptable risk and lack of value with mainframe modernization.

With the right processes, tools and training, you can readily include your existing mainframe code in the same Agile methods and DevOps culture as your other enterprise applications. Developers at all skill levels can work on mainframe applications, even if they’re not very well-documented. They can run unit tests on that code just as they do in Java. They can even manage requirements, scrums, code promotion, etc., across both mainframe and non-mainframe code in a common manner.

In other words, you can achieve the result you really want—while spending your millions on initiatives that are far more worthwhile to your customers than re-platforming.

Code, after all, is code. Nothing about COBOL makes it inherently less amenable to Agile, Lean or DevOps. Plus, IBM has relentlessly enhanced the COBOL compiler to take advantage of its next-generation mainframe hardware.

The only two real obstacles to mainframe agility have historically been that:

  1. COBOL and other mainframe languages lacked Agile/DevOps- and Millennial-preferred tools.
  2. Enterprise IT leaders failed to pursue mainframe evolution.

The first obstacle is already being overcome. Intense innovation in mainframe tools has led to better functionality and better integration with mainstream technologies like Eclipse, Jira and Jenkins.

The second obstacle is trickier. IT leaders have been told for years that investment in the mainframe is foolish, because its days are numbered—despite obvious empirical evidence to the contrary. So it’s not easy for them to acknowledge—and act on—the reality that mainframe modernization is a profoundly wise investment.

So, will blatantly wrong-headed and self-serving voices dupe IT leaders into mainframe disinvestment? Or will IT leaders recognize that the facts clearly favor mainframe re-investment?

One thing is for sure. There’s no doubt which choice best serves the enterprise and its customers.