A change can be technically successful and still leave the rest of the organization with an inaccurate picture of what is running.
The equipment works. The required checks pass. The change is closed.
But your inventory might still list that retired equipment as active. The monitoring system might still be looking for a it, too. The service map might show a relationship that didn’t get updated.
I’ve been thinking about how easily service owners might turn this into somebody else’s problem.
The people closest to the infrastructure may expect the shared platform to fix its records. The people operating that shared platform may try to standardize how source systems describe themselves.
The disagreement can become more important than the correction.
The bigger issue isn’t which team administers which tool. It’s whether the information other teams depend on is treated as part of delivering the service in the first place.
The work doesn’t end with the working system
Consider a routine replacement of some infrastructure.
In the replacement, the engineers performing the work know what changed. They know which device was retired, what replaced it, where it belongs, and what role it serves. That is information they should be helping to maintain, not leaving another team to reconstruct through discovery or an incident.
The change was validated. From a narrow engineering perspective, it’s done. But recovery planning, monitoring, and automation may all depend on records that describe what changed.
Other teams have legitimate reasons to depend on it. Someone planning recovery needs to know what infrastructure supports a service. Someone monitoring the environment needs to distinguish a device that failed unexpectedly from one that was intentionally removed.
A shared inventory, configuration database, or observability platform can provide those views without every consumer connecting to the underlying infrastructure directly. But the source of that context still matters.
I’m not arguing that an engineer should manually update five different applications before closing a change. I’d rather see the update become part of the end-to-end workflow. An inventory change could flow through an API, a supported integration, or an automated process that checks whether the downstream systems caught up.
Some records will update immediately; others may have agreed delays. What shouldn’t happen is treating them as unrelated administrative work that somebody will eventually clean up.
If we can automate configuring the device, we should at least be thinking about how we maintain the information describing it.
The shared platform has responsibilities too
Now suppose the inventory was updated correctly, but a shared platform integration fails to carry the change downstream.
That’s a different problem.
The source information isn’t the problem anymore. The integration or the way the platform interprets that information is.
The team operating the shared platform may need to investigate collection, identity matching, transformations, and how current its data is. It may need to fix a mapping, change an integration, or work with a vendor. It can’t assume the source is defective every time a consumer finds an error.
The infrastructure team may need to explain what a field means or help reproduce the issue. Neither team can resolve everything by insisting its own records are correct.
This is where the boundary gets less tidy. The domain specialist understands the meaning of the source information. The platform specialist understands how that information is collected and represented to its consumers. If something important is lost between the two, fixing it may require both.
A platform might also infer information nobody explicitly supplied. Dynamic application dependencies are one example. The platform owns how it makes and presents those inferences; domain experts can help validate their meaning without pretending they know every runtime relationship.
Sending a signal isn’t the same as making it useful
I see a similar problem in observability and traditional operations.
A centralized operations function may receive thousands of technically valid alerts. A system designed to tolerate component failures can produce signals whose meaning depends on the architecture and customer impact.
The team closest to the service is usually better positioned to explain what degraded redundancy means, which failures need intervention, and what action is useful. The team operating the observability platform may be better positioned to handle collection, routing, correlation, and the experience of the people responding.
Neither can solve the whole problem alone.
This isn’t a new idea. Google’s SRE guidance on operational toil makes the case for engineering away recurring operational work rather than simply absorbing more of it. I think there’s a similar responsibility to improve the information that creates the work.
Otherwise incomplete context keeps moving between teams without improving the result.
Ownership has to be possible
There is an obvious counterargument to asking domain teams to maintain more trustworthy information: they might not have the time, access, permissions, or tools to do it.
I think that’s often true.
Saying a team owns its data without giving it a supported way to correct records is not much of an operating model. Neither is expecting a shared platform team to quietly repair every gap by inventing domain knowledge it doesn’t have.
We need practical agreements about which information is supplied, how systems identify the same thing, how current the information needs to be, how it is validated, and where a correction goes when something doesn’t match.
Ideally, this becomes part of delivery: the change updates records, integrations carry the information, validation catches failures, and someone can correct what didn’t make it through.
Reality will be messier. Integrations fail, vendors have bugs, and correcting a discrepancy may require several people who control different parts of the path.
I don’t think there’s a perfect responsibility chart that makes all of that go away.
There’s still an expectation worth keeping, and some pride in the work behind it: if others depend on information about systems we operate, we should care whether it remains useful after it leaves our hands.
That applies to the people producing it and to the people building the shared services around it. The data is part of the service, even when no single team owns every step of its journey.