Integration — how data crosses system boundaries

Integration is about movement, not meaning.

It does not describe what data means, whether it is correct, or what should happen because of it. Those concerns belong elsewhere.

Integration answers one question only:

How does data move across system boundaries?

When this matters

Integration becomes relevant as soon as a business relies on more than one system.

Customer data in one place, orders in another, reporting somewhere else — this is already integration, whether planned or not. Even when everything appears connected, information is constantly crossing boundaries and picking up assumptions along the way.

Understanding integration means understanding what actually happens when data moves — and why problems often appear long after systems were connected.

Participants — who moves data

Every integration involves participants.

One system sends data. Another receives it. Sometimes the direction is fixed. Sometimes it is bidirectional.

Participants define ownership and responsibility. They answer questions like: who initiates movement, who consumes the data, and where failures must be handled.

Integration does not care what happens inside the systems — only that movement across the boundary is clearly defined.

Payload — what is moved

Payload describes what information is transferred.

Which fields are included, which are omitted, and how the structure looks during transfer. Payload is about representation, not meaning.

Two systems may interpret the same payload differently. Integration remains correct as long as the payload is transferred as defined.

Timing — when data is moved

Timing describes when movement occurs.

Data may move continuously, in batches, on demand, or with delay. Integration records when information becomes visible to another system — not whether that timing was good or bad.

If data arrives too late to be useful, that is a business concern, not an integration description problem.

Sequence — the order of movement

Sequence describes the required order of exchanges.

Some data must arrive before other data can be accepted. These are ordering constraints between movements — not internal processing steps.

When sequence is implicit, integration becomes fragile.

Medium — how data is moved

!!!

Medium describes the transport mechanism.

APIs, files, messages, streams — integration does not judge them. Changing the medium changes how data moves, not what moves or who is involved.

Resilience — when movement does not behave as expected

Crossing boundaries introduces uncertainty.

Data may arrive late, out of order, more than once, partially, or not at all. These are not business errors — they are normal outcomes of movement.

Resilience describes how these deviations are made visible and manageable, without deciding what they mean or what should happen next.

Final anchor

Integration does not decide meaning, correctness, consequences, or user experience.

It describes how data moved, under which constraints, and how deviations were handled.

If you can explain integration in these terms, the system becomes understandable.

Everything else belongs elsewhere.