During AADI we held a roundtable on ALM Practices and had a fairly quick conversation on this topic.  The nut of the conversation is that no-one in IT uses the term ALM.  Either SDLC (software development life-cycle) or more specific terms: requirements management, project management, defect management, etc. are used.  There is a slowly emerging convergence of APM and PPM tools with ALM and a convergence between ALM and Release Management in DevOps that at some point may deliver a real “ALM” suite or solution set  but the reality at this point is we probably should modify our terminology to say ADLM.  I would love to get your input either here or tweet me @metamurph

Jim and I are also taking the time together to work on completing the Magic Quadrant for ALM.  This has been a challenging process over the last 6 months given the ever growing size of the market and the evolving nature of ALM.  One of the key things we have noted is that in general most tools aiming at enterprise use have gained strong integration facilities recognizing that they won’t be the single stack provider.  There are single provider solutions and a few vendors still oriented toward these solutions but in general most organizations won’t have all ALM tasks managed in one single tool.  We have noted this in two notes recently: Selection Criteria for Success in Choosing ALM Products and Application Life Cycle Management Matters Where Diversity Persists.  In the near term, it would appear that Cloud delivery of solutions will only better enable users to choose governance tools that fit the various roles in an organization and this is a good thing.

Software testing continues to be hard, costly, and embattled to explain why it is both of these.  It is hard to measure the ROI of testing.  However, we will next turn our attention to the ALM market which plays a key element into Quality because “Quality can’t be tested in” some of the players in that document will match this but just as their is growth in quality and testing tools, the ALM market is exploding and our biggest challenge will be focusing in on a reasonable subset of these products.  It is great that options are expanding, this means better pricing, improving functionality, and support for a wider variety of technologies.  It also means that a decision isn’t as simple as picking from a grid.  So if you read the research and have questions about how to apply it to your needs, give me a call.

Generally this market has been driven by the need for: easy to get started and use, low capital expenditure, collaborative, connected as in connects to all my existing tools, and analytic.  We have captured this in many research notes and by no means see anything of a letup but an acceleration in the market.  This acceleration is driven by the need for better project transparency and the drive to improve productivity and better make use of globally dispersed teams (which may include internal and external resources). 

Rally’s acquisition of AgileZen fits into this pattern by broadening the ways that projects can be managed and measured in a tool that fits well to the current Rally platform.  We expect to see continued growth in the number of acquisitions and vendors broadening from Agile == Scrum to adapt support for a broader set of Agile techniques. 

We are also seeing that the traditional scope of suites (test and defect management, functional automation, manual testing, load/stress testing) is seen as only a portion of the requirements.  Increasingly there is a need for better data management to mask and subset test data, a desire to better integrate with requirements (the promise of ALM), and a need for a more complete view of the state of the project from a consolidated quality perspective instead of one tool for unit tests, one for static analysis, one for functional testing etc. each with its own reporting a consolidated view.  Planning tools are also evolving with more pressure to work with Agile development processes and better support for risk-based testing.

At the same time testing tools themselves are continuing to evolve with a greater number of model-based testing offerings coming to market.  These seem to be able to deliver improved test maintenance and higher productivity.  In addition with major updates continue to move forward from package vendors there is a greater need for tools that simplify the regression testing of these packages. 

So what are your thoughts about testing tools?  What is important?  Do you want a single vendor?  If not what level of integration do you desire?  Are you willing to switch tools to take advantage of breakthrough innovation?  Do you feel like your testing tools are providing the return on investment you need or are you seeking lower cost options?  I look forward to grilling the vendors and their reference customers so we can answer these questions and more. To see the current version of the MQ you can go here.