Modern CI/CD Tools with Legacy Mainframes with Tim Ceradsky of Compuware

Ledge: Tim, thanks for joining us. It’s really cool to have you.

Tim: I appreciate it. I’m always glad to talk about this. It’s a fun topic right now.

Ledge: Fantastic! Just so the audience get to know you a little bit, maybe give a two- to three-minute intro of yourself and your work and we’ll jump into the topic.

Tim: My team is what we call “field technical support.” Working for Compuware, I’ve got eighteen people on the team and we go out with individual customers and our market is primarily the mainframe which ─ many of your listeners may or may not realize ─ is still alive and well and it’s growing by leaps and bounds. It’s a pretty dynamic area.

What we’ve been able to do is actually apply the concepts of DevOps to the mainframe. Compuware is a company that’s been around for over forty years. We build a lot of the tools that systems get built on from being able to program and do fault analytics, solve problems, performance analyses, etcetera. But, then, leveraging what people do with DevOps has really taken a turn for making the mainframe platform much more powerful as people try to keep up with the pace of change.

Ledge: I totally understand. That makes a lot of sense. And you made a great point early on in our dialogue before we hit “record” here that the mainframe itself is probably associated with kind of this dinosaur legacy, not Agile kind of environment. But if you dig into the history of it, that’s not correct and it doesn’t need to be tied up that way.

I bet you have this conversation all the time with clients and developers. What is that like? Walk us through that way of thinking because the way Compuware does that, I think, is kind of unique and it’s a great niche.

Tim: Yes. It’s really been eye-opening for a lot of our clients that, traditionally, if you talk to folks and you throw the word “mainframe” out, in many organizations, they see and equate mainframe with legacy; they equate it with slow or ponderous ─ and insert your adverbs and adjectives here ─ but the reality is that the mainframe uses the fastest processors going. It has more data living on that platform being used. There’s nothing like it in the industry where you’re able to do so much processing and transaction processing on a mainframe platform. It outstrips any other platform you can put it in.

But you’ve got to have the right workload to run on it. It doesn’t make sense to try to run a web server on it that you’re logging in and uploading video to. It’s not its place in life. But if you need to be able to handle a credit card transaction that has to touch three or four different companies, lots of different networks, different systems and do everything in three seconds or less and it’s billions of times in a day, there’s really no other platform that does it as well as the mainframe.

So what we’ve been able to really focus on is taking people from realizing that it’s a really powerful platform. But the people who work with it are getting closer to that point in their lives where they want to be able to slow down, take the grandkids fishing, and relax a bit and being able to say, “Hey, you know what, there are ways to take advantage of what’s being done in the DevOps space and being Agile with this platform while still maintaining the key characteristics that make the mainframe what it is. It’s ‘fail never.’ It’s highly reliable, super high performance, etcetera.”

How do you kind of put those two things together?

The DevOps and the Agile approach are really the keys to doing the whole thing because you can automate the delivery of quality and the delivery of effectiveness in your service delivery in a way that just wasn’t possible using a traditional Waterfall approach.

And that’s what’s really helping unlock the value of the mainframe for the modern era.

Ledge: Obviously, people are thinking all about cloud now, even moving from on-prem. Where do these all fit together?

I imagine there’s got to be some kind of a layer of software and services in between that. There are, obviously, great use cases for being mostly cloud, all cloud. And what we’re saying here, I guess, is that there are obviously some missing legacy and/or maybe even new use cases for the mainframe. Is there a renaissance here? How do you, guys, see that?

Tim: What’s really helping people understand how to architect solutions is the realization to put the right workload on the right platform. Cloud systems are excellent at being able to be very flexible ─ scale up, scale down ─ and get global reach very rapidly. The mainframe is excellent at being able to push through transactions and kind of keep that corporate DNA in a safe location because your business logic on a mainframe and the enterprise data, those are the keys to the kingdom. And so, trying to find architectures that pull both of those pieces together is really important.

