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?
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.