Reducing the Cost of Configuration Management

By Mac Noland

mac.noland@thomson.com

September, 2002

 

 

Abstract:

 

The purpose of this document is to identify ways to reduce the cost of configuration management for your project.

 

 

Introduction:

 

From the eyes of a configuration management engineer, software projects are broken into logical abstractions called configuration items (CI).  A CI is an application or group of applications that have the same build and release schedule.  If anything changes in the CI, the entire CI is built and deployed.

 

Each CI has a configuration management cost associated with it.  For the purpose of this discussion the cost is broken down into two parts; 1) a configuration item (CI) resource; 2) a personal (P) resource.  The total configuration management cost (TC) of a project is “CI + P = (TC).”

 

 

Configuration Management Costs of a Project:

 

            As stated in the introduction the total cost of configuration management (TC) is configuration item resources (CI) plus personal resources (P).  CI resources include source control management, build management, and deployment management.  For example a build machine will be needed and is included in the CI resource.  Notably, the most important part of CI is the resource needed for managing CI source code.  This includes such things as branching, labeling, and any other associated source control related overhead.

 

            P is configuration management engineer personal resource for a project.  For example time spent on writing build and deployment software is included in P.  Also time and resources for managing documentation, schedules, environment versions, and the actual running of builds and deployments are included in P.

 

“CI + P = TC.”  CI can grow in size (i.e. CI^2) with little effect on TC, where when P grows the TC grows at relatively the same rate.  So for example let’s say the amount of source code (included in CI) doubles in size (CI^2).  Because this is a CI resource, the increased need is transparent to the TC.  Managing double the amount of CI source code is of little difference to managing half the source code.  On the other hand if P grows, the TC will grow along with P.  Adding more personal resources (P) to a project is a cost that cannot be transparent to the TC.

Note “CI^2 ≠≠ 2CI.  This means doubling the resource need of CI is not equal to separating CI into 2CI.  Why one might ask?  Reason being, each CI resource needs a corresponding P resource.  For example a need for 2CI would be “CI + P = TC” and “CI + P = TC” which equals the total cost of managing two configuration items (2TC).  Where as a need for CI^2 would be “CI^2 + P = TC,” which is the total cost of managing one configuration item.  Remember CI is directly proportional to TC.

 

 

How to reduced Configuration Management Costs of a Project:

 

            As one might guess 2CI is more expensive than CI.  The goal is to reduce the number of CIs which is directly proportional to the number of TCs.  In a perfect world each business unit might look at having one CI.  This means all code would be built and deployed per one schedule.

 

            For example a business unit with 20 CIs has a configuration management cost of “20(CI + P) = 20TC.”  Where a business unit with one CI would have a configuration management cost of “CI + P = TC.”  You’ll notice in the latter example there is only one P, which is the most expensive part of configuration management.

 

            While having one CI might not be possible or desirable, the purpose of this paper is to show the advantages of having fewer CIs and ultimately reducing the cost for configuration management.