Industry
I've had this conversation more times than I can count. Someone from an infrastructure team or a platform org tells me they have a CMDB. I ask if they use it. There's a pause. "We have it," they say. "People update it when they remember to."
That pause tells you everything.
A CMDB that relies on human data entry begins degrading the moment it goes live. This isn't a failure of discipline or process. It's a structural property of the approach.
Consider what it takes to keep manual CMDB data current. Every provisioning event, decommission, configuration change, and relationship update needs to be reflected in the system. In a small, stable environment with rigorous process enforcement, this is merely burdensome. In a modern environment where developers have self-service cloud access, Kubernetes controllers are reconciling state constantly, and infrastructure changes happen dozens of times a day, it's impossible.
The industry has a name for this: CMDB rot. Configuration data that was accurate when entered becomes stale. Stale data accumulates. Over time, the system becomes a liability. It tells you a server exists that was decommissioned two years ago. It has no record of the Postgres cluster your DBA stood up directly in AWS last quarter. The network topology it shows is from before the last major refresh.
What causes the rot?
Staff changes. The person who understood the undocumented parts of your infrastructure leaves. The institutional knowledge that made certain data entries make sense disappears with them. Nobody else knows enough to correct it.
Shadow IT and undocumented changes. Not everything goes through change management. A developer with cloud console access provisions resources directly. A vendor appliance gets connected to the network. A one-time emergency change never makes it into the record.
Configuration drift. A server's configuration when it was provisioned is not its configuration six months later. Packages are installed, services are changed, network interfaces are reconfigured. None of this flows back into the CMDB unless someone enters it manually.
Velocity. Cloud-native infrastructure moves faster than any manual process. Containers are ephemeral by design. Autoscaling groups change size continuously. Kubernetes operators reconcile state in response to events. Capturing any of this manually is a losing battle before it starts.
The discovery agent approach (install software on managed systems, have it report configuration data back) is a real improvement over pure manual entry. At minimum, it covers the systems it runs on.
But agents have their own set of problems.
First, coverage. Agents must be installed on every system you want to discover. This means Windows servers, Linux servers, maybe containers. But what about your network equipment? Your storage arrays? Your cloud-managed services? Your identity provider? Your monitoring platform? Most of these don't support agents. The gaps in coverage tend to be exactly where the most interesting configuration relationships exist.
Second, management overhead. An agent fleet is infrastructure that needs to be maintained. Agents need to be deployed as new systems are provisioned, updated as versions change, and removed when systems are decommissioned. If decommissioning discipline is already poor (and it usually is) you end up with zombie agents reporting data from systems that no longer exist in any meaningful sense.
Third, agents report what's on the system, not what the system means in context. An agent on a Linux server can tell you what packages are installed. It can't tell you that this server is the primary node of your production PostgreSQL cluster that six applications depend on. That relationship context requires something broader than per-system reporting.
Here's the situation many organizations find themselves in: the CMDB exists primarily to satisfy compliance requirements. Auditors want to see it. Frameworks require it. So it exists, it gets populated enough to pass an audit, and then it sits there accumulating rot while teams work around it.
The paradox is that CMDB data that isn't trustworthy can't actually satisfy the intent of the compliance requirement. You have a record that says your infrastructure looks a certain way. That record may or may not reflect reality. If an incident happens and you need to determine scope, you can't rely on it. If you're doing change impact analysis, you can't rely on it. You have the CMDB and you also have to do the real work of figuring out what actually exists.
This is the worst of both worlds: the overhead of maintaining the system, without the utility.
The fundamental shift is moving from a CMDB that is told what exists to one that discovers what exists.
An observational platform doesn't wait for humans to enter data. It connects to your infrastructure through existing APIs (the ones your systems already expose for management and monitoring) and continuously discovers what's there. Every collection cycle updates the picture. Changes are detected automatically. New components appear when they're provisioned. Decommissioned systems are marked gone when they stop responding.
This flips the data quality problem on its head. Instead of data that was accurate when entered but degrades over time, you have data that reflects current state by construction. The question "is this current?" is answered by when the last collection ran, not by when a human last updated a record.
The observational model also handles coverage differently. You're not installing agents on individual systems — you're connecting to the management APIs of your platforms. One connection to the Kubernetes API server covers every workload running in that cluster. One connection to your hypervisor covers every VM. The collector model naturally extends to cover the things agents can't: network devices, storage systems, cloud-managed services, identity providers, monitoring platforms.
Non-authoritative also means something important: the platform acknowledges that it observes rather than prescribes. It doesn't claim to know what your infrastructure should look like. It maps what it actually finds. This is more honest about what a CMDB can actually deliver, and it means the data can be trusted because it comes from the source systems themselves rather than from human recollection of what those systems contain.
When a CMDB is continuously, automatically maintained, it stops being a chore and starts being a tool.
Infrastructure teams that previously ignored the CMDB (because it was always wrong and never worth the time to maintain) start using it for incident investigation. When something breaks at 2am, you can ask what changed in the last 24 hours. You can pull the dependency graph of the affected service and see what else might be impacted. The information is there because the platform collected it, not because someone entered it.
Platform teams get a view across their entire estate that they can actually use for capacity planning and rationalization. "How many of these are we actually running?" becomes a query, not a project.
Operations teams stop dreading audit preparation, because the compliance evidence is already there.
A word on what observational CMDB isn't: it's not an argument to throw away ServiceNow, Jira Service Management, or whatever ITSM platform your organization runs on. Those systems handle workflows, ticketing, change management, and service catalog functions that are genuinely valuable.
The problem isn't that ServiceNow exists. It's that the CI data inside it is wrong. An observational platform solves that problem by becoming the authoritative source of discovered configuration facts, which can then feed into your ITSM. Your change records, dependency data, and CI relationships stay current because they're populated by a system that actually knows what's there, not by whoever remembered to update the ticket.
The best outcome isn't replacing your ITSM — it's making the infrastructure data inside it trustworthy for the first time.
The reason your CMDB is always wrong isn't that your team doesn't care or doesn't have the right processes. It's that the model requires human effort to stay accurate, and human effort doesn't scale with the rate at which infrastructure changes. The only sustainable fix is a system that observes continuously and maintains itself.
That's what we built Parascope to do.