ALM – What is it and Why Do I Care?

For those not familiar with ALM, it can be simplified down to “A comprehensive view of all of the ideas, requirements, activities and artifacts that impact an application over the course of its lifecycle, from concept until decommissioning”. Obviously, this encompasses a large number of different areas even for relatively small and medium-sized projects. In recent years, many teams have adapted methodologies which address individual aspects of this; but the majority of this adoption has resulted in “islands of improvement” rather than the desired comprehensive outcome…Until now!

Last year Microsoft released Team Foundation Server 2010 along with Visual Studio 2010 Ultimate Edition, and with these two in combination the situation has drastically changed. At last there is a single environment that is capable of handling all aspects of ALM, and is also capable of dealing with migration and integration with existing systems to make the transition to a single solution much easier.

The possibilities (and practicalities) are nothing short of amazing, Architecture thru Testing integration? YES. Being able to correlate specific requirement items (and their history) to actual code (and code history)? YES. Identification of which tests will be potentially impacted by a given code change? YES. Resiliant Automated Testing of User Interfaces? YES. Automatic Deployment Management? YES. Integraton Level testing as part of (designated) Builds? YES.

I could easily double or triple the above list, but these items should be enough to get you thinking about the “pain points” your team and organization currently face and the fact that there IS a way to relieve the pain.

When teams are first introduced to these capabilities, there are a couple of common reactions.  Many can be grouped under the heading of “That’s Great! What do I have to do in order to experience this goodness?”), but a fair number fall into one or more of the following groups:

  • We don’t need any of that. We are doing just fine editing our code, compiling it locally, testing it locally, and doing manual deployment.
  • We already accomplish that (or at least the important parts) using a suite of [often OpenSource/Free] tools.
  • That will make our jobs more difficult / take longer, and decrease efficiency.

If you are a member of the first two groups you are likely to be comfortable with the status quo and do not see the need for change. I recommend either a simple pilot project or a co-development effort (using both the existing methodology and an ALM approach in parallel) to identify and quantify specific areas for improvement. Trial versions of all of the tools are readily available, so this can be done without any capital expenditure.

If you are a member of the last group, it is likely that you have had a negative experience with adopting a formal comphrehensive process in the past. Unfortunately this is common, and my best suggestion is to keep an open mind, learn as much as possible about the capabilities, and (if possible) get an opportunity to work with a person or team who has successfully adopted ALM

Advertisements

About David V. Corbin

President / Chief Architect Dynamic Concepts Development Corp. Microsoft MVP 2008-2011 (current Specialized in ALM) Microsoft ALM Ranger 2009-2011
This entry was posted in Application Lifecycle Management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s