Customer Control & Best-of-Breed ALM
Choosing ALM Solutions
While the promise of ALM is very appealing to most organizations, the implementation time and adoption rate is generally longer than expected. There are several factors contributing to this including:
- The difficulty in making cross-functional organizational changes to processes
- The autonomy that each team requires in order to maximize their efficiency
- Development lifecycles make it difficult to change tools mid-stream
For example, when an organization chooses to implement a single-vendor ALM suite, it is often decided by a selection committee with interested representatives from each team (e.g., developers, testers, management, etc.). These representatives evaluate multiple products in their domain, each from different vendors or open source solutions, (e.g., the QA team will evaluate the automated test products and the release engineers evaluate the build tools). In most cases, these evaluations determine that the best choice in tools differs from each individual group and often come from different vendors. Because each tool is often only used by one or two groups, it is often not necessary for the entire suite of tools to be evaluated by any single individual or group (e.g., the architects rarely use the build and test tools, and the testers rarely use the project management tools).
In order for the ALM selection committee to ultimately decide which specific tools to purchase, a discussion generally occurs where the trade-offs are discussed. Common conclusions by the committee include:
- If we go with vendor A, we'll have the best tool for group X, compromise on the tools for groups Y and Z, but everything will be integrated out of the box.
- If we go with vendor B, we'll get the best initial license price, a single vendor for support and training, and "good enough" tools for all groups but risk a slow adoption rate or non-use by team members.
- If we go with a multivendor approach, we'll get the best tools for each group and stage deployment as needed, but we may not have full integration out-of-the-box.
Often, the final decision on an ALM solution is deferred because there is no optimal solution in sight. By going with option I and II, it is common that the groups with the "good enough" tools will either sacrifice their productivity or not fully adopt the chosen solution. By choosing option III, it is common that integration is not realized because of lack of commitment by the selected tool vendors, particularly when the vendor is focused on selling the remaining tools in their ALM suite and not on open integrations.
"Organizations that want to be competitive in the future are paying attention to ALM," said David Kelly, president of Newton, Mass.-based Upside Research (1/06)
A Difficult Choice: Productivity vs. Integration
While both single-vendor and multivendor solutions can provide the full advantage of an integrated ALM suite, as noted above, gaining full adoption of these tools by the engineering organization is often an obstacle.When the decisions are made by individual teams, generally a best-of-breed tool approach is selected in order to maximize productivity for the given team (e.g., developers choose the IDE that best meets their specific requirements). This choice may also be focused on implementing better technology and innovative solutions. There is often a low priority given to the ability of the tool to integrate with tools used by other teams in the engineering organization.
When senior management makes the decisions regarding tool choices, often a single vendor ALM suite is selected. This choice is generally based on providing out-of-the-box integration across the organization and a lower potential initial acquisition cost. Often productivity of each team, and the ability to integrate with future solutions from other vendors are not a key selection criteria.
As the chart below shows, both single-vendor and best-of-breed ALM offer the ability to improve team productivity, with a management view of the entire development process. Additionally, full artifact traceability (e.g., requirements, issues, etc.), and reporting measurements are available in both types of ALM solutions.
The Optimal ALM Solution
The optimal solution for most organizations is an ALM solution that appeals to both the individual teams' need for maximum productivity, and the management requirement for out-of-the-box tool integrations across the engineering organization.At the core of the ALM solution are the SCM and issue tracking tools, as they serve as both the data repository and the focus on the overall process. Each of the other software development tools will communicate with the SCM and/or issue tracking, but it is generally not required to have the other tools integrated directly (e.g., the project management tool does not communicate with the build tool directly).
AccuRev SCM software, at the core of a best-of-breed ALM solution, provides the foundation for an optimal ALM solution. AccuRev supports open standards and SOA-based development tool interoperability across Microsoft Windows, Linux, and UNIX platforms. AccuRev is tightly integrated out-of-the-box with all the leading issue tracking tools and IDEs, and provides an SDK and custom development for integration with other solutions.
|
AccuRev Solutions |
| Overview |
| Business Process |
| Release Engineering |
| Project Management |
| Software Development |
| Best-of-Breed ALM |
Read the Case Study: More Information - direct links to resources and how to contact AccuRev |
