Application lifecycle management (ALM) seems to have an identity crisis, or, at the very least, appears to take
a cue from a "Scooby Doo" villain. Once a common definition begins to gain acceptance, the technology pulls off its mask and shows itself to be something completely different. Even if you've spent your lifetime in the application development space, it's still easy to be confused by such a nebulous and (sometimes) schizophrenic term.
What really drives the confusion around the term ALM is the constant state of flux around the various tools and components that attempt to help automate ALM practices. I believe the key here is to keep the ultimate goal of ALM in focus: to improve application development and maintenance projects, making these projects more predictable and transparent to benefit the development team and the business as a whole.
Agreeing on the end goal of ALM is an important step but only marginally helps us define the term. To keep digging for a solid definition, let's examine the tools and technologies that are often classified as "ALM." According to various industry analysts and software vendors, at any given time, the following classes of tools are categorized as ALM tools including:
- Requirements analysis & management tools
- Modeling and design tools
- Project management tools
- Configuration management tools
- Build management tools
- Software testing
- Release management tools
- Issue management tools
The above list provides a good hint into the complexity of really managing the application lifecycle, especially if you're trying to define ALM and implement some kind of solution for your business. For most, buying all of the tools above is simply not reasonable. For others, the problem lies in taking one or more tools from each category and trying to make them work together. So what technologies should you consider in helping define your ALM solution?
You need to be prepared for your ALM approach to evolve and understand what internal (not just technology) processes will be affected as your application landscape evolves faster than it has before.
It's not so much about picking specific products for your ALM implementation, but rather finding the right process and framework. To get started I recommend you begin defining the key process and organizational constraints across the entire application lifecycle in your company-- don't just focus on a specific stage of the cycle.
So now with the end goal of ALM in mind and your application lifecycle processes understood, you can take the next step and begin to look at the underlying tools and technology that should support it. But just what is it?
First, let's consider the current definition of ALM -- let's look at the description offered up by TechTarget:
"ALM is a set of disciplines that together govern the process of turning business ideas into software."
My take? This definition works fine as long as we are not short sighted on how broad the definition needs to be. We cannot forget the operational and measurement aspects of the application development process. Thus here is my tweak on the definition above and what I like to call ALM 2010: "ALM 2010 is the set of disciplines, processes and tools which impact application delivery, application operations and end user teams in the effort to successfully deliver and maintain application software."
So, with this definition I would like to highlight three key needs of ALM 2010 that should not be overlooked. In addition, for any modern enterprise, it's more than just implementing a static ALM process and set of supporting tools. You need to be prepared for your ALM approach to evolve and understand what internal (not just technology) processes will be affected as your application landscape evolves faster than it has before. With this in mind, I propose your ALM 2010 approach must encompass the following:
- Seamless cross team collaboration, which includes requirements, issues, code changes and continuous integration
- A 'build to change' philosophy
- Fully integrated testing and performance management capabilities
For ALM to live up to its hype in 2010 (and potentially beyond), each of these needs must be successfully addressed. So what does each entail?
Seamless cross team collaboration: I propose that you need to invest in the processes and supporting tools to make sure you are able to drive application delivery and maintenance using a diverse set of team members. The modern shop must coordinate distributed development resources in such a way that change impact is minimized and code management is simplified. You will need to easily collect feedback from quality assurance and end user team members spread across different locations, and the feedback must be collected as close to the conception point as possible and automated to eliminate ambiguity. Operational team members must have their processes addressed and be included in the ALM definition for you to be successful. Last but not least, each of these team members needs to have transparent access to information regarding application status to avoid confusion and breakdown of the processes.
"Build to change" philosophy: A 'build to change' philosophy requires you to adopt some form of agile development process. I recommend you do this for both new development and maintenance activities. By adopting an agile approach you will be forced to look into streamlining key aspects of your development tools and how to eliminating the risk associated with rapid change. This will more than likely impact everything from your IDE to your build and configuration management tools not to mention how you capture requirements and feedback.
Fully integrated testing and performance management capabilities: I call this out specifically as testing and performance management are often overlooked in many ALM situations. If you are going to adopt a 'build to change' philosophy as part of your ALM 2010 approach these items must be seamlessly integrated into your process and platform. If not, you will miss quality objectives by not having the time to adequately test and monitor for performance issues.
ALM 2010 is no longer just about bringing a business idea through to a software application-- it's so much more than that. ALM 2010 has to deal with more shareholders having input in the development process, the need to build and change rapidly and the tools to make this happen while reducing risk and increasing transparency.
Is my ALM 2010 definition off the mark? Perhaps-- but I propose you use it as a starting point to provide your specific ALM definition with the greatest flexibility. With this simple yet broad ALM 2010 definition, it can really wear whatever mask you would like. Need more collaboration? Add in the proper tools and policies to your solution. Want tighter process management? Make the appropriate tweaks. ALM wears many masks-- make sure your solution wears the right one for your organization.