Email this page to a friend   

Email to a friend

Configuration Identification

The process of:

  • Labeling software and hardware configuration items with unique identifiers
  • Identifying the documentation that describes a configuration item
  • Grouping related configuration items into baselines
  • Labeling revisions to configuration items and baselines.

The purpose of configuration identification is to maintain control of an evolving system by:

  • Uniquely identifying the system, revisions of the system and the component parts of each revision
  • Understanding the status of configuration items as they progress through the development process.

We achieve this by:

  • Breaking a system down into a number of known and manageable parts (configuration items)
  • Uniquely identifying each of these parts
  • Identifying the various revisions of a part as it evolves throughout its development life cycle
  • Keeping track of the aggregates of parts that make up a deliverable item of software
  • Establishing baselines to give visibility of the completeness of a system at critical points in its development lifecycle
  • Keeping detailed and accurate records of the above in a CONFIGURATION ITEM REGISTER.

An Example of Configuration Identification

The figure illustrates the configuration of a railway network environmental control system. The system has a central operation control centre and many railway stations linked by a wide area network. Each station has:

  • A local control processor (LCP) that allows operators to display and manipulate the air conditioning system and smoke extraction fans
  • A remote terminal unit (RTU) that performs the control function and
  • An integrated backup panel (IBP) that allows operators to take manual control of the system.

The figure illustrates the configuration identification record for one of the stations (Central).

Identifying the Configuration

Why Configuration Identification is Important

Here are several real-life scenarios where failure to properly identify a configuration has caused financial loss.

Scenario 1 - Which Software is this?

An installation engineer located in Hong Kong experiences regular control system crashes. The Brisbane based development shop can't reproduce the problem in its test environment. After a week of investigation (cost = $5,000) a development engineer discovers site engineers have installed the wrong release of a configuration file in a remote terminal unit.

Solution: The central supervisory computer software is upgraded to automatically check the configurations of all remote units against an automated configuration item register.

Scenario 2 - Back to the Past

A new software release works fine for two weeks then catastrophically fails when a new feature is used for the first time. We have to revert to the previous release to recover (real quick).


Solution: Keep a Configuration Item Register that describes the evolution of the software product. Note that this function is usually performed by a source code control system, however a manual record may have to be kept of the documents that describe various versions of hardware and software configuration items.

Scenario 3 - If You Can't Build it they Will NOT Come

A software house goes bankrupt because it cannot reliably build its core product. See sidebar How Embarrassing Is This.

Solution: In your next job, as your first priority, set up a configuration register and pay more attention to configuration identification.

Scenario 4 - The Apocalyptic Test of an Effective Configuration Identification Strategy

Thirty years after your system is deployed the Martians come to earth with ray guns locked and loaded (get ready, it's not a matter of IF but WHEN). They blast your system into subatomic particles leaving you with nothing but the system documentation locked away in a vault at the North Pole. Could you recreate an exact facsimile of your system from these frozen specifications and design descriptions? Is all your documentation up-to-date? What versions of what documents describe the operational baseline - the one lolling around your feet in very small pieces? Not to put too fine a point on it but:



Member Comments


21 member ratings

✭ ✭ ✭ ✭ ✩

RE Definition: Configuration Identification


By anonymous » Wed 08-Mar-2017, 07:37, My rating: ✭ ✭ ✭ ✭ ✭

Definition was both funny and informative.

30 Comments  • Page 30 of 30 •        Previous « 1…  26   27   28   29   30 

- Rate this definition.
- Did it help?
- Suggest improvements.
- Request more information.
- Exchange ideas with our member community.

How Embarrassing Is This

by Les Chambers

The Board of Directors of a small software company has bunkered down in the board room discussing serious issues. They're reflecting on changes in their marketplace and fine tuning the company's strategic plan. Meanwhile down in the development shop there is only one man who knows how to build the company's software product: Ben the Build Manager. Ben is the only one who knows which versions of which software modules make up the latest release of the product; the company's one and only source of income. There is no documented build instruction. It's in Ben's head, which from a management perspective is not a real problem - but for the fact that Ben is unhappy with his salary package and conditions and is looking for another job. The company's sole means of production is about to walk out the door.

Email to a friend