Components do not experience the whole journey
A connected product crosses several boundaries. A physical event becomes a device reading. The reading becomes a message. A communications service transports it. A platform stores and interprets it. Software presents it to a person or passes it to another system.
Each component can behave exactly as designed while the end-to-end result remains late, ambiguous or unusable. That is why the interfaces are not merely integration details. They are part of the product experienced by the operation.
A boundary without an explicit contract becomes a place where each component can be “working” and the system can still be wrong.
Define what crosses each boundary
An interface description should cover more than a field list. It should explain meaning and behaviour:
- What information is produced, in which units and with which identifier?
- Which clock supplies the timestamp?
- How are missing, duplicated or out-of-order messages handled?
- What indicates quality, accuracy or confidence?
- How is a device, physical asset and customer record associated?
- What happens when a component is unavailable?
- Which part of the system owns retries, validation and alerts?
These decisions can be recorded in code, schemas and tests, but they first need to be understood in operational terms.
Offline behaviour is normal behaviour
Connected products should not treat every loss of service as an exceptional edge case. Coverage changes, power cycles, maintenance and upstream outages are normal parts of many real environments.
The system needs a deliberate account of what continues locally, what pauses, what is retained and what happens after service returns. A user also needs to distinguish “the asset has not moved” from “the platform has not received a new report”. Those are very different operational states.
Give the human handover the same attention
The final technical interface is often a screen, alert or report. Its job is not simply to expose data. It must help an authorised person understand status, uncertainty and the next useful action.
A technically accurate value can still mislead if the interface hides its age, accuracy or source. A notification can create noise if it does not reflect the user’s responsibility. A report can contain every event and still fail to answer the investigation question.
Test journeys, not only components
Component tests are necessary, but connected systems also need representative end-to-end scenarios. Follow information from the physical event through to the operational outcome. Include degraded conditions such as low signal, delayed transmission, a restarted device, duplicate data and a user with restricted access.
For every scenario, decide what the system should record, what the user should see and what evidence should remain afterwards. This turns a vague integration risk into something reviewable.
Ownership closes the gap
An interface must have an owner even when responsibility is shared across teams or suppliers. Someone needs to maintain the contract, coordinate changes and decide whether an observed failure belongs inside a component or at the handover.
When boundaries are explicit, technical teams can make changes with a clearer view of downstream consequences, and the operation receives a system rather than a collection of individually successful parts.