BMC Compuware ISPW Reviews

We have five affiliates and we have installed ISPW in three of those affiliates. One of the things that we had as a goal was to standardize. Until we made the decision to go to ISPW, all of our affiliates had different source statement management processes. They all functioned differently. Our support teams were outsourced, and we couldn't really move a resource from one affiliate to the other without completely retraining them, because their processes were so different. They used different tools. We had CA-Panvalet, we had Endeavor, and we had some in-house tools. There was no standardization. Not being able to move resources was very limiting.

When we installed ISPW one of our goals was to standardize processes as much as possible so that if we needed to move resources from one affiliate to another affiliate, they could transition across with no training based on standardized ISPW processes. Retrieving the code, developing changes, setting up testing, reviewing results and staging for deployment to Production, would all be done the same way. That was the first one of our major goals.

A second goal was to install a system that would track the change process and provide real time information to the developers as to the status of their programs. This information was not readily available in our current process. This step was key to moving to a more Agile model of development. 

It helped us move more toward an Agile development path. We are closer to that than we had been before because one of the main functions of ISPW is tracking code. Information is real time and displays where the code is and who has it checked out. That is critical information when you have 250 developers in different countries and so many different things are happening at the same time. One of the drawbacks of going to an Agile-type platform is you have to have the tracking  information real time and easy to understand. With ISPW you have that information at hand all the time.  

In terms of time savings, with our previous tools there were different platforms and a lot of customization. One issue with our old system was the process required developers make a request to a special department for code to be made available for change. This could take as long as 3 weeks to get access to programs and JCL in order to start a project. With ISPW the developer has the ability to retrieve all of the components they need into their containers. That's something they can do within minutes. From a time standpoint, that has resulted in huge savings for each project. 

We use it for change management and source control.

It has provided us with a number of improvements. The biggest improvement is its deployment facility. It does our CICS NEWCOPYs and our Db2 binds for us, whereas before, that was a manual process. It takes a lot of the workload off the operations folks and the DBAs.

We had parallel development before, but the way ISPW implements it is better. It has more control and oversight of the process, whereas before, it was like the Wild West. Everybody could have their own package with their own version of the component in it, and they had to do what ChangeMan called an audit before they could promote it. ISPW is constantly aware of it. It notifies when someone else is using or has a different version of that component. It protects the source better than ChangeMan did.

It's also starting to help our organization realize the benefits of DevOps. We're fairly new, and we still haven't had the Topaz training yet, where a lot of that stuff will be more apparent. We'll be able to use the GUI tools.

It helps us develop COBOL while juggling other responsibilities. This is less time consuming than using the old product

We have seen an improvement in the rate and level of quality at which we deploy changes. I don't know if I could give you an accurate percentage. It's probably 100 percent. It's much better. 

Our primary use case is managing and deploying code. We also build outputs from the code. 

I think the most valuable features are code management, code deployment, and code generation. The fact that those three features are included makes BMC Compuware ISPW a robust product. If one of those features was missing, it would be less robust and less interesting. But because it has those three features, it is a very good solution for code development and management.

Today, the mainframe is our foundation where our customer data lives. Interfacing with the mainframe is how our distributed systems provide services to our customers, regardless of the channel  used (Mobile, User Interface, etc).  Until an alternative cost-efficient technology is identified that has the processing power of the mainframe, our focus will remain on modernization.  Our focus is to utilize tools and technology that allow for more automation, real-time services, and communication with our distributed products in a way that reduces cost and increases efficiency.

With the use of ISPW, we were able to reduce our deployment time for specific applications  by utilizing the auto-deploy features. Using tools such as ISPW also increases our mainframe developer’s knowledge of Eclipse-based tools that the distributed products utilize. 

We’re also experimenting with being able to utilize distributed developers to see if they can utilize the  ISPW analysis tool to identify/make changes in COBOL without really knowing this technology.     

In 2018, we executed a migration from an LCM product (ASG: Allen Software Group company) to an ISPW in order to manage our mainframe programs (mostly Cobol, few C, and ASM).

• We use ISPW for SCM and ALM, built and deployed from the development environment to the production environment on IBM z/OS.

• ISPW can be used on both Eclipse Neon 4.6.3 and ISPF panels.
  

• In our company, developers are using ISPW in Eclipse to have the benefit of an IDE and to use others plugins from Compuware Topaz solution or other providers we have.

• ISPW administrators and production teams use ISPW on both Eclipse and ISPF panels depending on the tasks they have to manage (a part of the administrative task is not available in Eclipse plugin).   

• It helps us with the changing of SCM and ALM products, and also to change the life cycle including two branches.

Of course, it's still a recent migration, so we are still in progress to improve our organization and use of the product.