The project ends; the interface does not
An integration is typically funded as a piece of work with a start and an end. It gets built, tested, signed off and closed. The budget line disappears.
The interface, meanwhile, continues to carry clinical data every day for the next ten years, through upgrades on both sides, staff changes, and evolving requirements that nobody maps back to it.
The mismatch is not a planning oversight so much as a category error. Interfaces are not deliverables. They are running systems, and running systems need owners.
Symptoms of an unowned interface
Nobody can say with confidence what it currently sends. The documentation describes the original scope, and there have been changes since some of them made under pressure and never written down.
Failures are discovered downstream. Somebody notices a missing result rather than the interface reporting that it stopped receiving them, which means the detection latency is however long it takes a human to become suspicious.
Changes are frightening. When nobody is sure what depends on a field, the safe move is never to touch it, and the interface calcifies into something everybody works around.
What treating it as a product changes
It gets a named owner, in the same way any other part of the system does. Somebody is responsible for knowing what it does now, not what it was specified to do.
It gets monitoring aimed at the business behaviour rather than only the transport. A connection that is up while message volume has fallen to zero is not a healthy interface, and only one of those two facts is visible from infrastructure metrics.
It gets a changelog. Every interface change is recorded with the reason, which is what makes the next change safe to reason about.
And it gets a deprecation path. Fields and versions can be retired deliberately instead of accumulating forever because retirement was never anybody's job.
Volume is a signal, not a statistic
The single most useful alert on an integration is not an error rate. It is an expectation about volume: this feed normally carries a certain shape of traffic at this time of day, and it currently does not.
That catches the failure class error alerting misses entirely the upstream system that stopped sending, the filter that was tightened by accident, the scheduled job that silently stopped running.
Both sides have an owner, or it is not agreed
An interface is a contract between two organisations, and a contract with a signatory on only one side is a hope. When the other party has no named counterpart, changes arrive as surprises.
So establishing who to call is part of the build, not an escalation path discovered during an incident. It is the least technical part of integration work and one of the most valuable.
The economics are not close
Ongoing ownership looks like a cost, because it is a visible line item, while the alternative cost is distributed across incidents, workarounds and the slow accumulation of things nobody dares change.
Distributed costs are still costs. They are just harder to put in a budget, which is precisely why they are the ones that get paid.
The practical ask is small: name an owner, fund a fraction of their time, and give them the standing to say that an interface needs work before it fails. That is considerably cheaper than the alternative and much less exciting, which is why it rarely happens without someone arguing for it.
If any of the above matches a problem you are dealing with, we are happy to go deeper than a blog post reasonably can.