We changed our name from IT Central Station: Here's why

BMC Compuware ISPW OverviewUNIXBusinessApplication

BMC Compuware ISPW is #4 ranked solution in top Software Configuration Management tools. PeerSpot users give BMC Compuware ISPW an average rating of 10 out of 10. BMC Compuware ISPW is most commonly compared to CA Endevor Software Change Manager: BMC Compuware ISPW vs CA Endevor Software Change Manager. The top industry researching this solution are professionals from a computer software company, accounting for 26% of all views.
What is BMC Compuware ISPW?

A modern, end-to-end Agile source code management, release automation and deployment automation tool that enables mainframe application developers at all skill levels to fulfill business requirements, optimize code quality, and improve developer productivity through mainframe DevOps. With ISPW, developers can:

  • Easily perform concurrent development to support Agile Development practices
  • Leverage Jenkins plugins to manage code throughout the lifecycle
  • Use REST APIs to automatically connect mainframe applications into modern DevOps toolchains
  • Collaborate with other developers through features like alerts when another programmer has checked out code
  • See versions of a program at multiple points in the development cycle to prevent incorrect overlaying and ensure smooth code integration
  • Access an intuitive relationship visualization that guides users to failure points
Buyer's Guide

Download the Software Configuration Management Buyer's Guide including reviews and more. Updated: January 2022

BMC Compuware ISPW Customers

mBank, Standard Bank

BMC Compuware ISPW Video

BMC Compuware ISPW Pricing Advice

