Case Study: IBM DevOps Transformation

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.)

WHAT WE WANTED

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

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

• 
• 
•