Why Integration Design Is Critical in Enterprise Software

In the month-end meeting, finance says there were four hundred and twelve orders. The warehouse system shows four hundred and nine. Nobody can say which side the missing three are wrong on.

The rest of the meeting goes on verifying figures, and the actual subject waits another week. This looks like a technical glitch, but what was lost isn't data — it is the ability to decide anything on the strength of the numbers.

That is why integration design carries so much weight in enterprise software: when two systems are connected, the real risk isn't that data fails to move but that the two sides know a different truth.

Integration isn't moving data, it's agreeing on meaning

Integration projects are usually discussed as transport: take this field, write it into that one. That is genuinely the technical part, and usually the easy one.

The hard part is that the same word doesn't mean the same thing in both systems.

A "customer" in the sales system is a person; in the accounting system it is a billing address. Three branches of one company are a single record for one side and three records for the other. "Order closed" happens when the goods ship on one side and when payment clears on the other — and for the three days in between, both systems are correct by their own definition.

These differences aren't discovered during the integration. They are discovered months after go-live, through a report that doesn't add up. So the first step isn't establishing a connection but comparing the two sides' dictionaries: how is each concept defined, and where do the definitions diverge?

Disagreement is the normal state, not an exception

Integrations are usually designed on the assumption that two systems will continuously know the same thing. In practice that assumption is never entirely true — and its not being true is not a fault.

The sources of divergence are well known. Transfer is immediate but not instantaneous: there is always a lag, from seconds to hours, and any question asked in that window gets two different answers. One side changes a record while the other still carries the old version. A transfer stops halfway. A message is delivered twice. A record is deleted on one side and not the other.

None of this can be prevented; it can only be anticipated. What separates a sound integration from a fragile one isn't that divergence never occurs, but that what happens when it does is defined.

The source of record is defined per field, not per system

"Which one is the master system?" is a staple of integration meetings, and it is usually the wrong question. The answer cannot be a single system, because no system is right about everything.

The correct arrangement is at field level. Contact details are right in the sales system, because that is where they get updated. The credit limit is right in finance, the stock count in the warehouse system. For each field one system should hold the authority to say "what is written here is correct," and the others should only read it.

Without that definition the resulting behaviour is predictable: the same field gets updated from two places and the last writer wins. An address someone entered carefully reverts an hour later through a sync. Once a user experiences that, they lose confidence in the system and start keeping the information somewhere of their own — which explains how the parallel systems described in the transformation piece become permanent.

A field-level source of record has a second benefit: it ends the argument. When a discrepancy appears, which side gets corrected is already settled, and nobody has to compare two screens to decide.

Half-finished transfers and messages that arrive twice

The most expensive integration failures come not from transfers that fail outright but from ones that stop halfway.

An order is created on one side and the connection drops while it is written to the other. It exists in the first system and not the second. If the error landed somewhere it gets noticed; if not, the gap grows for months.

Its twin is the same message processed twice. When a transfer is presumed failed and repeated, or a queue redelivers, the same order is created twice. That is harder to correct, because working out which record is the duplicate means reading its contents.

The remedy for both sits in the same place: every transfer should carry its own identity, and the receiving side should refuse to process an identity it has already handled. It is a small decision technically and very hard to add later — because historical records don't carry that identity.

Where does a failure land?

The most frequently skipped part of an integration is where failed transfers go.

In most setups the answer is a log file — which in practice means nowhere. Nobody reads it, because the person who should isn't defined and no alert was raised.

The result is a silent divergence. The system appears to work, one percent of transfers drop, and the gap accumulates over months. The three-order discrepancy at month-end is formed in exactly this way.

The arrangement that works is simple: failed transfers should collect in a visible list, that list should have an owner, and a non-empty list should register as a condition. This is the integration-side equivalent of a system that sets aside the cases it cannot process (partial automation).

Should this side stop when the other one goes down?

The least visible decision in an integration design is how tightly the two systems are bound.

In a tightly coupled arrangement a transaction completes only once the other system has answered: the order isn't recorded until accounting confirms it. That keeps data consistent at every moment, at a price: when the other system slows down this one slows down, and when it fails this one stops. In an organisation where five systems are bound this way, uptime is the uptime of the weakest link.

In a loosely coupled arrangement the transaction completes on its own side, the transfer is written to a queue, and the other side processes it when it is ready. Orders keep being taken; accounting works through the backlog when it returns an hour later. That price is also clear: for a while, the two systems know different things.

The right choice varies by field. For steps that produce money or a commitment directly — deducting stock — waiting is reasonable. Waiting to feed a reporting system is not; a minute's delay costs nothing there.

The real mistake is never making the decision. When it isn't made, the default is almost always tight coupling — because that is the easier thing to write — and the organisation discovers it on the day one system fails and the other four stop with it.

Reconciliation is a feature, not a chore done afterwards

Comparing two systems regularly instead of assuming they agree is the highest-return part of an integration design.

It needs no elaborate mechanism: at set intervals, counts and totals on both sides are compared and mismatches listed. What matters is that the comparison is part of the system rather than something a person does by hand.

The benefit runs both ways. Differences get caught while they are small and their cause can still be remembered, and it produces evidence that the system works. Without reconciliation nobody knows the system is correct — they have simply seen nothing indicating otherwise.

In closing

Integration isn't connecting two systems; it is getting two systems to agree on the same reality. Establishing the connection takes days. Defining the agreement is the actual work of the project, and it is usually the part given the least time.

So integration quality is measured not by whether data flows but by what happens when it doesn't. An arrangement with a field-level source of record, visible failures and automatic reconciliation is a system that tells you when it has gone wrong.

In systems that don't tell you, the errors accumulate and surface one day in a meeting, as a difference of three orders. In our enterprise software and automation work, integration design starts by answering these questions rather than by mapping fields.