Serena ChangeMan ZMF alternatives and competitors

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. 

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

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.

Less than one year.

It's very stable.

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

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.

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.

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.

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.

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

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.

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.