Skip to content

May 15, 2018

Case Study: IBM DevOps Transformation

By IT Revolution

Rosalind Radcliffe is an IBM Distinguished Engineer responsible for DevOps for Enterprise Systems. She helps navigate transformations for both IBM and their clients.

Below, we’ve transcribed the key takeaways and main highlights of her presentation where she shows how a traditional z/OS product that’s been around forever can also transform (which you can also watch on YouTube here.)


When we started this process, we had release cycles that varied from relatively short to 18+ months. Our goal was to bring all of our z/OS development tools together in a single delivery pipeline in order to:

  • Deliver better value to our clients
  • Make sure that they had an integrated stack
  • Make sure it was easier for them to adopt
  • Allow us to deliver function faster and more efficiently for them (we were shooting for monthly deliveries)

With our wonderful set of products to delivering together instead of separately, we’d have a full DevOps pipeline for z/OS Explorer and all the products that sat on top of it that could give us the value and give you the value, and make it easier for all of us.

What we did

We created a single development pipeline.

Now this was a challenge. We have 17 separate products. They actually are still separate products, and in some cases, they’re totally separate. But we wanted the IDEs and the environments to be built together, so we literally stopped development for a while and said, “Other than critical customer situations, we’re not gonna do anything else. We’re gonna build a delivery pipeline.” And it took about four months.

We decided to do this in pieces. So we started with the base set of products; so z/OS Explorer plus CICS tools to get that base there. Then, we added products throughout the year, and we continue to add products.

So any product that has an Eclipse based IDE, that is related in any way, shape, or form to mainframe development will end up on this pipeline.

The important thing to recognize about this is, while yes, it’s Eclipse based IDEs, it’s also the backend pieces of the development for this. It’s not just Java development, it’s traditional PLX development that we use internally.

It’s an assembler development.

And we have the DevOps pipeline for all the parts of this. We don’t use separate tools. We have one toolchain, whether or not you’re building the Z side or the distributed side, we have one SEM. No separation, all the code is together. Everybody can see what everybody’s working on, etc.

We want to make sure that the pipeline is consistent, that when you’re doing DevOps, it’s doesn’t matter if you’re doing DevOps for Z or distributed, it’s one story, one set of processes, one set of capability.

Fun Facts

  • 94 releases, 17 products
  • We’ve gone to one month releases for fixes (and small function)
  • It is a single repository, so they’re all sitting in this environment. They have a set of automated tasks with them. They run every night so that we can deploy the function and we have what we need to deliver customer value.

What’d we learn?

Well, we had an advantage. We had the CICS team who had already started. They had started in 2005. So we had a lot of good lessons learned on how to do things and how to do this transformation.

But, what we ultimately learned was that:

  1. You have to give the teams time to work. You have to give them the education, the training, the understanding. They have to know what they’re gonna be doing in order to do this. However, they will less productive, in some cases, as they start. In our case, they were already using modern development tools so that wasn’t a problem. In the CICS team case, in 2005, they weren’t, so it does take somebody who’s been using a green screen a little while to learn how to use an Eclipse based tool. Their productivity was not the same day one. So give them time to do this. Give them time to learn.
  2. We spent the time to work across teams. We took the lessons learned from each team and adopted them into the pipeline to help improve the next product team’s adoption.
  3. Management support is essential. Imagine telling a development team, “You’re not shipping any function for the next four months.” See how well that goes over with the sales team saying, “I want new function.” No, you’ve gotta stop. You have to get support. You have to acknowledge that this transformation is then going to give you value, so that you can provide much more value, much faster.

But what else did we do?

  • We took CICS team information and their capabilities and the rest of organization and we created a CICD community so that the organization has the support across all of IBM in transformation.
  • We have slack channels so that we can discuss what’s going on, so people can ask questions, so people can information about how to do this.
  • We have a golden topology for z/OS development. If you’re internal in IBM, we have one topology that specifies the set of products that you’re going to use, and I’ll share that externally as well so you can all see it. But it has things like Jenkins on it, it has rational team concert on it, it has zUnit to do united testing. It’s the standard set of tools and products you would need to do development.

Closing Thoughts

As you can see, there is no reason that the mainframe should not be included in your DevOps transformation, so please remove the line ‘mainframe excluded’.  I need everyone to help the mainframe developers understand that, yes, the mainframe can do DevOps.

We need to kill this concept of two speed IT because it doesn’t work. Clients explain that it doesn’t work. We need to help everyone understand multi speed IT is really what we need.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

No comments found

Leave a Comment

Your email address will not be published.

Jump to Section

    More Like This

    Industrial DevOps: Bring Agile/DevOps to Cyber-Physical Systems
    By Suzette Johnson , Robin Yeman

    The following is an excerpt from the book Industrial DevOps: Building Better Systems Faster…

    My Fit Experience: Leaders
    By Lucy Softich

    In previous articles, I've been going through some of the excursions from André Martin's…

    2023 Fall Releases
    By IT Revolution

    We have had quite a year so far, and it only keeps going! As…

    Learning Sprints at DevOps Enterprise Summit Las Vegas
    By IT Revolution

    We are just three weeks away from (hopefully) seeing you all in Las Vegas…