What users are saying about BMC Compuware ISPW pricing:
  • "The price point is great."
  • "I like the seat-based licensing much more than MSU-based licensing, and that the cost has been competitive."
  • BMC Compuware ISPW Reviews

    Filter by:
    Filter Reviews
    Industry
    Loading...
    Filter Unavailable
    Company Size
    Loading...
    Filter Unavailable
    Job Level
    Loading...
    Filter Unavailable
    Rating
    Loading...
    Filter Unavailable
    Considered
    Loading...
    Filter Unavailable
    Order by:
    Loading...
    • Date
    • Highest Rating
    • Lowest Rating
    • Review Length
    Search:
    Showingreviews based on the current filters. Reset all filters
    Sr Consultant Project Manager with 10,001+ employees
    Consultant
    Tracks code during the change process so that more than one group could have code checked out for change. ISPW provides this tracking info real time helping move toward a more Agile environment.
    Pros and Cons
    • "One of the features that the developers like is that they can retrieve what they need with the tool. They don't have to go through some process or request something be done by another team. They can get the programs they need, compile them, retrieve the JCL and alter the JCL if they need to, and put these programs wherever they need to go for their testing."
    • "When you're setting up the parameters for how ISPW will work in your shop, there are a lot of questions that have to be answered... BMC Compuware should have more in-depth explanations about what the choices in each question mean. If you pick A, what does that mean has to happen? What does that impact? If you pick B, what does that mean? What does that impact?"

    What is our primary use case?

    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. 

    How has it helped my organization?

    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. 

    What is most valuable?

    One of the features that the developers like is that they can retrieve what they need with ISPW. They don't have to go through a process or request something be done by another team. They can get the programs they need, compile them, retrieve the JCL and alter the JCL if they need to, and put these programs wherever they need to go for their testing. They can promote all the way through to the production step. I know that might make a lot of companies nervous when we talk about the fact that developers can promote to production. What that means is the developers promote the code to the point of being ready to be released into production.  The release step is still controlled using your current approval process. This  gives the development staff a lot more control over what they're doing, and it dovetails nicely into an Agile process. ISPW is really great at giving the developers access to all of the components all the way through the process.

    The control of actually putting code into production is more about the "when" and not the "how." In most companies, your change-control coordinators or business analysts,  or managers that release code into production environment, will still do that last step. That's all controllable and secure at different levels. But it really gives the development staff a way to get everything where it needs to be, staged-up and ready to be released so that they can go work on something else. And the management of that movement into production is still maintained through whatever level you choose. 

    For how long have I used the solution?

    I have been using Compuware ISPW for about two and a half years.

    We installed it into three different affiliates within our company. We started that process in 2019 and finished in 2020. Our first installation was in June of 2019.

    What do I think about the stability of the solution?

    ISPW is a very stable product. 

    What do I think about the scalability of the solution?

    I haven't seen any limitations when it comes to scalability. The three affiliate companies that we converted to ISPW were very different in size. The first one was the smallest, and had a lot of vendor code rather than customized code. The second affiliate had much more customized code and was medium in size, while the last one was our largest and had a lot of custom code and some very old code.

    Our support teams are in five different locations and two different countries and there didn't seem to be any problems with that as far as access and speed. 

    How are customer service and support?

    Their day-to-day tech support is great. We haven't had any problems with it at all. We had some issues that we reported back to them and we got support right away. They have always been there to help us. I would rate them very highly and responsive to any issues we've had. They were very quick, answering our calls right away.

    We put some pretty heavy demands on BMC Compuware's professional services when we installed the solution. I required them to be on site with us every time we installed. They were on site at all three sites. We also had an implementation hotline set up for the first night of production support and they were there on the phone with us. They were physically in the building with us when we went live and were there at night on the phone with us when we went live. They stepped up and met our heavy demands.

    Having them on site when we went live was something we arranged after the fact, after the contracts had been signed by our company. When we started laying out the project plan they came on site for a week to look at everything we had and how we did things. After we went through all of that and start building the detail project timeline we requested that BMC Compuware be on site at   "GO-Live" and they were very accommodating. 

    How would you rate customer service and support?

    Positive

    Which solution did I use previously and why did I switch?

    Standardization was a key reason for switching. It was critical to standardize all of the development processes under a common Source Statement Management system. Before we converted to ISPW we were running 3 different systems at 3 different affiliates to manage source code. We converted those 3 affiliates to ISPW so that we could interchange our development resources without having to retrain personnel.  Also, the old systems that we were using were very expensive and ISPW's price point was extremely attractive. It gave us  more flexibility in being able to more development resources from one affiliate to another and the ability to standardize processes which allowed us to cut down on the number of people needed to maintain the different systems. 

    How was the initial setup?

    Deploying it is a complex process, but BMC did a great job of supporting that process and working with us. They answered our questions and tried to understand our environment so that all process were support in the ISPW installation. You should definitely engage the professional services group to help you with the installation. While it was very complex, it was also very thoroughly understood by the teams that we worked with. They did a great job, evidenced by the fact that we were able to convert to  ISPW from two different Endeavor sites and one CA-Panvalet sites,  with between 30,000 and 50,000 programs a-piece, and be up and running at those sites in nine months.

    I would certainly encourage everyone to engage their professional services and have a company team available to work with the professional services team. You need both sides. You need somebody within your company who understands what your company does, how all the processes work, and how each process will work using ISPW.  It's your responsibility, as a company, to own that process, and it's  BMC Compuware's responsibility to help you. It is not a case where you do nothing and they come and install it. You have to be engaged. And how you're going to train people should be talked about early in the process as well.

    It is a complex process, but as long as both sides, your company and BMC Compuware work together, the result will be a very positive experience. Our project was very successful and was completed on time and within budget. 

    When it comes to the actual installation, when you're setting up the parameters for how ISPW will work in your shop, there are a lot of questions that have to be answered. That's pretty normal with any software that you have to install, but because ISPW is a new animal and not very many people have a lot of experience with it, BMC Compuware should have more in-depth explanations about what the installation parameters mean and how each choice will impact your set-up.  I shared this feedback with BMC Compuware.

    For example, one of the questions was, "Do you want to have a brand new load library that ISPW promotes the programs into for Production?" Depending on the answer to that question you could cause a lot of additional work to be done. The installation steps should contain some pros and cons about the options you can pick.

    In terms of a deployment strategy, we picked some programs from several applications when we began the installation at each of our affiliates and we put up a test version of ISPW. Because we had a test area set aside for this work, we didn't interfere with anything else the development and production support teams were doing. We pulled real programs into the test version of ISPW and had our test team compile the programs, link-edit the programs, and test the programs using ISPW. We also used this test ISPW environment with real application code in it for training, so that when we had the developers sit down for those training sessions, they saw their real programs. 

    In terms of maintaining the solution, there doesn't seem to be a lot involved, although you will need an administrator. The first few months there are certainly bumps that have to be worked out, but they were always there to answer our questions. After that, on a day-to-day basis, once you get the primary functions covered ISPW is very stable. There isn't a lot of breakage. The care and feeding have been very minimal since we went live with ISPW. 

    What about the implementation team?

    Vendor supplied Professional Service installation team.  

    Excellent support team. 

    What's my experience with pricing, setup cost, and licensing?

    The price point is great.

    Which other solutions did I evaluate?

    The other solutions that we looked at were much more expensive and not nearly as flexible.

    What other advice do I have?

    I would advise two things. First, you must have a technical group of people who understand what you're doing now, where your programs are, how you change them, how you test them, how you promote them. You need to be able to clearly communicate all of that so that the ISPW team can create the steps in ISPW to do the same.

    Second, I would encourage any company to look at the whole process early on and develop realistic timelines for the whole project. Even the night you go live is a long process. This is not a 45-minute process and you're up and running. It takes time to build all the metadata that ISPW will use for tracking. 

    You also need to think ahead about training. The training is a three-day class and you need all of your developers to sit through these classes. That's a logistics nightmare if you have five different sites and 200 people in different countries. You need to think about how you are going to train people, what you are going to show them, and about when you are going to do it. Are you going to do it with a test system or something else? If you don't look at all of that early on, you can be racing towards the installation deadline and realize, "Oh, I have to get 150 people in a room and get them trained. How am I going to do that?"  

    Look at the whole process, start to finish. Plan for the "Go-live"  date, and how you are going to communicate where you are in the process to everyone that needs to know. Your team needs to have a really good understanding of all of those steps and then start to execute. We stumbled a little bit with our first installation but the last 2 were much more organized based on understanding how all of the key events had to happen and how to communicate to the development teams. 

     ISPW is an excellent product. It does everything the developers need it to do. We were able to build it and customize it, very simply, as we became more familiar with how the system works during installation. It doesn't need a lot of care and feeding once it's up and running. Our development teams think it is a great product as well. Installation-wise, I think more detail on the installation decisions you make up front would be very beneficial. But as a product, it's a solid nine out of 10.

    Which deployment model are you using for this solution?

    On-premises
    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Flag as inappropriate
    Mainframe Architect at a financial services firm with 5,001-10,000 employees
    Real User
    Does our CICS NEWCOPYs and Db2 binds, reducing operations and DBA workloads
    Pros and Cons
    • "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 of the operations folks and off 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... ISPW is constantly aware of it. It notifies when someone else is using or has a different version of that component."
    • "One thing I would really like to see some improvement on is the promotion diagnostic messages. It invokes utilities "under the covers" to copy components, and it does not echo back any of the error messages from those utilities."
    • "There are some features that are not well documented, so documentation could use a little help, on things like setting up deployment and which structures in the database correspond to which tables."

    What is our primary use case?

    We use it for change management and source control.

    How has it helped my organization?

    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. 

    What is most valuable?

    It's pretty much a purpose-built application for source control and change management. That's what we use it for.

    What needs improvement?

    One thing I would really like to see some improvement on is the promotion diagnostic messages. It invokes utilities "under the covers" to copy components, and it does not echo back any of the error messages from those utilities. So if we have an issue where, say, an old load module is missing an alias, it invokes IEBCOPY under the covers, and IEBCOPY returns a bad condition code. But there is nowhere that those messages are reported back to us. That's just a specific issue. 

    In general, the logging and the message analysis, the output analysis, could be made easier to use.

    There are some features that are not well documented, so documentation could use a little help, on things like setting up deployment and which structures in the database correspond to which tables. The admin configuration of it are kind of arcane. It would be nice if the doc were brushed up and maybe there were some step-by-step guides on doing things. There are some out there, but there are some things, like propagation, that are simply not documented and we don't even know how to set it up.

    For how long have I used the solution?

    Less than one year.

    What do I think about the stability of the solution?

    It's very stable.

    What do I think about the scalability of the solution?

    It seems to be very scalable. There is considerably more scalability and functionality than we had with ChangeMan.

    How are customer service and technical support?

    We haven't had to call support for this solution more than once. We do have lots of experience with Compuware. They're great. Compuware has good support.

    Which solution did I use previously and why did I switch?

    We used Serena/Micro Focus ChangeMan for this functionality and we switched for cost and functionality reasons. There is a lot more functionality with ISPW and there is clearly a lot more effort in the continued development of ISPW. ChangeMan was somewhat languishing. They didn't really update it much.

    How was the initial setup?

    The setup was pretty complex. Compuware came in and did it as part of the purchase, and then they did some training.

    A lot of it was conversion from ChangeMan. That was something that we could not have done, just to state it simply. We don't often come across a product that we can't convert to and implement. We've done a large number of them. This one, in particular, after seeing what they had to do - we couldn't have done it.

    It was a rushed deployment because we had a licensing misunderstanding with Serena/Micro Focus. We pretty much had to convert in a month. There were actually a couple weeks where we went without a change-control product, and we were doing manual compiles. It took a month to convert it and implement it, and then we were making changes and still implementing, to be honest. That propagation issue is one of them; the planned binds is another. There are still a couple things that are not implemented. But it's net new functionality that we never had before.

    Because it was so rushed, our implementation strategy was "cross our fingers and hope for the best." We actually had a longer-duration plan, but when we found out from our purchasing department that our licensing was about to expire, we had to rush things. We're not a good example to use for the right implementation approach, because it was so hurried.

    What about the implementation team?

    We used Compuware's ISPW conversion team. It was a company Compuware purchased and that is what they specialized in: change control product conversions. It was Compuware's unit up in Canada, and they were great to work with. They are experts in the subject material and easy to work with. Nice people.

    What's my experience with pricing, setup cost, and licensing?

    I like the seat-based licensing much more than MSU-based licensing, and that the cost has been competitive.

    Which other solutions did I evaluate?

    We had plans to implement Endevor but in evaluating Compuware ISPW vs CA Endevor, there was never any traction from the change group. The people who admin-ed ChangeMan before we inherited it were not very technically savvy. We just didn't have any good resources. And to bring Serena in to help us upgrade ChangeMan or to bring CA in to convert ChangeMan to Endevor was very cost-prohibitive.

    What other advice do I have?

    Take a longer implementation path than we did. Don't rush it. We were forced to rush it and we would incur a large cost from Serena. My advice is to plan longer and take more time to implement, which we had planned on doing. We were going to do a phased implementation. We just didn't have that luxury.

    To anyone who is considering moving from an alternative solution to this one, I would say, "Don't hesitate." I've told everyone I've talked to that this is a much better product. They'll be much happier with it.

    There was a lot of resistance early on but, the more people have used it, the more positive they have become. I think they have really started to like the product. We have about 50 users and all of them are in application development.

    For deployment and maintenance, it was just me and one of my staff. We maintain the skeletons and CLISTs and troubleshoot if we have a promote/deploy failure. They do happen but probably less frequently than with ChangeMan.

    It's used every day. It's constantly being used by the application developers. We don't have any explicit plans to increase its use, other than as we add developers. We do plan to make use of Topaz. We've been struggling with coming up with a training date but once that occurs, we hope that people that would use Topaz.

    We don't have it integrated with anything. There's been some talk of looking into that but I can't say which direction it will go.

    I would rate this solution a nine out of ten. The two things I mentioned earlier, the ways it could be improved, would make it a ten. If we could get a little better documentation and a little better error reporting from the promote/deploy processes, that would sure make my life easier.

    Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
    Buyer's Guide
    Download our free Software Configuration Management Report and find out what your peers are saying about BMC, Broadcom, Micro Focus, and more!