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?
What do I think about the stability of the solution?
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 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.
As Product Owner for ISPW I welcome your insight. Feedback from users helps form our direction as we put out new releases each quarter. We are also constantly improving the documentation based on user experience. I suggest that you always download the latest version, even if you did it as recently as a month ago.