Interoperability is not obtained by writing it into the specification
Two systems exchange only if someone holds the mandate to settle the format, the cadence and the responsibility for the data. That mandate is assigned before development starts.
The requirement appears in almost every public tender: the system shall be interoperable with existing systems. It is rarely followed by a description of what that means, and it then produces a technical interface nobody uses.
An interface is not an exchange
Delivering a documented programming interface is a technical service. It ends at acceptance. Making data circulate between two authorities is a lasting arrangement between two organisations that share neither procedures, nor calendar, nor the same accountable officer.
Three questions decide the outcome, and none of them is technical.
Which record governs? When two systems hold divergent information about the same person, one of them prevails. That rule is written once, or it is re-argued at every incident.
At what cadence? Data transmitted nightly and data transmitted at the moment of change do not call for the same architecture and do not cost the same. Cadence follows from use: a check at a border post does not tolerate the lag that a monthly statistic absorbs without difficulty.
Who answers for an error? Wrong data transmitted by system A and acted on by system B produces a wrong decision. Responsibility is apportioned in advance, failing which it is argued at the moment a decision has to be reversed.
The interface agreement
Those answers fit in a short document, signed by both authorities, stating the format, the cadence, each party’s point of contact, what to do when the far end is unavailable, and how long exchanges are retained. It does not belong to the development contract; it precedes it.
A project that starts developing before that document exists is developing against an assumption. The assumption proves false at integration, which is the point in a project where correction costs most.
The format is not the issue
The choice of an exchange standard occupies a place in the debate out of proportion to its influence on the result. A documented, stable, human-readable format is enough in almost every case. What fails is not the format: it is the absence of a rule for what happens when the far end stops answering for six hours, or when a record transmitted yesterday has since been deleted.
Both situations occur. An architecture that has not addressed them will address them in production, under time pressure, by a decision taken in haste.
Systems one does not control
An administration frequently has to exchange with a system it neither owns nor operates, and from which it will obtain no modification. The answer is not to wait. It is to place a mediation component under its own control, which absorbs the far end’s peculiarities and presents a stable interface to the rest of the estate.
That component has a cost and a value: it insulates the organisation from changes decided elsewhere, which is precisely what no contract can secure for it.
What to require
An interface agreement signed before development starts, carrying the three answers. A written recovery procedure for unavailability of the far end. A log of exchanges, retained and searchable. And a representative test dataset, provided by the holder of the far-end system, without which no integration is verified before go-live.
