Which system is right when they disagree about the same customer?
System Integration: Building One Source of Truth
Most operational pain that looks like a people problem is a data problem wearing a disguise. When the CRM, the accounting system, the store and the spreadsheet each hold a partial version of the same customer, nobody is wrong and nobody is right — and every report built on top of them is a negotiation.
"Single source of truth" is a decision, not a product
You do not buy one. You decide, field by field, which system owns each piece of information — and then make every other system read that owner rather than keep its own copy. The customer's phone number is owned by one system. Stock levels are owned by one system. Invoice status is owned by one system. Ownership can be split across different systems; what it cannot be is shared.
Two systems that both believe they own the customer's address will diverge. Not might — will.
Writing the ownership map down is the hardest hour of an integration project and the one that determines everything after it. It is also the artefact most teams skip, which is why so many integrations degrade into a mesh of scripts nobody can reason about.
Three ways systems get connected, in order of durability
- Manual re-entry. A person is the integration. Cheap on day one, and the source of every symptom in this article.
- Scheduled synchronisation. A job copies records between systems every few minutes or hours. Simple, and adequate where a short lag is harmless — stock counts, nightly reporting.
- Event-driven integration. A change publishes an event and interested systems react. More work up front, and the only approach that holds when the order of operations matters: payment confirmed, then stock reserved, then delivery booked.
Most operations need a mix, and choosing per data flow rather than per project is what keeps the result proportionate. A nightly sync for the product catalogue and an event for payment confirmation is a perfectly good architecture; forcing both into the same mechanism is not.
What breaks, and what to do about it
- The other side goes down. Assume it will. Every outbound call needs a retry with backoff and a queue that survives a restart, or you lose the order that arrived during the outage.
- The same event arrives twice. Networks retry. Every consumer must be safe to run twice on the same message, or you will ship two deliveries for one order.
- Records that do not match. The same customer as "Ahmed M." and "احمد محمد" with different phone formats. Decide the matching rule deliberately and keep the ones it cannot resolve in a review queue instead of guessing.
- Silent drift. The integration keeps running while quietly dropping a field the other side renamed. Reconcile counts on a schedule and alert on the difference — a broken integration that nobody notices is worse than one that fails loudly.
How to sequence it
- Inventory the systems and the flows. Not the software list — the list of facts that cross between them, and in which direction.
- Write the ownership map. One owner per field. Disagreements here are business decisions, not technical ones, so settle them with the people who live with the consequences.
- Connect the pair that disagrees most. One flow, done properly, with retries, idempotency and reconciliation. It proves the pattern.
- Then extend, reusing the same pattern. Each subsequent flow should be cheaper than the last. If it is not, the pattern is wrong — stop and fix it before adding the third.
Done in this order, integration is the least glamorous and highest-leverage work available to most operations. Every automation, dashboard and AI assistant you build afterwards rests on it — and none of them can be better than the data underneath.