Use case
Your tools work. They just do not talk to each other enough.
Each system does its own job correctly. The problem shows up between them: the same data is entered twice, a CSV export serves as an interface, and when two tools show different figures nobody knows which is right.
You may recognise some of this
These symptoms rarely point at a single tool. They appear at the joins.
- The same client or product data is entered into several applications.
- CSV exports and imports serve as a regular exchange mechanism.
- Someone runs a manual sync on a fixed schedule, and has to remember to.
- Some tools have no API, or one that does not cover what you need.
- Two systems show different information and the conversation turns into who is right.
- A change in one system breaks a job in another, discovered after the fact.
- Connectors were built years ago and nobody knows precisely what they carry.
What happens if nothing is done
The cost of manual exchanges is spread across many people, which makes it hard to see.
- Decisions get made on contested numbers
- When two systems diverge, the meeting starts with a debate about the source before anyone discusses the substance. That is a recurring cost, rarely attributed to the right place.
- Manual exchanges fail silently
- An import that did not run tells nobody. The gap surfaces later, often through a client or a month-end close.
- Every new tool makes it worse
- Without exchange rules, adding an application multiplies point-to-point links. Complexity grows faster than the number of tools.
- The estate becomes rigid
- When everything is coupled to everything, replacing or upgrading one application means touching several others. Change eventually gets postponed for that reason alone.
Connecting does not mean coupling everything
Good integration reduces dependencies instead of multiplying them. Several exchange methods exist, and they are not interchangeable.
| Connecting does not mean coupling everything | When it fits | What you have to accept |
|---|---|---|
| Direct API call | The need is one-off and synchronous: you ask for information at the moment you need it and wait for the answer. | The called system has to be available. If it is not, the caller must know what to do — retry, degrade, or refuse cleanly. |
| Events | Several systems have to react to the same business fact — an order confirmed, a client created — without the emitter having to know them. | Accepting a short delay, and designing handlers that can receive the same event twice without harm. |
| Middleware or an exchange bus | The number of links becomes unmanageable point to point, or formats have to be translated between several systems. | One more component to operate and monitor. It is justified by the number of flows, not by architectural principle. |
| Batch synchronisation | The volume is significant and freshness is not critical: a daily or hourly reconciliation is enough. | Planning the catch-up after a failure, and being able to say at any moment when the last batch actually completed. |
| Framed import and export | The remote tool offers nothing else, or the exchange involves an external partner who imposes their format. | The file becomes an interface like any other: documented format, validation on arrival, acknowledgement, and a path for rejects. |
| Wrapping a legacy system | The software exposes nothing usable and cannot be modified in the short term. | Building a façade in front of it rather than letting every tool reach into its database. That is also what will make replacing it possible later. |
One piece of data, one source of truth
What matters is not the number of links, it is knowing which system is authoritative for which data — and through which channel the others find out.
System of record
The system that holds the authoritative version for a given domain: the client, the product, the order. There is one per domain, and it is not necessarily the same one for all of them.
- CRMEvents
- ERPAPI
- Client portalAPI
- Mobile appAPI
- External partnerFramed files
- Reporting & BIBatch
The same tool can be authoritative on one domain and a plain consumer on another. It is the data that has an owner, not the application.
How we approach it
We start by establishing what actually moves today, which is almost always more than what is documented.
- 01
Map the current exchanges
Which flows exist, between which systems, how often, carried by whom. Manual exchanges and the script someone runs each morning included.
- 02
Identify the sources of truth
For each important piece of data, which system is authoritative. That is an organisational decision as much as a technical one, and it gets settled explicitly.
- 03
Define the contracts and responsibilities
What is exchanged, in which format, how often, and who is responsible when there is a gap. A written contract is what lets one system evolve without breaking the others.
- 04
Handle errors, retries and monitoring
What happens when a system does not answer, when a message arrives twice, when a batch fails. These cases get designed before go-live, not after the first incident.
- 05
Migrate progressively
One flow at a time, with the old mechanism kept in parallel long enough to compare results. The gaps found during that period are often instructive.
- 06
Observe the flows in operation
Volumes, delays, rejects, queues. An integration that is not observed becomes a black box again within months.
Which application is authoritative?
This is the question that unblocks most integration projects, and it is not a technical one.
One owner per piece of data, not per application
The CRM can be authoritative on a client’s contact details while the ERP is authoritative on their outstanding balance. Splitting by data rather than by tool avoids territorial arguments.
The other systems hold a copy
A local copy is legitimate: it makes a system autonomous and fast. What is not legitimate is modifying it where it is not meant to be authoritative.
A gap must be visible, not absorbed
When two systems diverge, the right behaviour is to flag it, not to silently pick one. A detected gap is an incident; a hidden one is a loss of trust.
The decision gets written down
A short list — which data, which system is authoritative, who arbitrates a conflict — is worth more than any architecture diagram for the rest of the project.
What this can look like
Depending on the tools in place and what they allow, integration takes various shapes.
- A stable API in front of a system that exposed none
- Replacing a daily CSV export with a verifiable synchronisation
- An event mechanism so several tools can react without knowing each other
- A written list of sources of truth, agreed with the business owners
- Flow monitoring with an alert when a job did not complete
- Progressive replacement of a legacy connector, old and new running in parallel
These describe possible shapes of a solution, not delivered projects presented as references.
This path may draw on
Framing the exchanges is analysis work; building and operating the flows is the other two.
Frequently asked questions
What if a piece of software has no API?
Several options exist depending on the software: read access to a database, scheduled exports, sometimes an automatable application interface. In all cases we build a façade in front of it rather than letting each tool connect directly — that is what will make replacing it possible later without breaking everything.
Do we need middleware?
Not by default. Middleware is justified when the number of links becomes unmanageable point to point, or when formats have to be translated between several systems. With three or four applications and simple exchanges, it mostly adds another component to operate.
How do we avoid duplicate data?
By designating a source of truth per piece of data and making sure the other systems do not write to it. Duplicates almost always appear because two tools each believe they own the same information. Automatic detection helps, but it treats the symptom.
What happens when a system is unavailable?
That is a case to design for, not an incident to suffer. Depending on the exchange method: queue and automatic retry, degraded operation on local data, or an explicit refusal with a clear message. What has to be avoided is an outage passing unnoticed and leaving two systems out of step.
Can an existing integration be replaced progressively?
Yes, and that is usually the right method. The old mechanism keeps running while the new one is put into service, and the results get compared for a period. The gaps found often reveal business rules nobody had documented.
Let us talk about your exchanges
Tell us which tools need to talk and what is getting in the way. A quick map is often enough to see where the real knot is.