Configuration Management and Baselines
1. Overview
A. Definition
A management activity that maintains integrity and consistency by identifying, controlling, recording, and auditing changes to the work products (configuration items) produced in the course of software development and operation, controlling changes against an officially agreed Baseline.
Configuration management is often mistaken for "just using a version-control tool," but its essence is a management discipline that organizationally controls change. Tools are merely the means to automate it; the substance of configuration management lies in the procedures and accountability structure of "what we treat as the objects of management, by whose approval and how we change them, and how we leave a record of that change history." That major process models such as CMMI, ISO/IEC 12207, and PMBOK treat configuration management as a core supporting process is precisely because it is a foundational activity running through every stage of development, quality, and maintenance.
B. Background and Necessity
Software has countless work products — code, design documents, requirements specifications, manuals, test cases, and so on — that constantly change through many people's hands. If everyone modifies them without control, version confusion arises in which no one knows "which version is the real one," and one person's change overwrites another's work, collapsing quality. This phenomenon worsens exponentially as scale grows, leading to an "integration hell" in which "code that used to build suddenly breaks" right before a release.
Configuration management solves this problem by "allowing changes only through a controlled procedure, rather than prohibiting them." Change itself is an intrinsic property of software, so it cannot and must not be blocked. Instead, it disciplines changes so that they occur by whose judgment, through what impact analysis, and with what history. Through this it ① tracks the change history (audit/traceability), ② prevents conflicts from many developers working simultaneously, ③ makes it possible to restore the state at a specific point in time (e.g., last month's released version) at any moment, and ④ makes it possible to accurately reproduce which combination of sources, documents, and libraries is actually deployed in operation (reproducibility).
C. Characteristics
The core characteristics of configuration management are the three of baseline-centered control, securing traceability, and conferring accountability. Because a fixed point called a baseline is set and only changes after it are controlled, the management burden does not grow without limit; by leaving the linkage of requirements → design → code → test, one can trace back "why this code exists, because of which requirement"; and by leaving an approver and reason for each change, accountability is made clear when a problem occurs.
2. The Configuration Management Process (Overall Structure)
Configuration management consists of a cycle of "deciding what to manage (identification) → controlling changes (control) → recording the status (status accounting) → verifying consistency with the baseline (audit)." These four activities are not one-time steps but a repeating cycle throughout the entire project life cycle, and audit results are reflected back into identification to update the management targets and the baseline.
flowchart LR
A[Configuration Identification] --> B[Configuration Control]
B --> C[Configuration Status Accounting]
C --> D[Configuration Audit]
D -. feedback .-> A
subgraph Baseline
BL["Baseline Fix/Update"]
end
B --> BL
BL --> C
As the figure shows, only a change that has passed the configuration control activity is promoted to a new baseline, its status is recorded, and periodic audits verify whether the baseline matches the actual requirements. When an audit finds a discrepancy, it is fed back to the identification stage and the management-target list or naming rules themselves are supplemented. Because of this cyclical nature, configuration management is less "a task you set up once and finish" and more an engine that keeps running as long as the project is alive.
3. The Four Activities of Configuration Management
Each activity answers a different question of configuration management. Identification addresses "what," control addresses "how to change it," status accounting addresses "what state it is in now," and audit addresses "whether it was done properly."
| Activity | Core Question | Description |
|---|---|---|
| Configuration Identification | What do we manage | Identify, name, and version configuration items (code, documents, libraries) |
| Configuration Control | How do we change it | CR → impact analysis → CCB approval → reflection |
| Configuration Status Accounting | What state is it in now | Record and report change history and current status |
| Configuration Audit | Was it done properly | Functional (FCA) and physical (PCA) audits of whether the baseline matches requirements |
A. Configuration Identification
Configuration identification is the activity of "deciding on the objects to manage and attaching name tags." Treating every work product as a configuration item explodes the management cost, so those items highly likely to change and with a large impact on other work products (requirements specifications, architecture design, core sources, interface specifications, etc.) are selected and designated as configuration items.
The practical core of identification is the naming rules and versioning scheme. For example, using Semantic Versioning (MAJOR.MINOR.PATCH), the number 2.3.1 alone tells you immediately "whether it is a large change breaking backward compatibility (MAJOR), a feature addition (MINOR), or a bug fix (PATCH)." In this way, identification is not simple numbering but the erecting of the coordinate system on which the entire subsequent control and tracking process will stand.
If identification is poor, the whole of the subsequent activities is shaken. An item omitted from the management targets is changed secretly with no one controlling it (shadow change), and if naming is inconsistent, the same file is called by several names and its history splits. Therefore, finalizing the configuration-item list and naming rules early in the project is the first gateway to the success or failure of configuration management.
B. Configuration Control
Configuration control is the substantive core of configuration management. When a change request (CR) comes in, it is not reflected immediately but only after impact analysis followed by approval from the CCB (Configuration Control Board). Because of this gateway, indiscriminate changes are filtered out and accountability for changes is left behind.
Impact analysis is especially important. One change may look small on the surface, yet it ripples in a chain to other modules, documents, and tests that reference that item. For example, changing a single function signature in a shared library affects dozens of modules that call it. Impact analysis grasps in advance "what must be touched together when reflecting this change," preventing the collapse of consistency caused by a partial change.
The CCB is a decision-making body that comprehensively judges the cost, risk, and benefit of a change. For cases requiring speed, such as an urgent security patch, a simplified approval path (emergency CR) may be set up, but the principle is "do not change the baseline without the approval of a responsible party." Only when this principle is upheld can the question "why did this code change this way?" always be answered.
C. Configuration Status Accounting
Status accounting is the activity of recording and reporting "what version each configuration item is at now, what changes are in progress, and what has been approved or rejected." It tracks the status of the entire process from receipt-review-approval-reflection-verification of a change request, so that managers and developers can see the current snapshot of the configuration at any time.
The outputs of this activity are configuration status reports, change-history ledgers, per-version release notes, and the like. In practice, an issue-tracking system (such as Jira) and version control (Git) are linked so that which change request a commit is connected to is recorded automatically. Only when status accounting is accurate is auditing possible, and when a problem occurs, "when, and after which change, the problem arose" can be traced back.
D. Configuration Audit
An audit is an activity that verifies "whether what was built matches what was promised," and comes in two kinds. A functional audit (FCA, Functional Configuration Audit) confirms whether the work product functions as per the requirements and specification, and a physical audit (PCA, Physical Configuration Audit) confirms whether the composition of the work product (documents, code, media) is fully in place as per the list.
Audits are performed just before a baseline is fixed or at the point of final delivery, giving a final check on whether the changes controlled up to that point actually maintained integrity. When an audit finds a discrepancy, corrective action is taken and its result is fed back into the identification and control activities. In other words, the audit serves as the quality gate of the configuration-management cycle.
For example, when a bug-fix request comes in during operation, the developer does not patch it arbitrarily but registers a CR, analyzes the impact this change will have on other modules, reflects it after obtaining CCB approval, records the history, and gives a final confirmation of consistency through an audit before release.
4. Types of Baselines
Baseline: A configuration that has been officially reviewed, agreed upon, and fixed at a specific point in time, serving as the reference version that must go through the control procedure (CCB) for any subsequent change.
The reason baselines are set at each major point in the development life cycle is to "freeze" the work products up to that point as a stable reference, so that subsequent work is not shaken. Without a baseline, all work products are always in flux, so one cannot know as of which point in time and against what one should verify and control. A baseline draws a boundary line — "up to here is fixed, changes after this are subject to control" — making the management scope finite.
As development progresses, things become concrete in the order requirements → design → product, so baselines are also set in three types to match those stages.
| Baseline | Point of Setting | Fixed Content |
|---|---|---|
| Functional Baseline | Completion of requirements analysis | System Requirements Specification (SRS) |
| Allocated Baseline | Completion of design | Design specification allocating requirements to components |
| Product Baseline | Completion of development and testing | Final delivered-product configuration (code, manuals) |
The functional baseline fixes "what to build," the allocated baseline fixes "how to divide and design it," and the product baseline fixes "the actually built result." Since a later baseline is verified (traced) against the earlier baseline, consistency is maintained from requirements through to the product. For example, if the code of the product baseline deviates from the design of the allocated baseline it is filtered out in the audit, and if the allocated baseline omits a requirement of the functional baseline it surfaces in the requirements traceability matrix. In this way the baselines are linked like a chain, preventing "code without a requirement, requirements without code."
5. Configuration Management Organization/Tools and the Change-Control Flow
Configuration management is a concept, but its actual operation is implemented with an organization (CCB) and tools. Below is the detailed flow by which a single change request goes through CCB control, is reflected in the baseline, and continues on to deployment.
sequenceDiagram
participant Dev as Developer
participant CM as Configuration Manager
participant CCB as CCB
participant Repo as Repository/Baseline
Dev->>CM: Submit change request (CR)
CM->>CM: Perform impact analysis
CM->>CCB: Request review
CCB-->>CM: Approve or reject
CM->>Repo: On approval, reflect change / update baseline
Repo->>Repo: CI/CD build/deploy
Repo-->>CM: Status record / release notes
Tools automate this flow. When version control, issue tracking, and CI/CD are linked, code changes become connected to issues (change requests) and are tracked all the way through automated build and deployment, maximizing the visibility of the configuration. For example, when a developer puts an issue number in a commit message, it is automatically linked to the corresponding CR in Jira; on merge, Jenkins/GitHub Actions runs the build and tests and deploys only when they pass; and the result is automatically compiled into release notes.
| Category | Examples |
|---|---|
| Version control | Git, SVN |
| Issue/change management | Jira, Redmine |
| CI/CD, release | Jenkins, GitHub Actions |
| Infrastructure configuration | Terraform, Ansible (IaC) |
6. Deep Dive: The Expansion of Configuration Management — DevOps, IaC, SBOM, Supply-Chain Integrity
Whereas traditional configuration management targeted "source and documents," configuration management in the age of cloud and containers is expanding to far broader objects. This appears in recent Professional Engineer exams as a tendency to ask about SCM not on its own but tied together with DevOps, SBOM, and supply-chain security.
First, with IaC (Infrastructure as Code), the infrastructure itself has become an object of configuration management. When servers and networks, formerly configured by hand, are declared as Terraform/Ansible code, infrastructure changes too can be version-controlled, reviewed, and rolled back like code changes. Being able to reproduce "what state the server is in now" as code is a major advance.
Second, GitOps is a way of applying configuration-management principles to deployment operations. Taking a Git repository as the "Single Source of Truth," the desired state of the operating environment is declared in Git, and a tool such as Argo CD automatically reconciles the actual state with the Git declaration. Since every deployment is left as a Git commit, the traceability and rollback capability of configuration management extends even to deployment.
Third, SBOM (Software Bill of Materials) and supply-chain integrity have risen to prominence. Since modern software is built atop vast open-source dependencies, if one does not manage "which components at which versions are inside our product," it is hard even to grasp the scope of impact when a vulnerability such as Log4Shell (2021) arises. An SBOM manages this component list in a standard format such as SPDX or CycloneDX, and it became a de facto requirement in the wake of a U.S. Executive Order (EO 14028). In other words, configuration management is expanding in the direction of taking responsibility not only for "what I built" but also for the integrity of "what I brought in and used."
7. Considerations and Implications
- Automation linkage (DevOps integration): Integrating configuration-management tools with version control, issue tracking, and CI/CD to make the entire change-build-deploy process traceable is the modern direction. However, automation should not replace the CCB's judgment; it should be designed as risk-based control that auto-approves low-risk changes and routes only high-risk changes to human review, so that speed and control are harmonized.
- Securing visibility and accountability: The essence of change control through the CCB lies in securing the visibility and accountability of changes by leaving a record of "who, why, and what was changed." If only tools are introduced without this procedural discipline, configuration management becomes a formality.
- Expansion to the supply chain (SBOM): Since even open-source dependencies must be managed, configuration management is expanding to supply-chain integrity through the SBOM (SPDX/CycloneDX) — a component list — and release management. It becomes the basis for vulnerability response and license compliance.
- Configuring infrastructure and environments too (IaC/GitOps): Declaring and controlling not only code but also infrastructure and deployment state as code, so as to make "the entire system at a specific point in time reproducible," is the core of reliability and resilience.
- Linkage with process maturity: Since configuration management is evaluated as an essential supporting process in maturity models such as CMMI, it must be established together with organization-level standard processes and role definitions to be sustainable.
References
- IEEE Std 828, Standard for Configuration Management in Systems and Software Engineering
- ISO/IEC/IEEE 12207, Software life cycle processes
- CISA, Software Bill of Materials (SBOM): https://www.cisa.gov/sbom
- The White House, Executive Order 14028 on Improving the Nation's Cybersecurity: https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
In one line: Configuration management allows changes to work products only through a controlled procedure via the activities of identification → control (CCB) → status accounting → audit, fixes the functional, allocated, and product baselines at each point in time to guarantee integrity and traceability, and has recently seen its objects greatly expanded to IaC, GitOps, SBOM, and supply-chain integrity.