Seamless Integrated Tops Wishlist for CM/ALM Tool Suites


In his CM: the Next Generation, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

There are a lot of CM/ALM solutions out there - so where are we headed? In my opinion, the future of CM/ALM will be defined by the level of tool suite integration, more than by any other factor in the 3rd and 4th Generations of tools. And basic "integration" will not cut it. Putting tools together into a single package with some glue and triggers to help the tools interact is helpful, but will fall short of market demand. "seamless integration" will be a requirement. No advance is more important to the next generation of CM tools. What about cost? What about ease-of-use? How about traceability? The answer is simple: first seamless integration, and the rest will follow. If you haven't seen a seamlessly integrated tool suite, you may not fully grasp this statement. But seamlessly integrated tools are the ones that will be dominant in the future. Let's look at why.

Seamless Integration

What is seamless integration? Let's start out by considering solutions that integrate tools from various vendors, or even various tools from the same vendor. Some do a nice job. But the honeymoon ends after the initial shipment. These tools are glued together and it's not easy to change the glue. If you want to expose a new feature from one tool to another, it's a lot of hard work. If you want to upgrade one of the tools, you're probably better off waiting until someone else has done it first, or until a new integrated suite version is released. It's not only risky, but also difficult. Not only are the tools dependent on one another but, to a large extent, they're dependent on the specific release features that have been integrated. Change a feature and you can break the integration.

So then, what is seamless integration? With seamless integration, the user sees one tool. The database is a single database shared by all applications. There's one, consistent user interface across all applications in the suite. Changes to one application are visible to all the other applications. Releases are done by tool suite, not by tool. And the glue that otherwise is used to hold the pieces together, is replaced by a process and data engine, with rich query, change and data navigation.

Typically in a seamlessly integrated suite of tools, both the set of applications and the set of functions available to each application are customized to the user's roles. Data navigation is not restricted to a single application, but flows as necessary between applications. On the infrastructure side, there's one consistent set of capabilities, whether it be backups, multiple site operation, workflow capabilities or reporting.

I've seen dozens of CM requirements documentation requiring integration of the CM tool with a particular problem-tracking tool or requirements management tool. As a vendor it's important that we can put a checkmark beside that requirement. However, almost continuously over the past 25 years, I've had the privilege of using CM/ALM tools with seamlessly integrated applications, even back before the GUI came into being. I would not consider using or recommending tools with traditional loose integration, as it's like stepping backwards in time. With traditional integration, the focus stays on supporting processes (rather than advancing them) such as getting the tools to talk sufficiently to each other to support the process and then to maintain that level of interaction over time.


One of the most fundamental capabilities of a seamlessly integrated CM tool is an unprecedented level of traceability. This assumes, of course, that the process and data schema support such requirements. When they do, though, the expressiveness of the query capabilities are generally sufficient to allow, not only reporting of traceability information, but point-and-click navigation of the same. Some tools do this better than others. I find it is essential to be able to take a build, and in a single click generate a prioritized set of testing activities which address each problem report or feature addressed by that build. Equally important are the following types of tasks:

  • Generating a list of problems fixed, features addressed by a build
  • Identifying which test cases have been run against a build and which have succeeded
  • Identify which requirements are missing test cases
  • Easily translating from a line of code to a change, and the associated change request or requirement which produced it
  • Rolling up gantt charts and producing risk reports based on the actual time sheets against each WBS activity
  • Generating a quarterly report for each customer on the state of that customer's change requests, both problems and features


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.