Last year, colleague Mary Gerush and I wrote overviews of the requirements tools market, noting how it was segmenting to address different problems. (Click here and here for the two studies.) Application lifecycle management (ALM) tools may be undergoing the same evolution, forcing us to accept either a much larger definition of ALM, or several specializations within ALM.

In the requirements market, new tools, or new emphases among tools, were a sure sign that some kind of change was afoot. Several years ago, visualization tools were not only absent from the list of requirements tool capabilities, they were almost completely unknown. Now, any list of requirements capabilities that omits visualization would be incomplete. Several years ago, requirements management was the emphasis of these tools. Now, much of the interesting innovation is happening in requirements collection.

Dev ops isn't part of ALM, but the frequency with which it comes up in discussions of ALM makes one wonder whether it should be. While I'm not 100% convinced yet that it should be an official part of the ALM category, it's certainly closely tied to it. Just as visualization addressed a specific problem, or use case, within the requirements space, dev ops tools fit a common scenario for ALM. The people who build and test code have a vested interest in what happens when it gets thrown over the wall to the ops team. Not only could that hand-off be more efficient, but the real lifecycle arguably continues after the hand-off. Certainly that's how it looks from the perspective of customers, who care only about the application they touch, and auditors, who care as much about compliance issues during deployment as they do about what happens during development.

That's why market developments like Smartbear's acquisition of AlertSite, a small web and mobile performance management company, makes sense. Many of their customers are struggling with issues that extend through development and deployment. Whether or not you want to include the AlertSite tools in the ALM category, the use case certainly exists. Other ALM vendors, such as ThoughtWorks, have seen opportunities addressing the same or similar challenges.

There are always arguments to expand a category, and there are equally strong reasons to resist efforts to inflate definitions to the point where they are no longer meaningful. For example, you could easily take the word "quality" and go absolutely bugnuts with it, slapping the label of "quality management" onto anything that has even the smallest bearing on quality. In the requirements space, there are good arguments for including idea management tools, since that's where you'll find the genesis of requirements, and listening platforms, since the landscape of social media contains a lot of customer insights that are directly relevant for requirements. But would you probably wouldn't include CRM in the requirements space, even though it lies at the beginning of the requirements process, when you're assessing customer requests, and at the end, when you notify them of the fulfillment of those requests.

In exactly the same fashion, it's important for us to apply some skepticism to proposed additions to the ALM category. Dev ops might be essential for many use cases, but it's not as ubiquitous a concern as planning releases or fixing defects. There's no real hurry to re-define the ALM category, since the desire for integrated toolsets from a single vendor isn't as great in ALM as it is in other categories. ALM implementations are pretty motley affairs, including packaged applications from different vendors, open source alternatives, and homebrew tools. While there are strong incentives for ALM vendors to provide more than just a single type of tool, the incentives for buyers to have a committed, monogamous relationship isn't nearly as strong.

That's why integration is an important meta-requirement of the ALM market, not just integration within a vendors toolset, but between the vendor's tools and other options (including, in many cases, other vendors' tools, such as HP Quality Center). The ALM 2.0 vision is, at its heart, all about integration. ALM specializations, such as tools designed to support Agile specifically, will continue to develop, and integrations among tools should keep pace with these developments. 

For the time being, we need to be identifying the different use cases or business problems) that ALM tools address, so that we can identify how the subspecies of ALM may evolve. From that perspective, we'll be better able to expand or re-shape the boundaries of ALM, if necessary.