CM: THE NEXT GENERATION of Tool Integration and Toolkits

own CM tools into it's IDEs. Now I've got a good idea of what I might recommend for this API, and it's not that complex.  But it looks at a wider, ALM view of CM, whereas some want a more narrow view.

The problem with not taking the Microsoft approach is:  Where is the user interface?  Is it in the IDE or in the CM/ALM tool?  If you're using several different IDEs, you'd probably be happy with the latter. Or if you're a developer working in a single IDE, you might want to do all of your CM right from the IDE.

What about the version control component - is it a management component or a separate vertical plug-in.  The function of version control - saving and identifying versions of a file - is vertical in nature.  However, management data, including branching and history information is horizontal.  It is needed by the broader management functions.  Ideally, your version control component manages versions and identifies them by a single (numeric) identifier, which can be used to reference any version of the file. The management tool should then be responsible for storing history and branching information in terms of these identifiers.  If not, you'll find that simple operations are inefficient, or possibly
not fully catered to because of the need for a separate mechanism to query and manipulate such data.

When we have a clear vision of horizontal versus vertical integration, we start to see that it makes sense that horizontal tools should share the same repository data, the same process engine and perhaps the same user interface.  We don't have to decide between a monolithic system and individual tools.  There's a part way in-between solution.  Horizontal integration will blossom when it's tools are sharing a common platform. 

The CM Toolkit

So one approach is to focus first on the toolkit we'll use to build our ALM solution.  It must start with a common repository.  But that doesn't mean the documentation tools, compilers and code dependency tools need to share this repository.  I'm sure there's extra benefit if they do, but it's just not always practical.  The management suites are
dealing with process, reporting, persistent data, quality and traceability.  All of them need these components.  And to spend time gluing from one tool to another isn't going to get the job done.  Look at the tools that have integrated repositories: generally there's lower
complexity and a smaller learning curve.  In fact, many CM tools won't grow into ALM tools because their repositories are CM-specific.

But if you start with a toolkit that understands process, has a central repository, and even moves towards a common user interface, you have a much broader success.  No glue. No worrying about what happens when one tool is upgraded and it's affect on the integration - the glue, which once resolved is met with the new release of one of the other tools.  Both MKS and Neuma, two Canadian companies, are taking this approach.  And in each case the approach allows rapid expansion of the suite of CM tools into ALM suites, and beyond.

Integrated User Interface

So what about the approach to CM/ALM user interfaces.  Here, more than anywhere in the solution, the focus has to be on process.  The user interface is what the users use to execute the process.  If it's unnatural or if it's overly complex, your process has no hope.  It's critical that CM vendors build in the flexibility for their customers to easily tailor the CM solutions.   One process does not fit all.  And although there are some prepackaged processes and tools (e.g. Rational's UCM), if they don't quite fit your process, you're in a lot of trouble because they are not generally flexible.

Ideally your CM tool interface is the same across ALM functions.  If you have to pop
in and out of different tools for Problem Tracking, Change