The analysts and tools vendors have been talking about Application Lifecycle Management (ALM) for many years now and I think they have (of course) been somewhat self serving in their definitions. ALM seems to  include whatever product category they have in the current price list and then promising their integrations' would be managements answer to cost and governance issues. I hope to say more about integrations in the future, but I'd like to look at the scope of ALM for now. If you ask vendors and consultants (including me) about ALM scope you'll get answers such:
  • Requirements engineering
  • Software Configuration management
  • Dependency Tracking
  • Change control and work tracking
  • Test management
  • Software development tools and process
  • Software building and processes
  • Deployment
  • Process Governance
Depending on the vendor you might even get more traditional: Project and Program Management;  Project and Application Portfolio Management/Analysis; and Service Management activities thrown in as well. The usual sales pitch is that everything is managed via a common tooling and provides a common repository. The major, and often single, selling point of this approach is improved governance and business oversight of the SDLC. However I think it's useful and important to look at the definition of ALM from a customers perspective rather than as analysts or vendors. It seems that a more pragmatic approach is to describe ALM as the methods, processes and tools that support the management of change for software systems -- with particular, but not exclusive, emphasise on the SDLC. In this context it does not matter if we are using Agile or Waterfall approaches, we chose the best tools and processes for our particular situation. This of course implies that in eighteen months time we may need to re-tool. Furthermore the methods tools and processes of project management (PM) are much more mature and there is no real need to include them in this evolving segment -- they have their own. Obviously PM will have an influence and impact on ALM and we need to design our ALM approach to dovetail with it. I realise that most vendors will not agree with this. I have come to the conclusion in order to 'sell' ALM into the teams that will use it we need to ensure, front and centre, that ALM provides a 'better/faster/more' improvement in daily productivity. That should be the primary focus of what is delivered. Governance, audit etc should be secondary attributes and natural site affects of using ALM (important though they are of course and usually the primary sales message). So at a practical level we need to be able to provide teams and their specialists with the best tools they need to do their job. Additionally we need to provide a supporting layer of data flows, events and data repositories to
  1. Assist teams with traceability
  2. Provide the tracking and management visibility to effectively steer the ship
So the point of this post is to plead with vendors to stop selling a one size fits all tool suite with deep integrations and start enabling shallow API and effective integrations to allow a truly best of breed approach for customers software purchases. It's a shame that ALF project is shuting down.