Searching for the Source(s) of Truth in Automation

Walk into almost any enterprise and you will find the same thing. Three teams, three tools, no shared view. The networking team has stood up Nautobot or NetBox. The systems team has picked something else entirely. The application team does not care about either one as long as their service runs somewhere. Nobody federated anything. Everybody calls their tool the Source of Truth.

I have seen this play out at scale. The pattern does not change. This is not a failure of execution. This is the actual state of the industry. The Single Source of Truth, the one tool that holds everything for the whole enterprise, is a fantasy. It does not exist, and chasing it is how teams burn quarters with nothing to show.

The interesting work starts when you stop chasing it and accept the distributed reality instead.

The networking team picks well and builds a silo

Networking teams almost always land on Nautobot or NetBox. That is the right call. They are good at networking, those tools are built for networking, and the data inside them is detailed and reliable. Devices, configurations, topology, IPAM. It is solid.

The problem is not the tool. The problem is that the tool becomes an island. The networking SoT was never designed to integrate with the systems or application view, and the team that built it had no reason to make it. They solved their problem correctly and created a silo in the process. That is not a contradiction. It is just what happens when each team optimizes for itself.

The systems team builds on top and stops short

Systems teams sit on top of what networking provides. Servers, virtual machines, storage, the things networking does not track. Broader scope, in theory. In practice they fall short of integrating fully with either the network layer below or the application layer above, so they end up standing up yet another SoT that talks to nobody.

The application team does not care

Application teams want their service available and performing. That is it. The underlying infrastructure, the network configs, the inventory that the other two teams obsess over, none of it registers as their problem. And honestly, from where they sit, that is a reasonable position. It just means there is no third party with any incentive to tie the first two together.

CMDBs, ServiceNow, and the discovery problem

This is usually where someone says the CMDB solves it. A central repository for every asset and relationship, kept current by discovery. ServiceNow gets pointed to most often, and on paper it is a reasonable fit for the role.

In practice, the discovery process is where it falls apart. I have walked into more than one environment where ServiceNow discovery was misconfigured, partially deployed, or quietly broken, and the data inside was wrong in ways nobody had caught. A CMDB that is feeding stale or incomplete data is worse than no CMDB, because people trust it. The tool is not the issue. The discovery feeding it almost always is.

Source control gets handed the same role, and Git is great for configuration and infrastructure as code: version history, review, audit. But it tracks intended state over time, not current state right now. At scale, with enough repos and branches and contributors, drift between what is committed and what is actually running becomes its own problem. Source control is a fine SoT for some things. It is not the SoT for everything.

Stop trying to make one tool do it all

The answer is not a better single tool. The answer is accepting multiple Sources of Truth and federating them on purpose. Let the networking team keep Nautobot or NetBox. Let the systems team keep theirs. Then build the integration between them deliberately, API-first, so each team uses its best-fit tool and shares data where sharing actually matters.

That is the part most organizations skip. They either keep fighting for one tool to rule everything, or they let the silos sit there unconnected and call it good. The work that pays off is in the middle: deliberate federation across tools that were never meant to talk, with each one honest about exactly what it covers and what it does not.

It will be interesting to see how Opsmill Infrahub handles this. It is built around the idea of managing multiple sources of truth rather than pretending one can hold everything, which is the right framing. I have not had the time to dig into it properly yet, but it looks promising. It is the first thing in a while pointed at the actual problem.