How the Network Source of Truth is replacing the CMDB

For years, the Configuration Management Database (CMDB) has been an integral part of IT service management (ITSM) for organisations. It has been the go-to tool for managing the configuration items (CI) of an organisation’s IT environment, including hardware, software and relationships between them. Indeed, this is to the extent that most people raising change requests even call them “CIs” without necessarily knowing what that stands for. But no longer. 

More recently, the rise of DevOps practices such as Network Source of Truth (NSoT), service bus, event-driven architecture and continuous integration/continuous deployment (CI/CD) have led to a decline in the use of the CMDB and IT Infrastructure Library (ITIL) practices. In this blog, we’ll explore why the CMDB is becoming less relevant as organisations mature their DevOps journey and contrast some of the disadvantages of the CMDB compared to the NSoT. 

Out with the CMDB, in with the Source of Truth 

The traditional CMDB model, as mentioned above, is used to manage configuration items, track changes and support key ITIL processes such as incident management, problem management and capacity management. Unfortunately, it also dates from a time when many of these were directly correlated with physical assets – the bare–metal server, the office printer; the desktop PC – that don’t deal well with logical or conceptual models prevalent in modern IT workloads – nested virtualisation, container network layers, side car proxies and so on. 

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 
• Ralph 
• MAAS 

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 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.