Configuration management, what is it?

When talking about configuration management, are we talking about the same things? Or are we just using the same words, the same terminology, the same vocabulary with a completely different picture in mind?
When I talk about configuration management, I usually mean configuration management for the development project of a product. CM for deployment of products and services is a completely different profession. But even within a development project, there is the same distinction between development and deployment. I will explain.
During the development project, there is a (software) development environment consisting of various applications that are needed to develop the software. In this development environment, new applications and services come available, for example a new compiler (or a new version), operating system upgrades and patches or modelling tools. The development environment is managed by an IT department, but even within a development project special scripts and tools are maintained to tailor the development environment for project specific optimization. That is called configuration management.
But the development environment does not develop a product; people do. And while people develop the product they make new artefacts, derived from other artefacts. For example, a design is derived from requirements and design constraints, code is derived from design and requirements, etcetera. And since this is performed in some sort of stepwise process (waterfall, spiral, iterative, incremental, agile, you name it) many artefacts are produced in different versions. These versions need to be managed, which is also called configuration management.

So we have already 3 types of configuration management:

• Configuration management of the deployment environment
• Configuration management of the development environment
• Configuration management of the project's products

Management or environment?
Now, when you are talking to the SCM-er of a project, who are you talking too? Is he responsible for assuring the the SCM system's availability and performance is within acceptable limits? Is he responsible for resolving database inconsistencies, like stale versions and branches, hyperlinks pointing the wrong way, data that is not replicated correctly to remote sites? In that case, he an SCM environment kind of guy.
Is he responsible for authorizing promotion of changes based on promotion or delivery criteria, deciding in which workspace which changes need to be made based on the development plan, who has access to which parts of the system, which versions need to be used for integration and testing, reporting the "status" of the product during its development? In that case, he is a configuration management kind of guy.

Unfortunately, we have seldom make a distinction between the name of these roles. And unfortunately, many of the issues that these people are dealing with are similar. But confusing these roles makes it difficult to communicate effectively.
For example, a project leader needs to start a new project to develop a product variant of a product that is still under development. He instructs his CM-er to create a development branch.

If the CM-er is an environment oriented person, he will probably create a branch using his knowledge about the CM tool from the LATEST version of the product development. Whenever a developer needs a change from one branch to another, he can merge using the CM tool mechanisms, possibly with the help of the CM-er. Introducing inconsistencies, quality risks and other degradation phenomena is not the concern of the CM-er.
However, if the CM-er is an management oriented person, he will probably worry about how to control the isolation and integration of changes happening in parallel. What if product development makes a change we need, or vice versa? How about merging dependent changes we did not ask for? Which tests must be performed before accepting a change we get from another branch? How about changes that we deliver to another branch? How do we know the exact content (requirements, bugfixes, etc.) of our configuration?

The environment oriented CM-er is often an expert with the CM tools, while the management oriented CM-er is often more an assistent project manager. Many non-CM persons do not see the difference, and do not understand that when having one person or the other makes a great difference in the responsibilities that the project manager and the developer carry.

Perceptions, presumptions and practice.
In my experience, a project manager (or project leader or team leader, whatever name you give) is often assumed to take responsibility for the configuration management issues while he lacks the appropriate knowledge and skills to do it. Project managers usually are skilled in negotiations, managing people, setting up plans and delegating work according to plans, but not with managing configurations on a day-to-day basis. Developers usually assume they have no configuration management responsibility, except for checking out and in files (and making appropriate changes to them) and delivering changes from to other people (and getting changes from other people). The CM system is considered more a burden than a blessing. Satisfying promotion criteria and following predefined change flows is bureaucratic overhead, "only" delaying the change flows, delaying developers and delaying the project. In other words, the CM system performance is really bad, not to speak the build performance.

The CM-er is squeezed in the middle. On one side he is made responsible for assuring that the environment is available and working properly with high performance, and support people using the environment to maximize their productivity. He builds in all kind of automated mechanisms to assure data integrity (or database integrity) and to rule out human mistakes. On the other side, he is made responsible for guarding the consistency and integrity of the data in the CM system without having the authority to hold or delay changes that violate the rules. Many times I have heard that development is delayed because the configurations are not managed properly, while the CM-er spends a lot of overtime (evenings, weekends) to recover the integrity of the configurations he did not mess up in the first place.

Is there a solution?
As for every problem, there is probably no one-best solution. A solution often chosen is by using a "simpler" CM tool. They are cheap (in money terms), have a good performance, have an intuitive and easy to use interface, are integrated with the rest of the development environment, etc. But this "solution" is typically an environment approach, made from an accounting perspective (money talk) or a convenience perspective (lazyness). But it hardly ever solves the management problems that configuration management suffers.
Even worse, changing the environment typically introduces so much additional environmental disurbances and issues (installation, tuning, customizing/tailoring, integration, training), that management is completely focussed on resolving them rather than the configuration management issues that hamper the development productivity in the first place.

In my opinion, the best approach is to keep the development environment as stable as possible allowing people to build up (high performance) routines of co-operation, and having a close look at the total development process flows. This involves data flows (e.g. change flows, document flows, code flows, notifications, reporting) and control flows (e.g. planning, scheduling, assignments, decisions, control boards, RACI definitions, progress tracking, exception handling), but it also involves policies and politics (e.g. authorities, responsibilities, "kingdom building", ownership, discipline and mentality, culture).