Configuration Management Planning: What To Do Before you Start

dependencies, product/component dependencies, etc.  Data records need to have a concept of versions.  A file has several
branches, each branch has several revisions.  The same goes for documents, requirements, and perhaps other objects.  With an RDBMS, the tendency is to push the revision data out of the database and into the file versioning tool's meta-data.  All of a sudden, a simple database operation to identify open revisions turns into a complex, inefficient task of searching through the versioning tool's set of files.

When the database does not match the real world, you need a process to map the real world objects onto RDBMS data, and you need another process to map the data back to the real world.  This requires effort, resulting in short cuts that shouldn't be taken.  It also requires expertise, meaning it's not easy to customize your tools and its not easy to get answers to your real world questions. 

Hopefully they're all pre-canned in your solution so that you don't have to frequently turn to your expert. Another effect of the real-world to database mismatch is one of performance.  You can't go to a requirement and ask for the sub-requirements. Instead you have to go to all requirements and see if the requirement is a parent of each requirement.  The performance is orders of magnitude worse.  But, data indexing comes to the rescue.  So now you have to (automatically) maintain index files which need modification whenever the data is modified.  You need to specify which fields need to be indexed, making customization tasks more complex.  You have background processes constantly performing indexing.

Then there's handling of "note" fields, such as problem descriptions, running logs, and of file management.  RDBMS solutions don't do a good job here.  You need to augment them.  However, when you do, you lose many of the capabilities that you started with because the augmented tools don't share the same architecture as the RDBMS.

Don't be afraid of non-RDBMS repositories, provided they have the necessary  functionality and a host of advantages.  Just make sure they are as good or better in areas of reporting, reliability, scalability, data integrity, and performance.

Be Prepared
So what we've covered is not how to do CM planning, but rather how to prepare  for your CM planning exercise.  Do some research and then set your objectives high.  Understand the tools and the processes out there.  Bring in help if you need it, but make sure the objectives are clear. And pass your results onto the rest of the CM community - your successes and your problems - as you go.  There's a lot of expertise available for free at CM Crossroads.