Configuration Management Processes

There are two basic processes in performing configuration management: Configuration Identification and Configuration Control / Change Management.

Configuration Identification

Configuration Identification involves identifying the configuration of items such as hardware, software, and documentation within a system as well as their physical, functional, and performance characteristics. Configuration Identification also involves the identification of items that do not necessarily have physical, functional, and performance characteristics such as project schedules, budgets, and plans. The following are some examples of these configurations:

  • Requirements

  • Architecture, software, and hardware designs

  • System, subsystem, and product interfaces

  • Test plans

  • Test procedures

  • Code

  • Hardware infrastructure

  • Schedules

  • Budgets

Configuration Items

A Configuration Item (CI) is the identified configuration of an item, or a portion of its parts, that is designated for CM and change control. CIs are important program or project items that are subject to change during their life. One would not identify temporary items as configuration items.

Identifying Configuration Items

CI identification involves the analysis of the identified items to determine their importance to the project and its products, and an analysis to determining if the items are subject to change during development and operations.

The identification of CIs includes:

  • Assigning unique identifiers to each CI

  • Technical documentation describing each item’s configuration

  • Establishing naming conventions for CIs

  • Establishing and maintaining associations between CIs and their descriptive information

  • Describing the product structure through the selection of CIs and identification of their internal and external relationships

Configuration Control / Change Management

Configuration control / change management is the systematic evaluation, coordination, approval or disapproval, and implementation of changes to CIs. Change control is the sub-process of making changes in a planned fashion, where the objective is to correct defects, add capability, and more effectively implement new and improved methods and systems on a project or in an enterprise. The CR is the typical means to initiate a change; some changes may originate as a Problem Report (PR) or an Engineering Change Proposal (ECP).

Establish Baselines

A baseline is the approved and fixed (immutable) configuration of a collection of one or more CIs at a specific time in the collection’s life cycle that serves as a reference point for change control. For example, a Git commit can be used as a baseline since it represents an immutable collection of files at a specific point in time. Not every commit is used as a baseline, however, because not every commit is suitable for release.

The baseline is a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. A change to a baseline requires a CR, which ensures that an appropriate entity addresses implications to cost, schedule, and technical baselines for the project. A specific version of a single CI by itself or a set of functionally related CIs can be established as a baseline.

A baseline is established at the proper time—namely, when the CI is mature, stable, and has been reviewed and agreed upon by all stakeholders. As CIs change during product development, a series of baselines is established to enable assessment of the evolving product’s maturity at different points in time. This task includes identifying:

  • Events that establish a baseline

  • Items to be controlled in the baseline

  • Procedures used to establish and change the baseline

  • Authority required to approve changes to the approved baselined items

During each iteration / phase of a development project, newly developed items and new versions of pre-existing items may be identified as CIs. At the close of each iteration or phase, approved CIs may be baselined for the project.

Configuration Control Boards

CCBs manage and control changes to the controlled items. CCBs review, approve, disapprove, defer, escalate, or remand CRs for CIs. CMS formally charters its CCBs with specific thresholds for their change approval authority. Security-related changes can only be approved by an ECCB (or higher authority). CM ensures that all updates, deletions, and additions to baselined CIs are performed only as an outcome of the change control process.

CCB membership consists of management and stakeholders, and is supported by subject matter experts (SME). A CCB may exist at the enterprise and/or project level, with an approved charter and operating procedures. A cross-section of disciplines need representation on a CCB.

When a CR impacts multiple baselines that may be the responsibility of other CMS CCBs, it is necessary to coordinate the assessment and approval processes among the affected CCBs.

Change Requests and Continuous Changes

Concepts related to continuous changes such as DevOps move towards the ideal state of continuous standard changes. That is, the ideal state is a continuous flow of small, discrete, low impact changes.

Any request to change baselined CIs must be documented in a Change Request form, continuous standard changes. There are at least two classes of changes:

At a minimum, the CR should contain the following fields:

  • CR requester

  • CI to be changed

  • Class of change (e.g., normal, emergency)

  • Description and reason of proposed change, including rationale, and purpose

  • Affected baseline

  • Analysis of impact on the project and other entities

  • Historical resolution

  • Approval or disapproval

  • State of the change (e.g., open, approved / rejected, implemented, and tested)

  • Date closed

Impact Assessment

All stakeholders need to assess impacts against requested CRs. The assessments should include at least the following items:

  • Physical, functional, and performance characteristics of CIs

  • System, subsystem, and product interfaces

  • Security issues

  • Cost (may be against a cost threshold)

  • Schedule (Master Schedule or equivalent)

  • Shared data by systems

  • Environmental Impacts

Security CRs

In addition to project or program CRs described above, security-impacting CRs have additional requirements—in particular for the conduct of security impact assessments—imposed by HHS and the federal government as follows:

  • Security Impact Assessment (as required by HHS Policy for System Security and Privacy Handbook requirement, P-CM.8)

  • Security Impact Analysis (as required by NIST SP 800-53, Recommended Security Controls for Federal Information Systems and Organizations and the CMS ARS)

  • FAR Subparts 39.1, 42.3, and 52.248-3 (available from https://www.acquisition.gov)

Updated Baselines

The CCB establishes an initial baseline for a CI once it is deemed mature and the stakeholders have approved it. Any update of the baseline requires submission of a CR, completion of an impact assessment, CCB approval of the requested change, and implementation of the change. The process for updating a baseline may take days, weeks, or even months depending on the complexity and degree of anticipated impact.