How to connect fragmented systems: an integration and API strategy guide

Connecting fragmented systems starts with ownership, boundaries, and information flow — not with choosing an integration tool. Before any technology is selected, the operation should be able to say which system is responsible for which data, where that data enters and leaves each system, and what has to happen when a handoff fails. An integration built on unclear ownership and fuzzy boundaries moves data between systems that still do not behave like one system. What a coherent business system looks like is covered by the business-systems guide (/resources/what-business-systems-include); this guide is the implementation depth: how to design the boundaries and the information flow between the systems that already exist.

Begin with the operational flow as it runs today: the systems involved, the actors who operate them, the data that enters and leaves each system's boundary, the state transitions each record goes through, the human approvals that are part of the flow, and the external dependencies the flow touches. Draw the map in operational terms before choosing any integration shape. The purpose is not documentation for its own sake — the map is the only reliable basis for deciding which data must move, who is accountable for it, and what happens when a step fails.

Every piece of core operational data should have one system of record: the system that is authoritative for that data. Customer, order, invoice, booking, ticket, and inventory item are common examples — each belongs to one system as its source of truth, while other systems may hold a reference to it. These are illustrative categories, not a prescription for which product must own what. The decision is about accountability: when two systems disagree about an order, someone must be able to say which version wins.

A system boundary names what one system owns and what it does not. A system that owns orders does not duplicate the customer master, and a system that owns invoicing does not maintain its own private copy of the order. Unclear boundaries create synchronization problems, because every duplicated fact must be kept in agreement forever — by integration, batch, or hand — and every agreement mechanism eventually fails. A boundary is not a wall; it is a named responsibility, and the data that crosses it moves in a defined way.

There is no universal integration shape. Direct point-to-point connections work for a small number of stable links. A shared integration or service layer centralizes the contracts when several systems exchange data through the same rules. Event-driven handoff lets one system publish changes and the others react asynchronously. Scheduled or batch synchronization suits data that tolerates being aligned periodically. A controlled manual boundary is a legitimate choice when a handoff is rare, judgement-dependent, or too consequential to automate. The right shape follows the flow, the data, the timing requirements, and the failure consequences — not fashion.

An API is a contract between bounded systems: explicit inputs, explicit outputs, stable semantics, and a defined way to signal that something went wrong. Contracts should stay stable over time, change through a deliberate version or change boundary, and describe their own error semantics instead of leaving failure to chance. Authentication and authorization are part of the contract conceptually — who may call what — but the strategic point is that the contract exists, is documented, and has an owner. This is a strategy guide, not an API tutorial: the decisions that matter are naming the contract, keeping it stable, and making its failures visible.

Every integration moves data in a direction, and the direction must be explicit: which system is the source of truth for each field, how synchronization is triggered, and what happens when the same record is written in two places. Duplicate writes and eventual inconsistency are normal in real systems; what matters is that they are planned for, not discovered. Retries and idempotency keep repeated attempts safe — a step that can be retried must be harmless to run more than once. Reconciliation — comparing what the systems actually hold — is how silent drift becomes visible.

Distributed workflows fail partially: the first system accepted the change, the second did not. The strategy must decide what happens at that point before it happens. Retry with a bounded limit, make the failure visible to the people who can act on it, and route the work that cannot be completed to a place where a person resolves it — a dead-letter or manual-resolution queue is the concept, not a specific product. No silent failure is acceptable: a handoff that fails quietly corrupts both systems' picture of the truth. What was attempted, what failed, and how it was resolved should be auditable.

Integration is systems exchanging information and state; automation is workflow actions being triggered and executed with reduced manual intervention. They are different concerns that are often mixed up. A workflow can need integration without any automation — systems exchange data cleanly while people still decide and execute the next steps. And a workflow can be automated without much integration when it runs inside one system. Distinguishing the two keeps the conversation honest: the question of how these systems exchange data is answered before the question of which steps can run automatically, which the workflow-automation prioritisation guide (/resources/what-to-automate-first) covers in depth.

Custom integration development becomes necessary when the existing APIs, connectors, and configuration of the products in use cannot deliver the required contract — the data movement, the transformation, the error handling, or the timing. The response is a bounded custom integration: a small, owned layer that implements exactly the missing contract and nothing more, not a replacement system. Whether a build is justified at all is a decision the custom-software decision framework (/resources/when-custom-software-makes-sense) answers; the integration strategy only determines the boundary of the custom piece.

Uncontrolled point-to-point links that grow without design.

Business logic duplicated in several connectors, so a rule change has to be made in each place.

Circular dependencies, where system A waits on B, B on C, and C on A.

Unclear data ownership, so every system believes it owns the same record.

Hidden transformations, where data is silently reshaped between systems and nobody remembers where.

Fragile synchronous chains, where one slow or failing step blocks the whole flow.

The answer is not automatically microservices or event-driven architecture. The answer is design: named boundaries, owned contracts, and explicit failure handling — whether that is one connector or twenty.

Ambiguous exceptions that no rule can describe in advance.

Irreversible or high-consequence actions, such as releasing funds, sending external communication, or deleting records.

Conflicting records, where two systems hold different versions of the same fact and a person must decide which is correct.

Failed reconciliation, where automated comparison found a mismatch that cannot be resolved automatically.

The threshold is consequence, not volume: human checkpoints belong where being wrong is expensive, not where the system is busy.

Which system is the system of record for each piece of data that moves?

What does the receiving system actually need, and what is the minimum data that satisfies it?

When is the exchange allowed to be eventually consistent, and when must it be exact?

What happens when a handoff fails — who sees it, and who resolves it?

Can each step be retried safely, and is a repeated delivery harmless?

Who owns the contract on each side, and how are changes to it reviewed?

Which parts of the flow stay human-controlled, and why?

How is the integration monitored, and how is drift detected and reconciled?

Integration architecture succeeds when it reduces operational fragmentation: when the systems exchange the right information in the right direction, when failures are visible and resolvable, and when a person can state who owns what. Connecting tools without that structure only makes the fragmentation more efficient — the same duplicated data, the same unclear ownership, moving faster. The test of a good integration strategy is not how many systems are connected. It is whether the operation behaves more like one system afterwards.