Several commenters on my blog post, Team Foundation Server is the Lotus Notes of version control tools, expressed the opinion that ALM (Application Lifecycle Management) is nothing more than a marketing buzzword used to sell bloated, expensive software that just gets in the way and piles on process without giving any real benefits.
I personally have mixed feelings about this.
The concept of Application Lifecycle Management is a good one. ALM is basically an aggregation of sound software engineering practices to manage change, releases and health monitoring of your application in a repeatable, disciplined fashion, and to be able to diagnose problems with a minimum of fuss. For example:
- Do you know exactly which version of your code is in production?
- Can you identify which change introduced a bug?
- Do you know what errors your production system is throwing?
These are the sort of things you should be doing anyway.
Where ALM becomes problematic is in the implementation of these practices offered by many vendors. Many of these tools impose rigid processes based on strictly prescribed ways of doing things, a low level of trust in the developers using them, and assumptions and technologies that are simply out of date. They may cope (albeit awkwardly) with 80% of your requirements, but when faced with the other 20% — in particular, innovation, experimentation and prototyping, and the need to respond rapidly to changing requirements or unforeseen circumstances — you’ll hit a brick wall.
There is an extent to which ALM has become a marketing buzzword touted by vendors of poor software, and in fact, the ALM solutions with the best reputation tend not to use the term at all. But the principles on which it is based are good ones, and we do ourselves a disservice if we dismiss the concept outright along with substandard or overbearing attempts to implement it.