Modern networks are dynamic: multi-vendor, multi-cloud, API-driven and constantly changing. The old configuration-management playbook – manual discovery, Excel exports and a static CMDB – can’t keep up. The result is stale data, fragile automation, slow incident response and risk that compliance asks remain theoretical, not operational.
A Network Source of Truth (NSoT) solves this by becoming the canonical, machine-readable representation of your network estate: devices, topology, configurations, policies and relationships. Unlike a traditional CMDB, an NSoT is designed to be updated continuously by automated collectors and to be consumed directly by automation pipelines, orchestration systems and analytics engines. This is not “one more database” — it’s the operational spine for an automated, auditable network.

Out with the CMDB, in with the Source of Truth
The CMDB was built for a world of physical assets, servers, printers, desktops. It struggles with today’s logical constructs: nested virtualisation, container overlays, service meshes, and sidecar proxies. Its rigid data model and legacy structure make it a poor fit for modern IT.
CMDB’s rigid data model and legacy data structure has opened the door to a series of contenders within the space, largely grouped together under the umbrella of “Source of Truth”. Some notable examples in the NetDevOps and DevOps spaces include:
- NetBox – An open-source NSoT platform that models network infrastructure and integrates with notable automation tools to gain accurate, real-time data
- Ansible – An open-source automation engine supporting IT functions including configuration management, application deployment and orchestration
- MAAS – An open-source solution offering the self-service provisioning of operating systems and implementation of all public cloud standard features.
Instead of CMDBs, many organisations are now turning to Source of Truth practices. This is often a repository or database used to store configuration data for an organisation’s IT environment.
Source of Truth is a DevOps practice
The key “why” behind all this can be easily summarised when contrasting the strengths and weaknesses of the CMDB against the NSoT further. In short, the Source of Truth is a DevOps practice that seeks to simplify configuration management by listing all configuration items and their relationships in a single location. This one version of truth can then be used for deployment automation, infrastructure management and much more.
Another key attribute of the SoT is the use of data-driven, structured data models such as YANG, which naturally integrates with well-used DevOps data structures such as YAML and JSON for frictionless flow between the ITSM process and the intended infrastructure outcome required.
Integration Integration in the age of disaggregation
Increasingly, we see IT departments stretched with their ITIL-based approaches and ITSM systems which were designed for singular, homogenous deployments of IT network infrastructure within the confines of the on-premises data centre – unable to cope as increasing amounts of their application workload estate migrates off-premises into the various public cloud PaaS, SaaS and hybrid cloud models of today.
As Network Consultants and Deployment Engineers, we see first-hand the issues that CMDB-based approaches create and frustrations throughout. Contrast this with a NSoT-led approach, where we might instead see the ability to:
- Simplify configuration management: By using a single source of truth, organisations can avoid the complexity and cost of managing multiple CMDBs across their hybrid IT network, compute, storage and application estate.
- Improve collaboration: Using a central repository for configuration data helps improve collaboration between development and operations teams (hence why they call it DevOps).
- Enable automation: With a centralised source of configuration data, it becomes easier to automate repetitive tasks such as deployment and testing, freeing up valuable development and operations resource time away from undifferentiated heavy lifting tasks.
- Facilitate auditing and compliance: A centralised repository of configuration data also makes it easier to track changes and ensure compliance with IT security standards such as SOC2, HIPAA, NIST, PCI-DSS, CESG and DORA.
How CACI can help bolster your configuration management journey
Along with a strong heritage in Network Infrastructure Engineering and Consulting, we have a strong set of ITSM Consultants available to help with your CMDB migration programmes – across the spectrum from service design, project and programme management and through to data and solution architecture.
Let us help and see how we can unlock the value of the CI data you have to bring you closer to the point of application observability over just plain asset visibility.