For platforms that each keep their own version of events
System Integration
Every platform in a business tends to arrive with its own idea of the truth, and the gap between them usually gets patched with someone's afternoon spent reconciling spreadsheets. This practice builds the contracts that close that gap: synchronization rules, a shared middleware layer, and a defined answer for what happens when a connected system goes down.
How the contract between two systems gets designed here
Source-of-truth rules, middleware routing and failure-mode planning.
90 secSample frame · video pending01Before wiring two systems together
Point-to-point or middleware is a real decision
Teams often default to a direct connection because it is the fastest thing to ship today. Four questions settle whether that will still hold up in a year.
How many systems will eventually need to connect?
Two systems tolerate a direct connection fine. A third or fourth system usually signals it is time for a shared middleware layer instead.
How costly is stale or conflicting data?
Low-stakes data tolerates occasional drift. Financial or customer records rarely do, and deserve a stricter synchronization contract.
What happens today when one side is unavailable?
If the honest answer is nobody knows, failure-mode design belongs in scope from the very first integration, not added later.
Who owns each field when systems disagree?
Without a named owner per field, every future sync conflict becomes a fresh argument instead of a defined resolution.
| Point-to-point | Middleware layer | |
|---|---|---|
| Best fit | Two systems, stable requirements | Three or more systems, growing needs |
| Visibility | Scattered across connections | Centralised in one place |
| Change cost | Low at first, rises with each addition | Higher upfront, lower per addition |
| Failure handling | Often ad hoc | Designed once, applied everywhere |
02Agreed before the first contract is written
The ledger that keeps the integration honest
Integration work drifts when ownership of a shared field is assumed rather than agreed. This ledger fixes what you bring, what we design, what returns, and what stays your call to make.
- Your side
You bring
- The two or more systems holding the record in question
- Whichever one is treated as the source of truth today, if any
- Business rules for what should happen when the records disagree
- Our side
We build
- A synchronization contract naming the source of truth per field
- A data pipeline keeping both systems current on an agreed cadence
- Conflict-handling rules for the cases where records genuinely disagree
- Your side
You receive
- Two systems that agree without manual reconciliation
- A written contract naming which system owns which field
- Monitoring that flags a sync failure before anyone else notices
Never leaves you
- Both systems and every decision made inside them
- The business rules the synchronization contract encodes
- The choice of which system leads for any given field
Where the line sitsSynchronization only works once a source of truth is named per field. Ambiguity here is the actual cause of every sync failure that follows.
03From mapping to monitored production traffic
Four stages, each closing on evidence
Integrations that fail quietly usually skipped one of these stages. This system closes each one with something you can verify directly.
Map the systems and their records
Every connected system, the records it holds and where those records currently disagree get documented before any contract is written.
Every system and its version of the truthDesign the synchronization contract
A source of truth is named per field, along with the cadence and conflict rules for keeping systems aligned going forward.
Ownership named per field, not assumedDesign for the outage, not just the happy path
Retry logic, queueing and alerting are built for every integration point before it goes live, not added after the first outage.
Failure planned for, not discovered laterShip with monitoring already watching
Sync health and failure alerts are live from day one, so a broken connection is caught by a dashboard, not a support ticket.
Visibility from the first day of traffic
04What actually moves the number
Four drivers, priced from the mapping stage
Integration work is priced against the mapping exercise, because these four factors change scope by multiples.
Number of systems in the integration
Two systems connect more simply than five, and each additional system adds its own contract and failure mode to design.
How strict the data consistency requirement is
Near-instant consistency for financial data costs more to build than an overnight batch sync for less time-sensitive records.
Existing platform APIs and their limitations
A well-documented, capable API costs less to integrate against than one with rate limits or gaps that need working around.
Depth of failure-mode coverage required
A basic retry mechanism costs less than full queueing, alerting and manual-recovery tooling for a business-critical integration.
05Evidence and proof
Systems that finally agree with each other.
Integration proof is a record that matches everywhere it appears and an outage that gets caught immediately. Every record here waits for written client approval before production.
Explore case studiesA CRM and an ERP reconciled without a single manual spreadsheet.
Aster North had sales and finance teams reconciling customer records by hand every week. A synchronization contract named a source of truth per field and ended the manual process.
- Manual reconciliation hours removed
- Weekly, down to zero
- Fields with a named source of truth
- All of them
A middleware layer replaced eleven direct connections between four systems.
Nexa Foundry had four platforms wired directly to each other in a tangle nobody fully understood. A middleware layer replaced the direct connections with documented, versioned contracts.
- Direct connections replaced
- 11
- Systems now routed through one hub
- 4
An outage used to mean days of quietly broken data. Now we get an alert the moment it happens.
Sample · pending client approval
06Read this first
When formal integration work is the wrong move
Designing a full synchronization contract for two systems that rarely share data is more engineering than the problem needs. The exits are marked plainly.
- API Development
You are exposing your own system, not connecting others
Publishing an API for your own platform to external consumers is a different practice from integrating existing systems together.
- Salesforce Consulting
The issue is inside one platform, not between platforms
Broken automation within a single Salesforce or ServiceNow instance is a platform configuration issue, not an integration one.
- Digital Transformation Consulting
The integration is one piece of a bigger sequencing question
When several systems need attention and priority is unclear, a transformation roadmap should come before any integration build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Two-system sync | One clear pair of systems needs to agree | Which system leads for each field | Contract design and delivery |
| Middleware build | Three or more systems need a shared hub | Which systems join and in what order | The layer, its contracts and monitoring |
| Integration into support | The connection needs care after go-live | Ongoing business priorities | Delivery, then ongoing reliability support |
07Straight answers
Asked before an integration budget is approved.
01How is this different from API development?
API development exposes one system's own contract to outside consumers. This practice connects existing systems together, so records created in one place stay accurate in the others.
02Do you work with an existing integration platform we already use?
Yes, an existing iPaaS or middleware tool is often the right foundation to build on rather than replace. The mapping stage decides whether to extend it or introduce something new.
03What happens to our data if one of the connected systems goes down?
That is exactly what failure-mode design answers before it happens. Queueing and retry logic hold data until the system recovers, rather than losing it silently.
04How do you decide which system is the source of truth?
Business rules decide it, not technical convenience. The mapping stage identifies who actually owns each piece of data and names that system as the source for that field.
05What does system integration cost?
It is priced against the number of systems, the strictness of data consistency required and the depth of failure handling, all sized during the mapping stage before commitment.
06Can you integrate systems from different vendors, like Salesforce and SAP?
Yes, this is one of the more common patterns. The contract design stage does not assume any particular vendor pairing and works from each system's actual API capability.
07How long does a typical integration project take?
A two-system synchronization contract can close within a few weeks. A middleware layer connecting several systems runs longer, scoped during the mapping stage.
08Do you monitor the integration after it goes live?
Monitoring for sync health and failure alerts is part of every engagement from day one, and ongoing reliability support can continue after launch by separate agreement.