The merits of application lifecycle management are rarely in dispute, but the adoption of ALM suites is still not in the mainstream.
First of all, ALM is not just about tools but also the management and development processes and methodologies, and certainly for small-scale projects one can do without some of the tools.
On the other hand, for large and/or complex projects, the use of appropriate tools can make all the difference to achieve success.
There are signs that vendors are now changing tactics to win acceptance of ALM.
The problem for ALM suite vendors is that most customers have a mixed bag of ALM spot tools, often purchased on a best-of-breed basis, or inherited as a result of merger and acquisition activity.
For larger organisations there may be differing acquisition policies across departments, and for global organisations different geo-locations may have their local tools preferences.
Given this backdrop, a policy of 'rip and replace' is less likely to take place, especially as the investment in new tools can be quite significant if an attempt is made to harmonise tooling throughout the organisation.
The answer must be to make disparate tools work together, and build end-to-end solutions that deliver on the essential benefits of integrated ALM without imposing a single vendor necessity.
It does appear that vendors are realising this and are attempting to address the question. For example, Borland has embarked on creating an Open ALM platform and is using this to feed into its new Business Intelligence for ALM roadmap.
The Eclipse Application Lifecycle Framework project is also premised on this need to share a common platform. Open source ALM tools are in a good position here as the Application Programming Interface is transparent and hence easier to work with. Microsoft Team System is also a platform but requires vendor products to work with the product's common repository, and it is the question of data exchange that remains a stumbling block.
The need for integration is certainly appreciated because this makes it possible to deliver Application Intelligence; reporting on project metrics using the tools and techniques of BI, such as data warehousing, analytics, visualisation, trends, and correlations.
This requires gathering data from at least three key segments of the lifecycle from a project intelligence viewpoint: requirements management, software configuration management, and test management.
Looking at other areas of IT faced with the same data exchange issue, vendors have got together and standards have emerged. For example, Business Process Management has the XML Process Definition Language for migrating models to process executing engines. The ALM vendors need to get together and work out a similar data exchange standard for application intelligence. This will raise the profile of ALM in absolute terms and thereby benefit all the parties involved, including, let us not forget, the customers.