Mainframe Change | Compuware ISPW | Mainframe SCM | DevOps
September 27, 2018 DevOps

The Mainframe Isn’t Leaving—It’s Changing, Man

What can I say that hasn’t already been said about the life of an experienced mainframe developer?

As a young person in the ‘80s, it was trendy to start a career in IT. While I was excited to conquer the world of technology, it became daunting and depressing when I started hearing that becoming a mainframe developer was not the way to go.

“The mainframe will die.”

“You will be out of a job soon.”

But, young and innocent and with no other option, I continued as a mainframe developer, waiting for the day that I would have to reskill myself on another platform.

Then the Y2K monster awoke and began to scare the world. The fate of civilization was suddenly in the hands of people like me, and the demand for highly skilled mainframe developers skyrocketed. Even so, the perception that the mainframe would die persisted. It would just happen after Y2K now.

As time went on, newcomers to the IT world wanted to learn the new platforms and languages. They saw already middle-aged mainframe developers like me who started in the ‘80s as people from the “Dark Ages” sitting in a room just doing their thing.

What the world didn’t realize was the mainframe would never go away—and that a developer skill shortage had begun. We in mainframe IT didn’t even notice this. We, and our dear “green screen,” survived Y2K after all, so we continued doing what we did best without bothering to fight the perception that the mainframe was going to die.

It’s no wonder, then, why mainframe teams like the one I was on at Standard Bank, a major international bank, didn’t bother to change. Our way of working became routine. We knew we were good at accomplishing the critical role we played with the tools and processes we had in the silo we had become accustomed to. We didn’t need to change the mainframe for anyone and we didn’t want to. We weren’t onboarding new team members, so it wasn’t a challenge we needed to address.

Why Change, Man?

To be honest, probably due to this complacency, there were a lot of things that were just part of the job and, therefore, were never questioned whether they should change. One of those things was our use of Serena ChangeMan (now Micro Focus ChangeMan) for source code management.

It was implemented before Y2K and became one of those tools that was mandatory to use. Prior to this, the source code was held in unsecured libraries; we suffered from code being overwritten and even source code being lost altogether.

The administrator for the tool, a job not many people were interested in, worked long hours to keep ChangeMan going. Nothing much happened with upgrades, streamlining or talk of replacement because there were no other recognizable competitors. Similar tools, but nothing that made anybody excited enough to want to replace ChangeMan.

The effort to change also seemed to be too much for anybody. The only interaction was renewing contracts time after time. Everybody became laid back because they thought ChangeMan would always be part of a mainframe developer’s life.

From Change to Transformation

In 2016, a young and upcoming visionary in the company, Jolene Olivier, wanted to know what our mainframe strategy was. She understood the importance of the platform in supporting the customer-facing innovation the organization was driving. To everybody’s shock, there was no defined strategy; well, not one we could coherently articulate.

So, the journey began and very quickly a strategy was formed and accepted by senior management to make our mainframe agile and included in a DevOps framework supporting Continuous Integration/Continuous Delivery.

Read Standard Bank's Story

We understood the threat to our business by new, smaller technology-based banks. Our IT organization had to react, otherwise we would just be another casualty in the long list of businesses being blown away by these disruptive forces. Many of us realized this would require modernizing our mainframe culture, processes and tools.

In response, we started migrating to Compuware ISPW before our full strategy had even been finalized because we realized how critical a modern Agile SCM solution was to our modernization aspirations and that ChangeMan would only hold us back.

When the ChangeMan team woke up from their “laid-back holiday mentality,” they were halfway out the door. Decisions were already made that the upcoming contract would not be renewed.

The ChangeMan team tried to fight back and went about in disbelief, spreading the word that ChangeMan was too integrated and couldn’t be replaced. However, the new buzzword in the company was “ISPW.” Everybody sat upright to figure out what this was about. You can just imagine the apprehension and anticipation it created.

Compuware ISPW | Modern mainframe source code management

ISPW for Agile source code management – parallel development, Life Cycle chart, end-to-end tracking, audit trail, impact analysis

The ISPW team had to work fast, hard and precise not to give reason for ChangeMan to get a foot in the door again. Many still believed it couldn’t be done, but the ISPW team (my team!) knew change was necessary and possible, so we remained focused and not distracted by noise.

Eventually, even the most stubborn mainframe developers, by now close to retirement, could see the benefit of ISPW and the DevOps journey that lay ahead. These were exciting times, and they looked forward to the new ways of working.

A Change of Scenery

When I think about all the people over the past 30-plus years who told me the mainframe was dying and those who thought the mainframe would never change—I want to go back and tell them the mainframe is still in its teenage years; it is young, reinvigorated and open to change.

I want to tell them, “I did re-skill myself, but on the mainframe!”

I’m re-skilling myself even further now as a Compuware solution consultant. I cheer on my former colleagues who are accomplishing amazing feats of agility and DevOps on the mainframe, thanks to a change in culture and modern processes. In my experience, Compuware tools very effectively integrate with best-of-breed DevOps solutions like Jenkins and SonarQube to enable these changes.

To companies out there that are stuck wondering what to do about their mainframes: Don’t be afraid to “Change, Man” ????

It’s time to bring this platform into the exciting new era of Agile and DevOps. I know from experience, it can be done. Who better to start the journey with than The Mainframe Partner For The Next 50 Years, Compuware?

I’m proud to say I am a true DevOps mainframer! Reach out to me at [email protected] if you want to chat and learn about how Compuware can help you become one, too.