Automation in application lifecycle management (ALM) can be critical to boosting productivity, improving quality and keeping projects on track, but IT decision makers need to make their choices wisely so the tools are not more of a hindrance than a help. Also, decision makers need to bear in mind key trends in the ALM space. According to market research firm Ovum, in its Decision Matrix: Selecting an Application Lifecycle Management Vendor, regulatory compliance and Agile continue to be drivers, but adding to that are the move to extend ALM to operations, automating application security and utilizing SaaS and cloud as an application delivery model.
“You cannot do complex software development without the right tools,” said Michael Azoff, a principal analyst at Ovum, “but choosing the right tools is crucial. If you choose the wrong tool it completely ruins productivity and can constrain you. You have to do good due diligence to select tools that will allow you the freedom to do what you want to do.”
The idea behind automation “is to remove the bottleneck from the process” in order to optimize the efficiency of deployment, said Mik Kersten, CEO of Tasktop Technologies, creators of the Eclipse Mylyn open source tools and provider of Agile ALM integration and productivity solutions. On the lifecycle management side, he said, organizations need to focus on a continuous application lifecycle. “If you’re not getting feedback, you might not be shipping the software. You need to be getting agility into the whole software cycle. Lean ALM requires automation.”
According to Jim Johnson, chairman of the Standish Group, an IT consultancy focused on project and value performance, ALM automation is paying off on some levels, but on other levels it can be a negative ROI.
So what should decision makers know about automation and their ALM tool sets?
Balance effort with benefit
Make sure the tools don’t take more work to put in place than the benefits they provide, Johnson advised. “Sometimes people end up doing things they wouldn’t have to do [without the tool]. You have to be really careful about what tools will give you benefit; if you don’t think about it that way, you end up working for the tools instead of the tools working for you.”
He continued, “Today 80% of the [IT budgeted] money is spent on overhead and 20% on productivity; it used to be the reverse. Every time you layer on a process, you increase the overhead. Watch out that you are getting greater productivity vs. just governance and covering your ass. You may not have project failure, but you may have doubled your cost and lost innovation.”
Make sure you can play outside the sandbox
Sometimes an ALM tool suite controls so much it stifles innovation, Johnson said. “If you’re doing something over and over, you want to automate it; if it’s creative you don’t. You have to balance things. People like to put these things in sandboxes, but only so many people can play in the sandbox, and there are only so many toys that fit in a sandbox. What if you want to play outside the sandbox, and what about people who could help you who are outside of the sandbox? So you have to be careful.”
Beware of silos
Within an ALM vendor tool suite, “you benefit from automation,” said Tasktop’s Kersten. “But if there are other things in the stack, then CIOs are very aware that the same automation and velocity they’re getting from one silo may be missing from [another silo like] the business analyst’s tools, etc. It doesn’t matter how efficient the development team is if they’re shipping the wrong thing.”
Know where the weak links are
There is more automation across the lifecycle, but there are still gaps, according to Dave West, a Principal Analyst at Forrester Research. The weakest area is requirements, he said. “People are poor at that kind of process.” Deployment is another area, he added. “It’s a gap if someone has to provision a machine.”
Extending ALM to DevOps is still a struggle
Jean Louis Vignaud, ALM Segment Lead, IBM Rational, said there are still gaps in extending ALM to DevOps. “You can speed the development process, but if deployment is not fully integrated to the development process it will lead to defects and errors. So expanding the development cycle to deployment is where the industry still has some gaps.
Think train yard vs. train
“There’s definitely a move within DevOps for automating the ability to deploy into production, but automation starts sooner than that,” said Carolyn Pampino, program director, Strategic Offerings for IT Software Delivery, IBM Rational. “The analogy for DevOps is you can focus on making one train move faster, which is typically what automation is about, or you can focus on how to coordinate all of those trains. From a DevOps perspective, you need that direction.”
Think about security earlier
Many organizations wait until the final stage [of application development] to run security scans, said Pampino. “I would urge driving that early in the lifecycle, and planning security remediation up front,” she said. “You can drive security scanning into the build and test process. So by the time you get to the final gate you’ve already dealt with many or most of the issues, by automating and driving it back to the integration builds.”
Finally, summed up Johnson, don’t expect ALM tools to solve people issues. “Oftentimes people are adopting tools instead of solving real problems like user involvement, executive support, etc. They’re relying on tools to solve the problems they haven’t been able to in the organization.”
Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.
This was first published in March 2012