a stop-gap measure until a real CM system could be put in place. The goal was primarily to capture information from the developers in such a way that a nightly build could be successfully accomplished - lots of glue, lots of short cuts, but it bought the time necessary to put a valid CM tool in place. A good version control system is just that. The problem comes when one tries to use a version control system as a Configuration Management tool. It doesn't fit the bill. It helps in the identification process. Because the version control system allows you to identify revisions of an object, it facilitates identification of a baseline as a collection of (generally compatible) object revisions. But not all Version Control functionality is applicable to CM because VC is applied to individual object. Configuration Management deals with the entire product picture. So although a VC tool might attempt some change control, you quickly find that change control is not naturally done on a file revision basis. Rather it is better done on a change basis. Similarly, baselines deal with a collection of revisions. Many are frightened by the complexity of the CM problem. Try to build a CM tool that works and you'll see what I mean. I've designed compilers, database systems and numerous other middleware and tools. None comes close to the complexity of a CM tool. Compilers have very straightforward specifications, and database users basically all have the same set of expectations, give or take a bit. You can't really say the same about CM tools. Just look at a few - ClearCase, MKS, CM+, Accurev - and you'll see widely different perspectives on the problem. But maybe we can propose some specifications and expectations. An ideal CM system will:
- automate all of the CM tasks except the high level directives
- allow me to manage Changes rather than file revisions
- let me easily specify a context for my queries and for my work
- be easy to use with little training
- perform reliably and responsively
- let my distributed team work as if it were all under one roof
- provide the traceability and reporting necessary to make timely product decisions
- support the processes and data that my organization decides is required
- make each of my team member's tasks easier rather than more difficult
- be easy to roll-out, with neither high risk nor high costs
OK - it's a partial list, but maybe it's not a bad start. But there are some mighty challanging expectations there. The key to a successful CM solution is to complete this list and then find a solution that will deliver. Twenty years ago the only way to deliver was to hire a large consulting firm that each team member could turn to whenever a task had to be performed. Even then, timeliness left much to be desired, not to mention cost. Today's CM solutions have evolved considerably. Most second generation CM solutions can deliver on a handful of these expectations. Third generation tools will do even better. In the end, what you want to be left with is customization tasks to fill in the gaps. But not customization of the tool. Rather customization of your processes and user interface to match your organizational requirements. The leading edge of the CM industry is rapidly approaching this capability.
Taking Short Cuts Doesn't Work - Simplicity Does
So what do you look for, specifically, in the technology of a particular solution. First of all the solution must hold the view that Configuration Management requires a broader data perspective of a product, or even a






