CM: THE NEXT GENERATION of Seamlessly Integrated CM/ALM Suites

single underlying architecture.

Where does integration end?

It's nice to have your Configuration Management integrated with your Problem Reporting and your Change Management. Is more required? If Requirements Management and Test Suite Management are tied in as well, the solution is even more attractive. So what about Build and Release Management, Project Management, Customer Requests and CRM? What about Time Sheets? Peer Reviews? Pre-sales Support? Documentation? Org Charts?

When do we have too much integration? In my experience, I'd gladly welcome all of these in a single integrated suite. In fact, for the most part, that's how our own environment (at Neuma) works. A single integrated suite. It's true that few on the product team need that wide a view of the world. But when done properly, it sure makes life easier. These pieces are all tightly woven. Or more properly put, the processes are.

And that's the key - to look at the processes. It's important that management data is integrated from end to end. The output of one phase is the input to another and eventually closure is required by verifying outputs from later phases against requirements of earlier phases.

Horizontal vs. Vertical Integration

When we discuss tool integration, we need to talk about both vertical and horizontal integration. Horizontal integration has the same general types of users: Management or various classes of end users. An ALM tool integrates management tools. An IDE integrates implementation tools. An Operating System integrates (or supports integration of) run-time programs.

There is a very high level of data interchange within horizontal integrations. In an IDE, source code and resource editors work with compilers which work with linkers and debuggers. It allows a developer to rapidly move from one "application", such as editing, to another, such as debugging. Ideally, the user sees a single IDE tool. In an ALM tool, users move from requirements to test cases, from change packages to problem reports and features, from baselines to workspaces. A successful ALM tool integration will make the end-to-end integration behave like a single tool.

Vertical integration is much more difficult. There are not a few phases or applications to move between. There are a myriad of them. From countless CM/ALM tools to numerous IDEs. From source tree browsers to various editiors, difference tools and merge tools. It is complex. Whereas an IDE integration will concern itself with a specific tool suite (e.g. the Visual Studio family, or the JSEE environment), a vertical implementation must span all sorts of variations.

Vertical integration is best addressed through standard APIs that must be adhered to by all tools. An Editor should be able to take a filename and a line number or object identifier and go to it. A Merge Tool should take two or three filenames and a few standard options. The higher level tools can then invoke them appropriately. There are hundreds, if not thousands, of common editors. The API must provide the standardization so that these can plug into any CM environment to provide a simple "view" operation, for example. Such a collection of vertical integration APIs establish a Framework for vertical tool integration.

Standard APIs can, by their nature, be restrictive or complex. Take for example the "APIs" for integrating CM tools with Microsoft's Visual Studio or with Eclipse. The former is restrictive - for example it does not support the concept of Change Package (aka Update) based CM very well. The latter is complex - it's no simple matter to integrate a CM tool with Eclipse. Overall, I would expect a fairly basic API to interact with a CM tool, but