Configuration Management
Practice · Chapter 2
Overview
Section titled “Overview”Architects are expected to be involved in configuration management. Many orgs have a software configuration management (SCM) team, sometimes also at the project level (which on small projects may be a single, non-dedicated person).
SCM responsibilities
Section titled “SCM responsibilities”- Identifying configuration items: software, documents, models, plans.
- Implementing a change control process.
- Managing the process and tools used for builds (automated builds and continuous integration are covered under modernizing build and deployment processes).
Change management
Section titled “Change management”A formal change control process governs changes to all aspects of a system — requirements, source code, documentation. Changes arise to fix bugs, alter business rules, or add functionality. The goal: ensure changes are appropriate and minimize the effort, difficulty, and disruption of implementing them.
Change control board (CCB)
Section titled “Change control board (CCB)”A group of stakeholders designated to analyze proposed changes and decide whether to implement them. As an architect you may sit on a formal or informal CCB, helping to:
- Evaluate whether a proposed change should be implemented.
- Prioritize by importance and severity (for defects).
- Estimate the effort to implement.
Four approaches to change management
Section titled “Four approaches to change management”| Approach | How it works | Trade-off |
|---|---|---|
| CCB reviews all changes (most formal) | Every change, large or small, goes through the board | Multiple viewpoints catch ramifications a single person can’t — but slow; the CCB can become a bottleneck (decisions + meeting logistics). |
| No CCB | Individual developers decide all changes | Fastest; empowers/satisfies developers — but only one mind per change; quality depends entirely on that developer; risky for large/complex changes. |
| CCB reviews some changes (balance) | Board reviews the most important/complex changes only | The riskiest changes get scrutiny without making the CCB a bottleneck for the rest. Depends on size/complexity/importance, not just defect-vs-enhancement. |
| Multi-level CCB (most pragmatic) | Always use a CCB, but with tiered authority; low-impact changes approved at lower levels, high-impact escalated | Balances speed and control. Project stage matters — focus shifts from flexibility toward stability/control as release nears. |
Citations
Section titled “Citations”- Software Architect’s Handbook (Packt, 2018), Ch.2 “Configuration management”, pp. 128-131.