CM: THE NEXT GENERATION of Tool Integration and Toolkits

There have been many "backplane" recommendations over the years for plugging in tools into a common framework.  How successful are these and what success can be expected in the future?  There has not been a lot of success here.  Eclipse is an open source effort to push forward, and with some success.  Like other companies, Neuma has embraced the effort with it's own Eclipse plug-in, but with an order of magnitude more effort than at first anticipated.  In my opinion, this complexity will make it difficult for this solution to succeed in the long term as a full solution.  No doubt it has and will have more specific partial solution successes.

The work of tool integration is not easy.  Some say it should not be approached with over ambitious expectations.  However, if you find you have to limit your approach, you're losing
before you get going.  Instead, a process-centric understanding of the goal is necessary.

To start with, every company, every organization, wants to do CM/ALM/Development differently.  Looking first at the technical side of things, in the '70s, diversity was in computer platform.  In the '80s that moved to programming language.  As user interfaces cropped up in the '90s, a new level of diversity emerged, with GUI toolkits and languages popping up to support these.  From a management side of things, there were a number of factors which caused diversity:  small and large projects, hardware and software projects, embedded and end-user projects, business and engineering projects, and so forth.

Initial Success Stories

All this diversity is no good if you're trying to integrate tools into a common framework.  My first attempt at an "integrated" solution was in the 1970s.  Putting together "full-screen" editors, compilers/linkers, version control, change management and build management into a single tool that could support automation and give project control was a definite challenge.  The project was initially hundreds of developers, but that grew quickly to thousands.  It was an IBM mainframe based environment in a telecom setting.  "Network" didn't apply to the data side of telecom back then - in fact there was very little, if any, data
side of telecom.  But, surprisingly, things like Virtual Machines (VM) were an integral part of IBM's mainframe capability.  And so, even though each developer didn't even have his/her own keyboard and monitor (i.e. there were shared resources in the "computer" room), each did have his/her own virtual machine.  This first tool, named PLS, understood the source language enough to identify dependencies, and understood the target OS enough to automate builds.  It understood and worked with the full-screen editor so that it could effectively do version control.   And it was a very successful project, still in use to this day.  However, although it was ahead of its time, it still barely addressed things like integration with project activities/tasks and with the problem reporting system - which was just moving from a paper-based to a mainframe-based application.

Still it enjoyed success.  Here's a few factors that contributed.

• It was designed for a particular computer system.
• It had a small, fixed set of development tools that had to be integrated.
• There was a single data repository that held all of the CM data.
• We had full control over how the tools would work together.
• It was designed to support a single common configuration management process.

Before we explore further, let's look at the second CM tool I put together, this time in the 1980's at another telecom company.  It again was a single computer platform (initially at least, on VAXes, eventually expanding to SUN workstations as well).  There was a great deal of experience from the first go around.  It covered more than just CM, from system requirements to test suites, and supported a more diverse set of compilers and editors.  So it had a generic name: Software Management System (SMS). The concept