Configuration Management
Configuration management maintains accurate information about IT components and their relationships throughout their lifecycle. This discipline differs from asset management in its focus: where asset management tracks ownership, cost, and financial value, configuration management records technical attributes, dependencies, and the structural connections that determine how services function. Every service outage investigation, change impact assessment, and capacity planning exercise depends on configuration data that reflects reality.
- Configuration Item (CI)
- Any component that requires management to deliver an IT service. CIs include hardware (servers, network devices, workstations), software (applications, operating systems, middleware), documentation (runbooks, architecture diagrams), and services (email, file storage, case management systems).
- Configuration Management Database (CMDB)
- A repository that stores configuration records and the relationships between them. The CMDB provides a model of the IT environment that supports incident diagnosis, change planning, and service dependency analysis.
- Configuration Record
- The set of attributes that describe a single configuration item. A server configuration record includes hostname, IP address, operating system version, installed applications, physical location, and relationships to other CIs.
- Relationship
- A defined connection between two configuration items that indicates dependency, composition, or association. “Database server X hosts application Y” expresses a hosting relationship; “Application Y depends on authentication service Z” expresses a dependency relationship.
- Configuration Baseline
- A recorded snapshot of configuration state at a specific point in time, used as a reference for comparison, recovery, or compliance verification.
- Federation
- An architectural approach where configuration data remains in source systems rather than being copied to a central repository, with the CMDB providing a unified view through integration.
Configuration item identification
The first decision in configuration management defines what to track. Recording too little leaves gaps that undermine the CMDB’s usefulness; recording too much creates maintenance burden that causes data to decay. The scope decision balances visibility against sustainability.
CI identification follows a decomposition principle: start with services that the organisation delivers, then identify the components that constitute those services. A case management service comprises an application, a database, application servers, a load balancer, network connections, and authentication integration. Each of these components becomes a CI if changes to it affect service delivery and if tracking it provides value for incident resolution, change assessment, or compliance.
The decomposition stops at a level where further breakdown no longer aids decision-making. Tracking individual memory modules inside a server rarely helps diagnose incidents or plan changes, so the server itself forms the lowest-level hardware CI. Tracking individual database tables rarely aids service management, so the database instance forms the lowest-level data CI. The appropriate depth varies by component criticality: a core network switch warrants more detailed tracking than a desktop workstation.
+------------------------------------------------------------------+| CI DECOMPOSITION LEVELS |+------------------------------------------------------------------+| || Level 1: Services || +------------------------------------------------------------+ || | Case Management Email Service File Storage | || | Service | || +------------------------------------------------------------+ || | | | || v v v || Level 2: Applications || +------------------------------------------------------------+ || | Primero Exchange SharePoint Active Directory | || | Application Online Online | || +------------------------------------------------------------+ || | | | || v v v || Level 3: Platform Components || +------------------------------------------------------------+ || | PostgreSQL Application Web Authentication | || | Database Servers Servers Services | || +------------------------------------------------------------+ || | | | || v v v || Level 4: Infrastructure || +------------------------------------------------------------+ || | Physical Virtual Network Storage | || | Servers Machines Devices Arrays | || +------------------------------------------------------------+ || || - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - || Below this line: not tracked as CIs (components within servers, || individual files, memory modules, cables) |+------------------------------------------------------------------+Figure 1: CI decomposition showing tracked levels and the boundary where tracking stops
CI types group items with common attributes. All physical servers share attributes like manufacturer, model, serial number, rack location, and warranty expiry. All applications share attributes like version, vendor, support contact, and owning team. Defining CI types creates consistency in what gets recorded and enables meaningful queries across items of the same type.
A practical CI type structure for a mission-driven organisation includes:
| CI Type | Subtypes | Typical Count |
|---|---|---|
| Service | Business service, technical service, shared service | 15-50 |
| Application | Web application, desktop application, mobile application, integration | 30-150 |
| Server | Physical server, virtual machine, container host | 20-500 |
| Database | Relational database, document store, data warehouse | 10-100 |
| Network device | Router, switch, firewall, access point, load balancer | 20-200 |
| Endpoint | Workstation, laptop, mobile device, thin client | 50-2000 |
| Cloud resource | Compute instance, storage account, managed service | 10-500 |
| Document | Runbook, architecture diagram, configuration specification | 50-300 |
The count ranges reflect organisational scale. An organisation with 50 staff operating primarily through cloud services might track 200 CIs total. An organisation with 500 staff across 15 country offices with on-premises infrastructure in each might track 3,000 CIs.
Attributes and relationships
Each CI type defines mandatory and optional attributes. Mandatory attributes must be populated for every CI of that type; optional attributes capture additional detail where available. The attribute schema determines what questions the CMDB can answer.
Server CI attributes demonstrate the pattern. Mandatory attributes include hostname (the unique identifier), IP addresses (for network location), operating system and version (for patch management and compatibility), status (in service, retired, under maintenance), and owning team (for accountability). Optional attributes include physical location for on-premises equipment, cloud provider and region for cloud instances, primary purpose description, and maintenance window preferences.
Relationship types connect CIs in ways that reflect operational reality. The relationship model must answer the questions that service management processes ask. Incident management asks “what services does this server support?” and “what other components depend on this database?” Change management asks “what will be affected if we upgrade this network switch?” and “what services share this authentication system?”
+------------------------------------------------------------------+| RELATIONSHIP TYPE MODEL |+------------------------------------------------------------------+| || COMPOSITION (contains/contained by) || +------------------+ +------------------+ || | Data Centre |--------->| Server Rack | || | | contains | | || +------------------+ +--------+---------+ || | || | contains || v || +--------+---------+ || | Physical Server | || +------------------+ || || HOSTING (runs on/hosts) || +------------------+ +------------------+ || | Virtual Machine |--------->| Hypervisor | || | | runs on | | || +------------------+ +------------------+ || || DEPENDENCY (depends on/supports) || +------------------+ +------------------+ || | Web Application |--------->| Database | || | | depends | | || +------------------+ on +------------------+ || || CONNECTIVITY (connects to/connected from) || +------------------+ +------------------+ || | Application |--------->| External API | || | Server | connects | | || +------------------+ to +------------------+ || || ASSOCIATION (related to) || +------------------+ +------------------+ || | Runbook |--------->| Application | || | Document | documents| | || +------------------+ +------------------+ || |+------------------------------------------------------------------+Figure 2: Core relationship types that enable impact analysis and dependency mapping
The relationship model builds a graph structure where CIs are nodes and relationships are edges. Traversing this graph from any starting point reveals the upstream dependencies (what this CI needs to function) and downstream dependents (what relies on this CI). Impact analysis for a planned change traverses downstream to identify affected services. Root cause analysis for an incident traverses upstream to identify potential causes.
A worked example illustrates the power of relationship data. Consider a database server showing high CPU utilisation:
- Query downstream dependents of the database server
- Find three applications: case management, reporting dashboard, mobile data collection
- Query downstream dependents of those applications
- Find services: case management service (critical), programme reporting service (high), field data collection service (critical)
- Conclude: this database issue potentially affects two critical services and one high-priority service
Without relationship data, the same analysis requires manual investigation, institutional knowledge, or guesswork. With accurate relationships, the query returns results in seconds.
CMDB architecture
The CMDB architecture determines how configuration data is stored, accessed, and maintained. Three fundamental approaches exist: centralised repository, federated integration, and hybrid combination.
A centralised repository stores all configuration records in a single database. Discovery tools, manual updates, and integrations all write to this central store. Queries and reports draw from one source of truth. This approach simplifies querying and ensures consistency but creates data synchronisation challenges. When a server’s IP address changes in reality, that change must propagate to the CMDB through discovery, import, or manual update. Delays or failures in propagation cause the CMDB to diverge from reality.
A federated architecture leaves configuration data in authoritative source systems and provides unified access through integration. Server data remains in the virtualisation management platform, network data remains in network management tools, cloud data remains in cloud provider consoles, and the CMDB presents a combined view through API integration. This approach keeps data closer to its source and reduces duplication but requires robust integration and handling of data format differences across systems.
A hybrid architecture stores core CI records and relationships centrally while federating detailed attributes to source systems. The CMDB holds the service model, CI identifiers, ownership, and relationships. When detailed server specifications are needed, the query retrieves them from the virtualisation platform in real time. This approach balances query simplicity against data freshness.
+-------------------------------------------------------------------+| CMDB ARCHITECTURE OPTIONS |+-------------------------------------------------------------------+| || CENTRALISED || +------------------------+ || | CMDB | || | +------------------+ | || | | All CI Records | | || | | All Attributes | | || | | All Relationships| |<---+---+---+---+ || | +------------------+ | | | | | || +------------------------+ | | | | || | | | | || +-----------+ +-----------+ | | | || | Discovery | | Manual | | | | || | Tools | | Entry | | | | || +-----------+ +-----------+ | | | || +---------+ | | || | VM Platform | | || +-------------+ | || +------------+ || | Cloud APIs | || +------------+ || || FEDERATED || +------------------------+ || | CMDB (Index Only) | || | +------------------+ | || | | CI References | | || | | Relationships | | || | +------------------+ | || +------------------------+ || | | | || v v v || +----------+ +----------+ +----------+ || | VM | | Network | | Cloud | || | Platform | | Mgmt | | Console | || | (server | | (network | | (cloud | || | data) | | data) | | data) | || +----------+ +----------+ +----------+ || || HYBRID || +------------------------+ || | CMDB | || | +------------------+ | || | | Core CI Records | | || | | Relationships | | || | | Ownership | | || | +------------------+ | || +------------------------+ || | | | || | Live queries for detailed attributes || v v v || +----------+ +----------+ +----------+ || | Source | | Source | | Source | || | System A | | System B | | System C | || +----------+ +----------+ +----------+ || |+-------------------------------------------------------------------+Figure 3: Three CMDB architecture approaches with their data flow patterns
The architecture choice depends on organisational context. Centralised repositories suit organisations with stable infrastructure, limited integration capability, and tolerance for periodic data refresh. Federated architectures suit organisations with strong integration skills, dynamic cloud infrastructure, and requirements for real-time accuracy. Hybrid approaches suit organisations seeking to balance these factors.
For mission-driven organisations, practical considerations dominate architectural purity. A CMDB that requires constant integration maintenance will not survive staff turnover in a small IT team. A centralised CMDB with monthly discovery scans provides more value than an ambitious federated design that remains half-implemented. The sustainable architecture is the one that will actually be maintained.
Data population and maintenance
Configuration data enters the CMDB through discovery, integration, and manual entry. Each mechanism has appropriate uses and inherent limitations.
Discovery tools scan the network and interrogate systems to identify CIs and their attributes automatically. Agent-based discovery installs software on target systems that reports configuration data to a central collector. Agentless discovery uses protocols like SNMP, WMI, and SSH to query systems remotely. Discovery excels at identifying infrastructure CIs (servers, network devices, installed software) but cannot determine business context, ownership, or service relationships.
Discovery configuration requires thoughtful scoping. Scanning everything creates noise; scanning too narrowly creates gaps. A practical approach starts with known network ranges and expands coverage iteratively. Discovery schedules balance freshness against system load: daily scans for rapidly changing cloud infrastructure, weekly scans for stable data centre equipment, monthly scans for endpoints.
Integration feeds connect the CMDB to authoritative source systems through APIs or file imports. The virtualisation platform provides definitive data about virtual machines. The cloud provider console provides definitive data about cloud resources. The endpoint management system provides definitive data about workstations. Each integration should flow from the system of record for that data type.
Manual entry remains necessary for CIs that cannot be discovered and relationships that cannot be inferred. Service definitions, business context, ownership assignments, and custom relationships require human input. The goal is to minimise manual entry for attributes that can be automated while preserving it for context that requires human judgment.
+-------------------------------------------------------------------+| DATA POPULATION AND RECONCILIATION |+-------------------------------------------------------------------+| || +-------------+ +-------------+ +-------------+ || | Discovery | | Integration | | Manual | || | Scan | | Feeds | | Entry | || +------+------+ +------+------+ +------+------+ || | | | || v v v || +------+------------------+------------------+------+ || | STAGING / RECONCILIATION | || | | || | 1. Match incoming records to existing CIs | || | 2. Identify new CIs requiring creation | || | 3. Identify conflicts requiring resolution | || | 4. Identify stale CIs for review | || | | || +---------------------------+-----------------------+ || | || +--------------------+--------------------+ || | | | || v v v || +------+------+ +------+------+ +------+------+ || | Automatic | | Review | | Automatic | || | Updates | | Queue | | Creation | || | (matched, | | (conflicts, | | (new CIs, | || | no conflict)| | exceptions)| | validated) | || +------+------+ +------+------+ +------+------+ || | | | || v v v || +------+--------------------+--------------------+------+ || | CMDB | || | (Production Data) | || +-------------------------------------------------------+ || |+-------------------------------------------------------------------+Figure 4: Data flow from sources through reconciliation to production CMDB
Reconciliation resolves conflicts between data sources. When discovery reports a server’s IP address as 10.0.1.50 but the network management system reports 10.0.1.51, reconciliation rules determine which source to trust. Establishing source priority by attribute type resolves most conflicts automatically: trust the virtualisation platform for VM specifications, trust the endpoint management system for workstation details, trust the cloud console for cloud resource attributes.
Data quality degrades without active maintenance. Servers get decommissioned but their CMDB records persist. Applications get upgraded but their version attributes remain unchanged. Relationships become outdated as infrastructure evolves. Maintenance processes counter this decay through scheduled verification, exception handling, and periodic audits.
Verification queries identify stale data by comparing CMDB records against current discovery results. CIs that discovery no longer finds are candidates for review. CIs with attributes that differ from discovery results are candidates for update or conflict resolution. Running verification weekly and addressing exceptions within 5 business days prevents quality degradation.
Baseline management
A configuration baseline captures the approved configuration state of a CI or group of CIs at a specific point in time. Baselines serve multiple purposes: establishing a known-good state for recovery, documenting approved configurations for compliance, and enabling comparison to detect drift.
Baseline creation follows significant events. After a new application deployment, baseline the application servers’ configuration to record the approved state. After a security hardening exercise, baseline the affected systems to document compliance. Before a major upgrade, baseline current state to enable rollback comparison.
The baseline contains the complete configuration record at capture time: all attributes and relationships for the included CIs. Baseline storage must be immutable; once created, a baseline cannot be modified. Baselines can be superseded by newer baselines but the historical record remains available.
+-------------------------------------------------------------------+| BASELINE MANAGEMENT MODEL |+-------------------------------------------------------------------+| || Time ---> || || CI: Application Server 1 || || +--------+ || | State | OS: Ubuntu 22.04 || | t=0 | App: v2.1.0 || +---+----+ Memory: 8GB || | || | [Baseline B1 created: "Pre-upgrade baseline"] || | || v || +--------+ || | State | OS: Ubuntu 22.04 || | t=1 | App: v2.2.0 <-- upgraded || +---+----+ Memory: 8GB || | || | [Baseline B2 created: "Post-upgrade baseline"] || | || v || +--------+ || | State | OS: Ubuntu 22.04 || | t=2 | App: v2.2.0 || +---+----+ Memory: 16GB <-- changed (unplanned) || | || | [Drift detected: Memory differs from B2] || | || v || Comparison: Current vs B2 || +------------------+------------------+ || | Attribute | Status | || +------------------+------------------+ || | OS | Match | || | App version | Match | || | Memory | DRIFT (8->16GB) | || +------------------+------------------+ || |+-------------------------------------------------------------------+Figure 5: Baseline creation and drift detection over time
Configuration drift occurs when actual configuration diverges from the approved baseline. Drift indicates either an uncontrolled change (a problem) or a controlled change that was not reflected in a new baseline (a process gap). Drift detection compares current discovery data against the active baseline and reports differences.
Automated drift detection runs on a schedule appropriate to the environment’s rate of change. Production servers with strict change control benefit from daily drift detection. Development environments with frequent legitimate changes might use weekly detection with higher tolerance thresholds.
Drift response depends on the nature of the variance. Unauthorised changes trigger investigation: who made the change, why, and what are the implications? Process gaps trigger baseline updates: if the change was approved through change management but the baseline was not updated, update the baseline and improve the process. Legitimate operational changes (like memory added during emergency capacity expansion) trigger retroactive change records to maintain audit trail accuracy.
Service model integration
The CMDB’s service model connects technical components to business-meaningful services. This connection transforms infrastructure data into service intelligence. Without service mapping, the CMDB answers questions about technology. With service mapping, it answers questions about service delivery.
Service mapping defines which CIs constitute each service and how they relate. The case management service comprises the Primero application (dependency), which runs on application servers APP-01 and APP-02 (hosting), which connect to database server DB-01 (dependency), which stores data on storage array SAN-01 (hosting). This chain of relationships enables service impact analysis.
The service model distinguishes business services from technical services. Business services are what end users consume: “case management,” “email,” “file storage.” Business services appear in the service catalogue and have associated SLAs. Technical services are internal IT capabilities that support business services: “database hosting,” “load balancing,” “authentication.” Technical services do not appear in the user-facing catalogue but appear in the technical view.
Building the service model requires collaboration between IT operations (who know the technical components) and service owners (who know the business context). A practical approach starts with critical services: identify the 10-15 services that matter most, map their components thoroughly, then expand coverage incrementally.
Service models require maintenance as infrastructure changes. When an application moves to a new database server, the relationship must be updated. When a service adds a new component, the model must expand. Embedding service model updates in the change management process ensures that approved changes include CMDB updates.
Process integration
Configuration management provides foundation data for other service management processes. The value of accurate configuration information multiplies through integration with incident management, change management, and service level management.
Incident management integration enables impact assessment and root cause analysis. When an incident ticket is logged against a service, the CMDB provides the list of underlying components to investigate. When a component alert fires, the CMDB identifies the affected services for priority classification. Bidirectional linking between incident records and CI records builds a history of which components cause problems, informing problem management priorities.
Integration works through CI fields in incident records. The incident form includes a CI reference field that links to the CMDB. Populating this field accurately enables queries like “show all incidents affecting the case management service in the past 90 days” or “show all incidents related to database server DB-01.”
Change management integration enables impact analysis before changes occur. A change request to upgrade a database version references the database CI. The CMDB provides the upstream path to affected services and the downstream path to dependent infrastructure. This analysis informs risk assessment, testing requirements, and communication planning.
Change records link to affected CIs, creating an audit trail of what changed and when. Post-implementation, the CI records update to reflect the new configuration. If the change created new CIs or retired old ones, the CMDB reflects those additions and removals.
Service level management integration connects SLA commitments to monitored components. The service model shows which CIs must be monitored to measure service availability. When component monitoring detects an outage, service mapping translates that into service impact for SLA reporting.
Implementation considerations
Configuration management scales across a wide range of organisational contexts. The discipline’s principles remain constant while implementation approaches adapt to available resources and organisational complexity.
Limited IT capacity
Organisations with minimal dedicated IT staff need configuration management approaches that deliver value without consuming scarce time. The priority is establishing basic visibility that supports incident resolution and change awareness, not comprehensive CMDB implementation.
Start with a simple CI inventory in spreadsheet format tracking critical systems only. Define “critical” narrowly: the 20-30 systems whose failure would significantly impact operations. For each critical system, record the essential attributes: name, purpose, owner, IP address or URL, and dependencies on other systems. This basic inventory, maintained manually, provides more value than an elaborate CMDB design that remains unimplemented.
Discovery tools are not required at this scale. Manual updates during changes keep the inventory current. The discipline comes from habit: every time a system is installed, modified, or retired, update the inventory. Building this habit matters more than tool sophistication.
Relationships at this scale focus on service dependencies. Document which systems the case management service needs to function. Document which systems the email service needs. These service maps, even as simple diagrams, enable faster incident response when something breaks.
Small IT teams
Organisations with 2-5 IT staff can implement basic CMDB functionality using service desk tools that include asset and configuration modules. Open source options like GLPI, i-doit, or iTop provide CMDB capability at no licensing cost. Commercial service desk platforms often include basic CMDB functionality in nonprofit licensing.
At this scale, implement automated discovery for infrastructure components. Network discovery identifies active devices and their IP addresses. Agent-based discovery on servers reports operating system, installed software, and hardware specifications. Cloud provider APIs export resource inventories. Automated discovery reduces manual data entry and improves accuracy.
Focus relationship modeling on service dependencies. Build service maps for business-critical services first, then expand coverage. Relationship data takes more effort to maintain than attribute data, so invest relationship modeling effort where it provides the most value.
Assign CMDB maintenance responsibility explicitly. Without clear ownership, data quality degrades. One team member should own discovery configuration, data quality monitoring, and exception resolution, even if this represents only a few hours per week.
Established IT functions
Organisations with dedicated IT departments can implement comprehensive configuration management with federated data sources, automated reconciliation, and deep process integration.
Select a CMDB platform that integrates with existing service desk and monitoring tools. Evaluate integration capabilities before feature richness; a CMDB that cannot connect to discovery tools and service desk systems provides limited value regardless of its native functionality. Commercial options include ServiceNow, Freshservice, and ManageEngine; open source options include i-doit and iTop.
Implement automated discovery across all infrastructure segments: data centre, cloud, network, and endpoints. Configure discovery schedules appropriate to each segment’s rate of change. Establish reconciliation rules that resolve conflicts between sources automatically where possible and route exceptions for human review.
Build the service model comprehensively for all services in the service catalogue. Integrate the CMDB with change management such that changes require affected CI identification and post-implementation CI updates. Integrate with incident management such that incident records link to affected CIs.
Implement baseline management for production systems subject to change control. Configure drift detection to identify unauthorised changes. Establish governance for baseline creation, comparison, and drift response.
Federated organisational structures
Organisations with autonomous country offices or merged entities face additional complexity in configuration management. Each unit may have its own infrastructure, its own tools, and its own practices. Achieving enterprise-wide visibility requires either technical federation or process alignment.
Technical federation aggregates configuration data from multiple sources into a unified view. This requires integration development, data mapping, and ongoing maintenance. The benefit is centralised visibility for enterprise-level decisions. The cost is integration complexity and dependency on multiple source systems.
Process alignment standardises configuration management practices across units without technical integration. Each unit maintains its own CMDB or inventory using agreed CI types, attributes, and relationship models. Periodic exports or manual aggregation provide enterprise visibility for planning purposes. The benefit is lower integration complexity. The cost is reduced real-time visibility and increased manual effort.
Many federated organisations adopt a hybrid approach: technical integration for critical shared infrastructure and process alignment for unit-specific systems. Global cloud services and shared applications feed a central CMDB. Country office infrastructure is documented locally using standard formats that enable periodic aggregation.
Technology options
CMDB implementation requires tooling decisions. The market offers open source platforms, commercial products with nonprofit programmes, and cloud-native services.
Open source options provide CMDB capability without licensing costs. GLPI combines asset management and CMDB functionality with service desk features, widely deployed in mission-driven organisations due to its comprehensive free tier. i-doit focuses specifically on CMDB and documentation with strong relationship modeling. iTop provides IT service management including CMDB with configurable data models. These platforms require self-hosting and internal maintenance but avoid vendor lock-in and licensing uncertainty.
Commercial platforms with nonprofit programmes reduce licensing costs while providing vendor support. ServiceNow offers significant discounts through its nonprofit programme for organisations meeting eligibility criteria, providing enterprise CMDB capability with strong discovery and integration. Freshservice includes CMDB functionality in its nonprofit pricing. ManageEngine ServiceDesk Plus offers CMDB as part of its service desk platform with nonprofit discounts.
Cloud service provider native tools provide configuration visibility for cloud resources specifically. AWS Config tracks configuration for AWS resources. Azure Resource Graph provides query capability across Azure resources. Google Cloud Asset Inventory catalogues GCP resources. These tools excel at their respective cloud platforms but do not provide multi-cloud or on-premises coverage.
The selection depends on organisational context. Self-hosted open source suits organisations with Linux administration skills, data sovereignty requirements, and tolerance for self-support. Commercial platforms suit organisations prioritising vendor support, integration breadth, and implementation speed. Cloud-native tools suit organisations operating primarily within a single cloud provider.
Regardless of platform selection, the configuration management discipline matters more than the tool. An organisation with rigorous practices using spreadsheets achieves better outcomes than one with sophisticated tooling and poor practices. Invest in practices first, then select tools that support and scale those practices.