To get to our destination, the road that we drive is important. In order to drive on the road, the road must be built for our needs. In order to keep the road safe, signs with meaningful messages must be added along the way. This should parallel our approach to Configuration Management (CM).
The road in this CM example is the CM infrastructure: a combination of the CM environment (CM technology and systems) and the CM procedures. This car vehicle is the project which uses CM ‘road’ to deliver a release to its destination. The signs on the road are the organizational policies and direction given to guide us in the right direction and on the right road.
CM does occur at several levels within a workplace. CM is often though of as occurring at the project level, focusing on what tasks must occur to deliver a release package. This usually involves build, package, and deployment tasks and includes change control and issue tracking tasks. These CM tasks fit nicely in an engineering project plan and most occur in the development and release phases of the project. However, many CM tasks and activities may not fit so neatly into a project level plan.
As an example, often times CM infrastructure tasks (e.g., application level CM tasks) are intermingled with project level tasks in an engineering project. The CM infrastructure tasks may interfere with the ability to get the release out on a timely manner. In this case, what is recommended is to have a separate CM effort whose goal is to establish the deliverables known as a CM infrastructure that is independent from the engineering project whose goal is to create a set of deliverables known as a project release.
If the CM infrastructure tasks get completed in time for the engineering project to use them (a procedure, training, code repository), then they can be used. However, an engineering project should not have to wait for the CM infrastructure tasks (at the application level) to get completed in order to get the release out. It is advisable for the application owner to provide the CM professional(s) with lead time to build an appropriate CM infrastructure for the application lifecycle so that when project releases are ready to be developed, a functional set of CM procedures and technology are available to control that work.
Three CM Levels
In the book, Software Configuration Management Implementation Roadmap , Mario Moreira, defines a structure for the level where the CM tasks can be aligned. These levels include the Application Level, Project Level, and the Organization Level. At the Application level, the CM tasks build or improve a CM infrastructure. CM tasks at this level do not directly involve getting a project release out to market (e.g., to its destination), but involves CM tasks focused on building the infrastructure and processes that can support an engineering project lifecycle.
At the Project level, the CM tasks help a project create and deliver a release to the marketplace.
At the Organization level, the CM tasks define CM consistency across an workplace such as standard policy, budget, personnel structure, and terminology.
Defining the CM Levels
Many people within a workplace use the terminology of the CM levels interchangeably. For example, people constantly use the term “project” and “application” (or “product”) synonymously when, in fact, they are very different. Below are brief definitions of the levels, but it is important to define these terms for your workplace.
An Organization may be:
- An entire workplace if small with only 1 division head or area of focus.
- A division or