Are You Swimming Against the Rip Current of Mainframe Modernization?
Have you ever been in a rip current? I have. It was about 10 years ago near Melbourne, Florida. The waves were amazing and I was having fun getting tossed and turned—and then it happened. Right after a series of waves crashed down on me I got sucked under a strong rip current. Thankfully I knew what to do.
Growing up spending many summer days at the beach, I learned a respect for the water and what to do if something bad happened. You can’t fight a rip current. It’s too strong. If you fight it, you could easily drown. You have to let it take you out—and then, when it’s calm enough, you will have the energy to swim parallel to the shore to get away from the current and safely head in.
That’s what I did when it happened to me. In seconds, it pulled me out over 50 yards. When it stopped, it took me a few seconds to get my bearing, then to safety—and as I did, I shuddered to think what might have happened if I tried to fight it.
There is a rip current effect within certain mainframe “modernization” approaches as it’s often thought of in the context of replacing the mainframe with another platform. A common, albeit misguided, reason for doing so is based on cost—but there are lots of facts showing the mainframe is a highly cost-effective platform.
For some small mainframe customers, this migration modernization might be do-able and could even be justifiable. But for large mainframe customers, their mission-critical systems of record mainframe applications are as strong as a rip current—if you fight them, you will lose.
Modernizing Against the Current: Failed Migrations
Many companies have tried to fight the rip current and spent exorbitant time and money attempting mainframe modernization through application migration. But there are just too many long-term pitfalls involved with audacious migration strategies like converting large COBOL programs to Java for the benefit of only trivial short-term cost savings.
You should look at the long list of failed mainframe application migration stories from Planet Mainframe. These organizations fought the rip current and are now over their heads in time and money invested for naught. The mainframe applications they tried to migrate were too strong to swim against.
If only these organizations had learned a respect for the platform on which their mission-critical programs existed, they would have known there is a better way to modernize.
Modernizing with the Current: Two-platform IT
Instead of fighting the strong current of your mainframe applications, you need to leverage them. When you leave your most important assets where they belong, on the mainframe, you choose to swim with the rip current instead of fight it.
The foundation for this modernization strategy is two-platform IT. Simply put, this means leveraging your mainframe for business-critical applications and massive amounts of data, such as product source code and company and/or customer IP, while leveraging the XaaS resources from cloud providers for assets such as payroll or health benefits data that don’t differentiate your business from competitors.
Watch the video below to learn more.
This is exactly what Compuware has been doing for three years now. By moving our non-business-critical workloads from a hairball of distributed x86 servers to the cloud, we’ve converted x86 savings into meaningful investments in the business-critical assets on our mainframes. Instead of fighting against those mainframe assets, we’re leveraging Agile and DevOps best practices to modernize them.
Leveraging Agility and DevOps
Today, Compuware leverages Agile and DevOps processes and tools for COBOL and Assembler—maybe to the surprise of many, especially those who think mainframe modernization requires migrating off the platform, though it continually proves to be as modern as any other system (see the new IBM z14).
What’s more surprising, we’re using the exact same DevOps toolchain for both our mainframe and cloud work. That toolchain is a series of integrations between our mainframe products as well as with multiple partner and third-party mainframe and non-mainframe DevOps tools. This proves the platform technology and language aren’t what matter for achieving true business agility and delivery quality—it’s the culture, processes and tools you provide your people with.
If you’re wondering how you achieve mainframe modernization without migrating off the platform, I suggest you read “10 Steps to True Mainframe Agility.” It lays out the steps you need to take, the tools you need to use and the benchmarks you should look for along the way.
Stay tuned for an upcoming post that dives deeper into two-platform IT, including how the strategy reduces costs, increases investment opportunities and pulls IT into a new role where it can add more value to the business. Keep swimming with the current of your mainframe.