Should DevOps for Mainframe be a Product or a Culture?

Or, Why You Must Still Write Letters to Santa to Make Your Infrastructure Truly Fault Tolerant

June 21, 2023

I have been working as a DevOps engineer in the world of Mainframe for some time, and I’ve seen how DevOps for Mainframe started as an obscure topic that nobody wanted to touch and grew into the idea on everyone’s mind.

In particular, I’ve come to see that the way we are currently approaching this discipline has helped us grow but it has now reached some limitations.

Why DevOps and Mainframe Took So Long to Merge Together

Historically, DevOps and Mainframe took a long time to come together. While DevOps quickly merged with most other corners of the technology landscape, both DevOps and Mainframe initially viewed each other with a lot of suspicion.

Most Mainframe people were opposed to DevOps and saw it as a threat. They believed DevOps was just another modernization trend that was going to try to make Mainframe less important, to take critical processes away from Mainframe engineers, and to overall make organizations want to throw away their Mainframes.

The relationship between DevOps and Mainframe has only really thawed over the last few years, due to a few big changes.

Get Free Mainframe DevOps Solutions Guide

Optimize Your DevOps Practices

GET FREE GUIDE

What Changed? Why DevOps and Mainframe Began to Join Forces

There was no single event that made DevOps people and Mainframe people shake hands, come together, and begin to make peace. Instead, a few separate changes.

New IBM^® Mainframes arrived
Mainframe engineers — are becoming younger, and are naturally more open to new approaches
Mainframe technologies have developed APIs, CLIs, and other easy integrations with other next generation technologies
Multiple groups — came to realize Mainframe is not going away

These changes added up slowly, and Mainframe groups began to adopt DevOps principles and practices in small drips. And as they did, everyone began to experience the tangible benefits of bringing Mainframe and DevOps together through automation and modernization.

This has become a hot topic at every Mainframe conference, and there are many vendors looking to jump on the trend and bring the two disciplines closer together.

Unfortunately, this merger has been both a good thing and a bad thing.

A Double-Edged Sword: The Current State of DevOps for Mainframe

Five years ago — when the two fields were first starting to merge and DevOps for Mainframe was starting to become a concrete, well-defined thing — there were no real tools to drive this transformation. Everyone was starting from nothing and had to create their own tools and approaches from scratch.

But today there are standardized tools and approaches to bring DevOps to Mainframe. And this is a very good thing! It’s alleviating a lot of headaches and accelerating the modernization of the Mainframe discipline.

In some ways, DevOps for Mainframe has become a commoditized trend. To catch this trend many Mainframe vendors are just putting “DevOps” in the name of their products.

This tool-based approach has created a situation where DevOps for Mainframe is no longer seen as an exciting new field of development. Instead, “DevOps for Mainframe” has just become a set of products or solutions for a vendor to sell, or for an organization to buy, like any other off-the-shelf piece of software.

Three Problems Created by Generic “DevOps for Mainframe” Tools

While there are many problems created by the current approach to bringing DevOps and Mainframe together, there are three big ones causing most of the headaches.

First, DevOps tools for Mainframe are still focused on integrations.

Remember — DevOps came to Mainframe much later than DevOps came to other technology disciplines.

For example, most of the broader world of DevOps and technology are no longer attempting to integrate one million unnecessary and disparate bodies, first into large and incomprehensible presentation pictures and then into pipelines. Instead, they want to put everything into one place, already integrated, so they don’t have to try to screw their monitoring and test management tools into their pipelines themselves.

However, DevOps tools for Mainframe are not there yet. They are still very focused on providing one-off integrations, instead of creating unified solutions.

Second, DevOps tools for Mainframe are young and unstable.

DevOps for Mainframe is still a young phenomenon, and the tools that drive it — by attempting to launch something on the Mainframe from outside the Mainframe — are still extremely unstable and poorly supported.

Every Mainframe developer has cried at least once because Jenkins does not have good Mainframe plugins, and they have to come up with a barely-working crutch every time they want to create an automation task.

And every Mainframe developer has written a letter to Santa Claus so that, say, their IBM UrbanCode^® Deploy agent doesn’t fail at the most important moment of some production deployment, from overflowing the logging space on Windows or Unix.

Now, let’s be clear — this is not the fault of the companies and teams creating the DevOps products for Mainframe. All of them are cool guys doing interesting and important work. But we all must face the hard truth that there aren’t enough DevOps for Mainframe users in the world to debug these tools in different environments. (Yes, I’m talking about checking DevOps solutions on customer environments, one way or another.)

Overall — and it’s no one’s fault — this space just is not very mature yet, and the infrastructure around Mainframe with DevOps just is not yet ready to generate and support reliable out-of-the-box tools.

Third, DevOps tools for Mainframe don’t address unique risks well enough.

Finally, this instability is a big problem because Mainframe is primarily used in industries and environments that cannot accept the risk of their systems failing — ever.

Think about it. Many Mainframes are located inside the biggest banking conglomerates in the world. For these companies, a minute of downtime can lead to the loss of millions of dollars. In these environments using unstable tools to implement changes to production systems is an expensive pleasure, to say the least.

Because of this, many real-world Mainframe teams are simply too scared to use unreliable out-of-the-box tools to try to bring DevOps to their organization.

In sum: A tool-based approach to DevOps for Mainframe is not enough.

While we need vendors to continue to develop out-of-the-box tools, products, and solutions to help drive DevOps for Mainframe transformations, we must also admit that right now this approach and the products that it generates cannot solve every problem along the way.

To solve these problems, and to advance these transformations, the world of DevOps for Mainframe must go back to the roots of what this movement is all about… a shared culture of automation and collaboration and not (only) a suite of consumable products.

Restoring the Culture-First Approach to DevOps for Mainframe

Before we dig in too deep, let’s first be clear about one point — DevOps tools for Mainframe and solutions are going to get better.

But the reality is — today and tomorrow —Mainframe will always be a complex field with a lot of variation between organizations and teams. Which means no matter how good our Mainframe for DevOps products get, every development team will always have to do a lot of their own work to develop or adapt tools and solutions to fit into their unique Mainframe context and to overcome their unique challenges.

To meet this reality, we can’t think about DevOps for Mainframe as just a set of engineering best practices and generic software. We have to think about it as a flexible, adaptable culture and mindset that we live every day.

To do so, we need to move the DevOps for Mainframe away from only talking about tools and solutions, and reunite our community around things like:

Doing DevOps, and not just purchasing tools
Adopting common values and a culture of automation
Building new mindsets based around breaking code into small parts
Automating everything you can, and helping your colleagues automate everything they can
Developing a sense of shared responsibility where everyone must ensure the final product works at an acceptable level of quality
Continuing to love Mainframe, and understanding that DevOps will not replace Mainframe but only make it better

This last point is most important. To make DevOps for Mainframe stick we must convince Mainframe people that the world has changed, that these transformations are doable, and that if they adopt DevOps no one is coming to throw away their Mainframes or to take their Mainframes away from them.

If we can achieve this cultural change then Mainframe teams will actually embrace DevOps as a new way of doing things, and not just some new tools to tack onto the old way of doing things. It’s the only way forward — to both get past our current sticking points and to ensure Mainframe with DevOps continues to evolve, and to overcome its challenges, and to deliver the benefits we all desire.