Integrations look like technical projects. Two systems, an API, some mapping, a sync schedule. The work is engineering. The deliverable is a connection.
This framing is wrong, and the consequences are visible in every organisation that has built integrations without first answering a different set of questions. Who owns this entity? Who is allowed to change it? What happens downstream when they do?
These are not technical questions. They are organisational ones. An integration that proceeds without answering them is not connecting systems. It is connecting assumptions — and propagating the consequences of those assumptions across the business at machine speed.
Free · 4 minutes
When two of your systems disagree, do you know which one to believe?
Fourteen questions on ownership, lineage, and quality — the difference between a number on a dashboard and a number you could defend. Banded finding on screen, full sheet by email.
A simple integration that is not simple
Consider a common pattern: a contact record synchronised between a CRM and a bookkeeping system.
The technical task is straightforward. Map the fields, schedule the sync, handle the error states. A developer can complete the work in days.
The organisational task is much larger.
Who keeps the contact record up to date — the sales team using the CRM, or the accounts team using the bookkeeping system? Both have legitimate reasons to update it. Sales because the relationship is theirs. Accounts because the invoice goes to that contact.
What happens in the CRM when the contact is attached to a company? The relationship is between a person and an account. Are you billing the person or the account? The CRM and the bookkeeping system structure this relationship differently. The integration has to choose. Whichever it chooses, it has imposed an organisational model that nobody in the business explicitly approved.
What happens when that contact leaves and joins a competitor? Sales updates the CRM because they are managing the new relationship. The integration propagates the change. The invoice that was about to be sent to the original company now references someone who has no relationship with that company anymore — and may, depending on the system design, no longer be visible at the right account.
None of these outcomes are integration failures. The integration is working exactly as built. The failures are the absence of organisational decisions that should have been made before any code was written.
The paperwork that reveals the problem
In organisations where this conversation has been deferred, the symptoms are visible in the process layer.
Changing a customer record requires a form. A sign-off. A sequence that nobody can remember without consulting documentation. The changes that should be routine — a phone number, an email address, a billing contact — have accreted layers of bureaucracy because the organisation discovered, somewhere along the way, that uncontrolled changes had consequences.
The forms are not a solution. They are a mitigation. They exist because the structural question — who owns this entity, what propagates when it changes — was never answered. The organisation responded by inserting friction at the point of change, hoping the friction would prevent the worst mistakes.
It does not. The changes happen anyway. Sometimes through the official process. Sometimes around it. The forms create the appearance of governance while the underlying problem remains unresolved.
When this paperwork exists, it is evidence. The integration is connecting systems whose ownership boundaries were never made explicit.
What integration actually connects
An integration does not connect systems. It connects the teams, processes, and authorities that use those systems.
When the contact record syncs from CRM to bookkeeping, it is not just moving data. It is establishing — implicitly and without consultation — that sales has the authority to change a record that the accounts team relies on for invoicing. Or vice versa, depending on the direction. Or both, if the sync is bidirectional, in which case the question of authority is genuinely unresolved.
The integration has made an organisational decision. Whether the organisation noticed or not.
The same pattern applies at every integration point. A product sync between PIM and ecommerce establishes who owns the product definition. An order sync between ecommerce and ERP establishes whose system is authoritative for the order state. A customer sync between CRM and support establishes whether sales or support owns the relationship record.
Every one of these decisions has commercial consequences. Every one is made implicitly when the integration is built without the organisational conversation.
What the conversation looks like
The conversation is short. It is also uncomfortable, which is why it is often skipped.
For each entity that crosses systems, the questions are:
Who owns this entity? Not which system holds it — which team has authority over it. The system is downstream of the ownership decision.
Who is allowed to change it? Read access is the easy answer. Write access is where the conflict lives. If two teams can both change the same record, the integration is going to propagate disagreement.
What propagates, and when? Not every field needs to sync in real time. Some changes should propagate immediately. Some should require approval. Some should not propagate at all because the downstream system needs a different value for legitimate operational reasons.
What happens in edge cases? The contact who changes employer. The product that is renamed. The customer that becomes a different legal entity. These are not exceptions to plan for later — they are tests of whether the ownership model holds under pressure.
An integration built after this conversation is much smaller than an integration built before it. Most of the engineering complexity in real-world integrations is dedicated to handling the consequences of organisational decisions that were never made.
A few rules
Before the integration is designed, name the owner. For every entity that crosses systems, one team owns it. The system is a tool. The ownership decision is the architecture.
Bidirectional sync is a red flag. If both systems can update the same field, the ownership question has not been answered. The technical work to handle conflicts is real, and it is usually compensating for an organisational decision that should have been made instead.
The integration encodes the org chart. What syncs, in which direction, with what authority — these reflect organisational structure. If the structure is unclear, the integration will be unclear. Fix the structure first.
Paperwork around routine changes is a diagnostic. When changing a customer record requires forms and approvals, the underlying ownership model has gaps. The forms are not the solution. They are the symptom.
Plan for the edge cases that test the model. The contact who switches employers. The account that is acquired. The product that is reclassified. These are the moments when the implicit decisions become explicit. Make them explicit at design time.
Richard King is CTO at Sixteen Pillars — technical leadership, architecture, and governance for organisations that need it without the overhead of a full-time hire.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.