Posted by Tom Grant on April 18, 2011
We've been talking about the next stage of application life-cycle management (ALM) for several years now. As my colleague Dave West argued, the vision of ALM 2.0 is clear, compelling, and comprehensible. While ALM tools might have a ways to go to fulfill this vision, they have made significant strides in one particular area: integration among tools, whether or not they come from the same vendor. The momentum for ALM integration isn't unique, propelled by the same forces that make integration the killer app in other segments of the software market (CRM, content management, collaboration, etc. etc.). Tools provide potentially valuable capabilities, but these capabilities don't map exactly to the way people work.
The Work Defines The Tool, Not The Other Way Around
The primacy of work over tools explains why ALM 1.0 died quickly from its own success. Having convinced app dev teams of the value of point solutions for task management, planning testing, requirements, release management, and other functions, the obvious question on practically every customer's mind was, "What other tools might help us?" We should be careful about how we understand that question, which is not synonymous with, "What other activities might we make easier or more successful?" The tools are, more often than not, part of the same activity. Planning, for example, should identify risks that shape what requirements you write and what tests you build.
As an analyst, I hear this demand for ALM integration practically every day. When I have inquiry discussions with clients about ALM, the discussion inevitably moves beyond the boundaries of any one tool. For example, I recently had a telephone conversation that started with a question about user stories. The bigger question was the road map for Agile teams, which in spite of techniques such as epics and themes, may not be as clear to people outside of the team as it is for the team members themselves.
While the primary topic wasn't tools, some mention of tools options was inevitable. Could a Wiki help communicate the road map effectively? What would be the value of a more automated or regimented way of moving from the user story to the functional test? Was constant feedback really possible without tools that made communication with business users a bigger part of the development process?
Teams, Not The Vendor, Drive Adoption
At this point, tools vendors might be salivating over the opportunity to create the perfect suite of tools, capable of improving every aspect of a given activity, such as road map definition and communication. They shouldn't, or at least they shouldn't salivate too much. There's always some value to getting multiple tools from the same vendor, but the market favors a different approach than gradually locking teams into a single-vendor ALM strategy. Once again, the explanation lies in the primacy of the work process — in this case, how teams adopt ALM tools.
Here's another emblematic conversation about ALM during a recent inquiry. A Forrester client asked me, "We've tried two task management tools from ALM vendors that focus on Agile. Honestly, they look very much alike. Which do you recommend?" My paraphrased response: "The tools you already have, or think you will have, for other activities related to task management will make the relative value of these tools clear."
Every team approaches tools adoption differently. They start with unique combinations of tools they already have and like, tools they already have and don't like, and tools they haven't tried yet. These tools are variously custom-built or packaged, and the off-the-shelf options are customized to greater or lesser degrees. And, of course, some of the "packaged" solutions may be open source, and others commercial. Therefore, the ALM tools vendor has no way of anticipating the customer's starting point. At this early point in the discussion, pushing their own ALM suite is tantamount to saying, "We're not interested in your work processes or your existing tools investments. So let's talk about us."
Some potential hubs exist, but even if they captured 100% of the market, they'd never be able to set the rules for how and when people adopt them along with other ALM tools. HP Quality Center, for example, appears frequently in the list of "things we already have and we're planning around." However, HP is not pushing as hard as it might for customers to adopt all of its ALM tools. In fact, HP supports the Mylyn integration framework, even though its primary purpose is connecting a tool from Vendor A (HP) with a different tool from Vendor B (not HP). HP is hardly alone, since there are Mylyn integrations with practically every other major ALM tool. And, of course, integration via Mylyn or another mechanism can make or break smaller companies looking for a foothold in the market.
ALM Customer Want To Know Who, What, Where, Why, And How
What's the secret behind Mylyn's success? Managing tasks is common to practically every work process on which you might slap the label "ALM." If task management describes how people work, IDEs define where they work, which is what makes Eclipse integration commonplace. Perhaps one reason why Open Services for Lifecycle Collaboration (OSLC) hasn't made more headway is because, unlike Mylyn or Eclipse, it doesn't connect as directly to the what, where, why, and how of work in app dev teams.
Integration is so important for ALM that it's possible to imagine a company making integration its primary value proposition and its own applications less so. That scenario, were it ever to happen, would be good news for app dev teams. The ALM market, at that point, will have moved far away from the tools enforcing how teams should work, to supporting how teams do work.