But it’s also empowering those people who are kind of the digital natives who look at things from a frame of reference in the cloud and giving them tools that allow them to exercise those same processes and the ability to have continuous delivery and continuous integration pipelines that stand up so they don’t have to know how to go in and code JCL and make all these little tweaks and things that people have learned how to do for thirty years.

Today’s information worker doesn’t have time to sit there and learn everything there is to know about one specific piece of code. They’ve got to be given a task, jump into it ─ they may never have seen the code before ─ understand it, make the changes, and push it into a DevOps pipeline that ensures that the change they make doesn’t negatively impact everything else that’s out there because you’re talking millions of lines of code and if you don’t have an automated way of testing all of that, then you’re back to the same old “Well, we’re going to have to study this. We’re going to have to test everything for six months before we can allow that to go to production.”

That’s why we’re kind of at a critical mass, if you will, in terms of DevOps around the mainframe because bringing all these pieces together allow us to blend cloud and on-prem mainframe in a way that really makes it powerful.

And the reason why we know this works is because we’ve done it.

In 2015, with made the conscious choice to move completely to an Agile stance. We got rid of all of our on-premise equipment except for our mainframe. Everything else is in the cloud. We even developed an interface with our mainframe by running our ID out of an Amazon Upstream 2 setup so we can deliver. Our desktop-based Eclipse environment is running out of an Amazon Upstream 2 instance.

It kind of changes the game whenever you realize that we’re plugging in the mainframe into Jenkins pipelines. We’re pushing information into Sonar. We’re working with release orchestration tools like XebiaLabs, Electric Cloud and others.

So we are right on that cutting edge. In fact, you can even find Compuware on the DevOps periodic table. If you’re familiar with that tool, we’re the only mainframe ISP that’s on it.

Ledge: That’s fantastic! So you are dealing in many cases like a gigantic monolithic collection of millions of lines of like COBOL or some legacy language. Is it largely that you’re, then, creating an interface that makes it easier to deal with and that is more modernized?

I mean, that code base still exists there. You’re not talking about replacing it with a more modern language, for example.

Tim: Correct. And it’s kind of a misnomer. When people first look at COBOL, they kind of treat it as “Oh my goodness, that’s the first thing we’ve got to start with. We’ve got to replace COBOL.” There are some cultural reasons why. We haven’t been teaching COBOL as a modern language in a while although COBOL itself has been a continuously developed language; IBM has been a great steward of the COBOL language for many decades. It does a phenomenal job at being able to do transaction processing and it’s a very maintainable language.

And the funny thing is, once you get the tools out of the way and people quit having to go to the green screen to be able to do all of their work, if you can set them up with a set of tools that allow them to work in the Eclipse environment like they’re used to doing with JAVA or anything else, and then you empower them with tools that allow them to scan the code and provide the structure chart that shows them everything on that massive program, lays it out for them, and makes it easy to traverse that, you give them Logic Flows that you click on a paragraph and it will diagram out the logic for you, you choose a variable and it will show you not only every place that variable is used but all the aliases that feed in and out of it and you really start to give people the tools that they need to be understand it, all of a sudden, they go, “Wait a minute! This COBOL stuff is easy.”

Anybody who is a programmer can sit down and read through COBOL and realize,

this is not big deal; I’ve seen all this stuff.

It’s procedural language so it’s not object oriented where you really have to be kind of intimate with it before you understand all the ins and outs of object oriented.

I would basically say that virtually every program out there could work with COBOL and be very successful with it. I don’t think there’s anybody out there who would be challenged by it. Going the other direction, it’s more challenging because you’ve got to learn more concepts.

So it’s more about the tools and the processes than the language itself.

Ledge: Do you, guys, imagine that there’s going to be sort of a COBOL renaissance or a mainframe renaissance? Would someone start out from scratch right now and think about solving a problem that way? Is that going to happen?

Tim: That’s a great question. I think that’s probably one of the more challenging aspects. I don’t know that that’s where it’s harder to get started on taking a new problem. There’s nothing really to stop someone from doing that. But I do think it’s much less likely.

