Why interfaces need their own control
In a project with several suppliers and systems, each interface sits between teams who each assume the other has taken care of the difficult parts. Unless an interface is specified, owned and tested as a unit, problems appear late, at integration, when changes are most expensive.
Keep an interface register and a specification for each
List every interface in one register: source, destination, purpose and owner. For each, maintain an interface specification with the attributes below.
| Attribute | What to define |
|---|---|
| Source and destination systems | The systems and their environments (test, production) |
| Data owner | The role accountable for the data and for resolving disputes |
| Data format | Schema, field definitions, units, code lists, character set, time reference |
| Frequency | Real-time, batch schedule, or event-driven; expected volumes and peaks |
| Security | Authentication, authorisation, encryption and credential management |
| Error handling | What is validated, what is rejected, how rejections are reported |
| Retry logic | When and how often to retry, back-off, and when to stop |
| Logging | What is recorded at each end, and for how long |
| Monitoring | Health indicators, thresholds, alert owners |
| Reconciliation | How counts or values are compared between systems and discrepancies resolved |
| Change management | Versioning, notice period, testing before change |
Assign ownership at both ends
Each interface has a named owner on both sides, and a named owner of the data it carries. Faults are traced jointly by agreed methods, starting from the logs at both ends.
Design for failure, not just the normal case
- Make processing idempotent where possible, so that a retried message does not create a duplicate.
- Use retries with increasing delay and a limit; move messages that repeatedly fail to a holding queue for investigation, rather than discarding them.
- Define behaviour when the destination is unavailable: queue, buffer or reject.
- Use a single agreed time reference and record timestamps with time zone.
Control change
Version every specification. A change to either end is raised as a change request, assessed for impact on the other, tested in a non-production environment and scheduled. Unannounced change by one party is the common cause of interface failure in service.
Test the abnormal as well as the normal
- Normal transactions at expected and peak volume.
- Invalid, duplicate, delayed and missing data.
- Destination or source unavailable; network interruption.
- Retry behaviour and recovery after restoration.
- Reconciliation completes and reports differences correctly.
Monitor interfaces in operation
Interface health should appear in central monitoring: message rates, queue depth, error counts, latency, and the age of the oldest unprocessed message. Reconciliation results are reported regularly and discrepancies are tracked as incidents or problems.