What is our primary use case?
One use case was for development life cycle management for a pool of developers using it in an Oracle and .NET development environment.
How has it helped my organization?
One of the benefits is the integration with different platforms. Having the defect management, and being able to relate defects and testing to the initial user requirements—having this complete life cycle—is one of the major advantages with Octane. It's the "life cycle" way of thinking that the solution provides. That is a very important component of Agile and DevOps. Octane integrates with your CI server for continuous integration and delivery. This "life cycle" approach gives us end-to-end visibility.
It also provides a single platform for all automated testing and that definitely helped facilitate the testing, the test scenarios, and collaboration between the test team and the development team. Having both together on a single platform allows us to ease the integration between the different teams. One of the major things we talk about regarding Agile, and one of the major components we talk about regarding DevOps, is this seamless integration between the teams.
In addition, it gives you a single, global ALM platform that supports all your Agile and Waterfall needs. One of the big challenges for DevOps is the adoption of a tool among the teams. The fact that the tool facilitates and supports this definitely helps the adoption.
ALM Octane also reduced testing costs overall. It's hard to say exactly how much, but I would estimate by 20 percent. It also definitely reduced integration costs by building a streamlined application delivery pipeline connecting to all IDE, CI, and SCCM tools. In this case the integration costs were reduced by 20 to 30 percent. Finally, it helped to produce releases faster, again by about 20 percent.
What is most valuable?
The valuable features start from the defect management in the life cycle and go into the part for versioning control.
The defect management gives us full-fledged capabilities for handling defects, including capturing the details of the defects and even screenshotting the defect cases. The defect management is comprehensive.
Also the integration capabilities with other development platforms we were using was helpful. The out-of-the box integrations are definitely a big part of making Octane comprehensive when it comes to DevOps quality management. It is full of features and gives us flexibility to provide the needed integrations with different platforms.
The solution natively supports Waterfall, Hybrid, and Agile software development at enterprise scale. That's very important because there is a big shift going on from the Waterfall environment into Agile in DevOps. Having a tool that can give us both practices was important.
In addition, Octane's Agile support is good at both the team and the portfolio levels. It has dedicated capabilities for Agile and is very flexible and comprehensive in these two areas.
What needs improvement?
Security and security management, meaning the integration of the security, could be enhanced. We know about Fortify, but it would be better to have security features in the original Octane platform without the need for another solution or another application.
For how long have I used the solution?
We've been implementing solutions with OpenText ALM Octane since 2016.
What do I think about the stability of the solution?
From the stability perspective it's okay.
What do I think about the scalability of the solution?
We did not stress-test it to see what it would be like in a mega environment. Usually we deployed it in a medium-sized environment, with 20 to 30 developers, and the scalability was okay.
How are customer service and support?
I would rate technical support for the solution at six out of 10. Usually there is a lack of connection among the teams for handing over support cases. You often need to do or redo some work whenever support cases are opened. If it is handed over to a new engineer, you need to start doing things over from the very beginning. You have to explain things again.
How was the initial setup?
The initial setup of Octane was straightforward. Because you are talking about development and software developers, it's not like a normal tool for business users. It was not complicated for people to get along with the tool and use it and integrate it.
Usually, deployment takes, on average, a maximum of two months. The deployment plan definitely depends on what the current technologies are, the integrations needed, and on what types of development environments and what types of IDEs are involved. It also depends on whether there are other systems and tools available already.
Just one person is required for deployment and maintenance of the solution. Rather than a developer, that person would be an administrator for the system.
What was our ROI?
The benefits I've mentioned can be reflected as monetary benefits, which I would estimate at 35 percent annually.
What's my experience with pricing, setup cost, and licensing?
Microsoft is a big challenge for OpenText when it comes to pricing because they are much cheaper. But it definitely depends on the complexity of the environment. If it has multiple technologies, at that point, looking at other options and Microsoft would be a feasible approach.
Which other solutions did I evaluate?
We work with Microsoft TFS. We also use JIRA, but I don't consider JIRA a competing component, rather we integrate it. One of the pros of TFS is definitely its integration and supportability if you are a Microsoft development environment, using .NET and the like. There's a lot of seamless integration there. Also, from a pricing perspective, usually Microsoft can provide you with very cheap packaging options. Those are the two main pros for Microsoft TFS.
What other advice do I have?
Dedicate someone for the administration. Often companies assign a developer to take care of it but this is not the proper approach. Someone needs to have responsibility for the administration. Also the process when using the solution should be a consultative approach. First look at your process and your development life cycle and then reflect it in the tool. Also, be clear about the integration points before starting the implementation so that the technical requirement and scope, etc., are clear.
Regarding reducing manual testing time, this didn't happen in the extreme because we were already automating most of the environments. There was a lot of automated testing. But it helped in facilitating the "life cycle" approach, especially if the environment already had Microsoft TFS. You integrate it and put it on top and you gain big benefits.
Which deployment model are you using for this solution?
On-premises
*Disclosure: My company has a business relationship with this vendor other than being a customer. Partner.