There are companies all over the world that are leveraging their COBOL source code because it’s much more difficult to move away from COBOL than understand in those business applications. So it’s not about creating new applications and leveraging them. In most cases, I believe there are a few out there.

Being straightforward, I don’t think that’s the real emphasis of the industry. It is about optimizing and refactoring those existing COBOL programs to make them more efficient, to make them really more modern, and giving them the tooling to do it.

Ledge: I understand. Do you think colleges should be out there making sure everybody knows the stuff?

Tim: It’s funny that there are over three thousand universities worldwide that are still very actively teaching IBM mainframes. We work with many. We work with Northern Illinois University. We work with Robert Morris and several others that are all very actively trying to increase their mainframe competency.

And what they find is that their students who get some mainframe experience, if they’ve got basically anything mainframe on their résumé, get job offers almost immediately coming out of college because there are companies that are very actively hiring in that space.

In fact, I’m familiar with one gentleman who took his son on a college visit and the head of the computer science department was giving them a discussion where the prospecting students were standing there; and they asked the question, “Do you teach mainframe?” and the professor tried to tell them, “Oh, no, the mainframes have gone away; that’s old technology. Nobody is hiring for that.”

And so, my friend basically raised his hand and said, “You do understand that most of the major organizations around are hiring in that space.” And he tried to correct him: “Let me rephrase it. I’m a hiring manager at one of these locations that I’m telling you. I hire twenty to thirty new mainframe programmers every single year.”

We do that ourselves. Compuware has ─ I would say, 25% to 35% of our development staff at this point are five years or less out of college.

Ledge: This is really interesting for us thinking in terms of how to provide maybe a non-traditional learning path for existing freelancers who are probably going to be having grown up on Full Stack JavaScript, maybe some more of the C, C++ Java, lots of Python.

So is there a learning track that could make them attractive for these highly lucrative, potentially more available and more interesting roles particularly through the types of things that you, guys, are doing where they can say, “Okay, this isn’t just a dusty monochrome interface anymore and maybe I should take a look at this”? How does a current digital native or Full Stack JavaScript developer even begin to look at this stuff?

Tim: There are a lot of resources; IBM is pretty good about putting out some resources. There’s a user organization called “SHARE” that puts on a conference couple of times a year and there are typically quite a few workshops, labs, etcetera at Share to participate in.

There are DB2 environments. I would really suggest focusing on a specific technology in the DB2 or CICS or Websphere, etcetera as a starting point.

Another one would be is if you’re an expert in DevOps tools, there are companies that are very actively looking for trying to understand how can they leverage infrastructures like Jenkins, CloudBees, and SonarSource and taking some of those technologies that they may have had experience with from the Java world and being able to help companies think through and architect how to bring in new platforms such as the mainframes into their pipelines and be thought leaders around that.

Another really heavy area that we’re seeing a lot of traction in right now is automated testing. The Java world was kind of a leader in terms of JUnit and technologies and testing frameworks. The mainframe Compuware actually is ─ we’ve built a product called “Total Test” that provides automated unit testing, automated functional testing. We’re building in regression testing and so on and helping customers think through the practices of how to actually leverage automated testing to help increase their code quality is really a key area and I think that’s an area that people are going to need help with for years to come.

Ledge: That’s fantastic. This is really interesting stuff, Tim. Thank you so much for sharing with us. This is a new area for me as well. It’s really neat to think about all these things that we’re starting to use for your fast growing startups that you’re able to bring those to bear on these more legacy-style environments and really bring it up to speed with the Agile practices.

Very cool! Thanks for spending the time with us.

Tim: Absolutely! We love talking about it and we see clients everyday who have been struggling in this type of thing for years and it’s like you’re shining a light on their struggle and bringing them to the forefront. I’ve actually had distributed teams that, once they’ve been through and they’ve started evolving what we’re doing in the mainframe, they’re coming to us and asking, “Can you help us do this on the distributed type because we’re kind of leapfrogging in many respects?”

Being able to do the visualization of what we’re doing is pretty remarkable. So, yes, it’s very exciting to be a part of it.

Ledge: Thanks for sharing with us today. I really appreciate your time.