Step 2: Modernize Your Mainframe Development Environment

Step 2: Modernize Your Mainframe Development Environment

Part Two of the “10 Steps to True Mainframe Agility” Series

Send Us Feedback

Listen on Itunes

Listen to Stitcher

Transcript

Mike: Hey everyone, this is Mike and I’m here with Steve Kansa, who is one of our product managers here at Compuware. Steve, thanks for joining me.

Steve: Great to join you, Mike.

Mike: So, we’re talking about step two in our series “10 Steps to True Mainframe Agility” today, which is based on our eBook of the same name, and step two is to Modernize Your Mainframe Development Environment. And, Steve, you’ve done a lot to really help Compuware enable this for customers. So, to give everyone a picture of this, how has mainframe development traditionally been done and why should that environment be modernized?

Traditional Mainframe Development Practices

Steve: So, the mainframe is one of the older platforms on the planet, and mainframe development has been done in a variety of different ways over the course of time. But really, the majority of mainframe development was done long before concepts like Agile development and extreme programming were mainstream concepts.

So, what’s been done traditionally is longer release cycles, potentially working on a large number of requirements that stay in a development cycle for a very long period of time. And then they go through a longer test cycle to verify those things. So, the overall release cycle has traditionally been a much slower cycle, or mainframe development has gone into stasis in some companies where they’re really only doing maintenance-type tasks instead of doing things that really help the company move forward and modernize and compete in the digital age that exists today.

And the other aspect of mainframe development is, again, it being an older platform, a lot of development has been done with tooling that’s been built up over the course of years, but that tooling really wasn’t built an agile sense. So, the tooling tends to be green screen tools, and those tools aren’t really enabled for the modern digital age.

Changing Your Culture to Modernize Mainframe Development

Mike: So, what do you need to do, then, to enable your mainframe for that modern digital age?

Steve: One of the key things that I think makes companies successful in this isn’t just putting new tools in place and then working in the same processes and the same approach that you’ve done traditionally. You really need to change the culture, and the best way to do that is to put new processes and new expectations in place to really tackle the company’s tough business challenges. Based off setting those goals for your organization, the culture will adapt to meet that.

So, I think it’s a key thing for leaders to consider; don’t think you can quickly fix your culture by dropping in a tool. You really need to holistically change the requirements of the organization to meet the needs of the business today. The tools that you need in order to make that successful transformation can be put in place once you’ve set the new expectations.

Why a Modern Mainframe IDE Is Critical

Mike: Okay. Now, when you’re ready to get that right tool in place—because I think it’s fair to say a green screen tool environment won’t support that culture that you’re saying needs to adapt—when you’re on that right path, what makes an IDE (integrated development environment) so critical to supporting that?

Steve: Your IDE is where your developers are going to spend the vast majority of their time, particularly within the new requirements of their jobs. You need IDEs that can perform the tasks that are required for that job. So, you need an IDE that allow you to quickly analyze your large complex programs and figure out what you need to change. You need to be able to do automated unit testing as you’re making those changes so you’re ensuring quality along the way. And you need a toolchain integrated in with that.

That’s sort of the fabric that the developers are working with. As they’re making changes, they’re getting rapid feedback from things like Continuous Integration. So, you need to create that environment, that experience for the developers that’s required to meet the business needs of today.

Empower Every Mainframe Developer to Be Productive

Steve: And you know, the tooling needs to be something that both existing development resources and maybe historically traditionally experienced mainframe resources are comfortable with, but also something that allows you to bring in new talent to replace the people that may be leaving the platform through retirement and give them something that excites them and give them something that matches the expectations they’re going to have as a modern developers.

Mike: So, IDEs are obviously a huge help to next-gen developers because it’s familiar and it’s intuitive and they’re not familiar with the mainframe or its tooling, but they are familiar with, an IDE, an Eclipse-based environment. So, it’s obviously beneficial for them. It helps them become pretty productive quickly versus the green screen.

Now in terms of the traditional developer who’s been using a green screen for decades sometimes, and they’re really efficient with it, they’re fast with it—what is the benefit for them moving to an IDE? Will it increase their productivity?

Steve: Yes, it definitely will increase their productivity to meet those new needs. There are people that are very experienced, that are very efficient in tasks, but when you go to those people and you ask them to produce net new requirements or you ask them to work on a mainframe application they haven’t seen before, those productivity gains and efficiencies that they’ve gained over the years will drop down. They need tooling that allows them to be productive more quickly.

So, even though they may be efficient in editing through ISPF in a particular application, when they’re put against new requirements, they really need the capabilities of the analysis, the ease of use of debugging in a modern IDE, and again, automated unit testing, which is something that really did not exist on the mainframe until Compuware brought out Topaz for Total Test. So, they need to embrace automation and do things in new ways that just really are impossible in the existing tooling they may be familiar with.

What Makes Compuware Topaz Workbench Unique

Mike: Okay, and I think that’s a great way to segue into my next question. Compuware offers an IDE called Topaz workbench. What makes Topaz workbench different and unique compared to other IDEs out there? And you just mentioned, you know, automated unit testing for instance, that’s one thing that you can do through Topaz for Total Test, which is through Topaz Workbench. Are there other things?

Steve: Yeah, there are a lot of unique capabilities, and really, what Compuware is very focused on is providing the best developer experience for people using Topaz Workbench. So, the ease of use, the discoverability of how you flow through the tasks of analysis of large applications, interactions with our source control ISPW, the ability to do automated unit testing and flow through those tasks very rapidly, those are really things that sets us apart from existing approaches and other mainframe IDEs.

Mike: I think one other thing that would be cool to touch on for people who are listening that might not know this is that new feature that we released back in January, Topaz Team Profiles. That’s a really cool way teams can start sharing knowledge and, for developers who are less familiar with something, setting them up to be more productive quickly. Can you explain that?

Topaz Team Profiles

Steve: So that is definitely a key feature of what we built and designed, Team Profiles. It serves two different use cases. One is that initial new developer that may be familiar with the green screen, they’re given Topaz, and what we wanted to do is make it very easy for them to get up and going.

So, we built a feature that allows you, through a central capability, to define all the configuration within Topaz and then share that configuration across the team. So when that developer logs in and they’re not going through the initial setup of Topaz, they’re able to instantly go in and, for example, start debugging a program or see datasets related to a particular application, to have access to already defined data editor requests, to be able to view data related to a particular application. So, we want it to be able to give people a quick jumpstart and jumpstart their productivity in Topaz.

And then the other use case is, maybe you’re off, you’re going in Topaz, you’re familiar with a particular application and you’re asked to work on a net new application again. Through Team Profiles, we allow you to share knowledge of what makes up that application and across the team. So, you can bring in new people that might not be familiar with the application or even existing resources that are very experienced in some domains but not experienced in these other domains.

We really wanted to be able to kind of institutionalize that knowledge that may exist for an application and instantly transfer it into Topaz so people can get up and going quicker and start making changes to those applications.

Mike: Awesome. Steve, thanks a ton for sharing all that. For those listening, if you want to read our eBook “10 Steps to True Mainframe Agility,” I’ll put the link in the show notes. Otherwise, we’re going to keep covering the remainder of the steps throughout this series. So, Steve, thanks a ton again.

Steve: Thank you.