What should large enterprises keep in mind when selecting ALM tools?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Tools, tools, tools! When it comes to wading into the ALM tool store, I suggest first and foremost that any enterprise spend a little time reflecting on their ALM process and what they want to accomplish in 2011 and beyond. From there, you’ll find three primary drivers that any enterprise IT shop needs to keep in mind regarding ALM tooling. Consider these:
- Bottlenecks -- Development teams need to recognize where bottlenecks form in their ALM process and determine how to best fix these specific points of congestion. Then go see if there is a tool or set of tools to help.
- Cost -- Remember, the cost of the tool is just the tip of the iceberg. In addition to how much a given tool costs, you also need to consider how much it is going to cost to implement -- integration between tools and existing systems, training, and so on. Costs don’t occur in a vacuum, especially in ALM.
- Change -- Enterprises need to keep in mind that, on average, maintenance is responsible for 60% of the cost of software, including both error correction and enhancements. Understanding this is key to having an effective enterprise-level ALM strategy and supporting tools.
It is worth noting that the above drivers are really geared towards organizations where software is not their core business, but rather a component of RUNNING the business -- what I like to call Enterprise IT shops. Software vendors and consulting firms likely already have these problems under control. For Enterprise IT shops where IT isn’t the central business, the ALM challenge is compounded due to people.
The people challenge is not a talent problem but rather one of resourcing. In my experience, most Enterprise IT shops are faced with “flowing” teams. What I mean is that the team who delivers a working piece of application functionality tends to not be the same team providing maintenance over time. Thus, “flowing” teams put an extra level of stress on your ALM process and supporting tools.
So, when selecting your next wave of ALM tooling, don’t forget the full application lifecycle, including the different team members who participate in the process and especially the “long tail” of maintenance.
This was first published in January 2011