TECHNOLOGY SERVICE · 08
Systems Integration
Connecting the systems your organisation already depends on, so data moves once and arrives correctly. For teams re-keying the same order into three applications, and for anyone whose nightly batch has become a nightly risk.
Agree the system of record first
Almost every integration failure traces back to two systems each believing they own the same field. Before any connector is written, we settle which system owns each entity, who may create it, who may only read it, and what happens when the two disagree. That agreement is written down and signed off by the business owners, not just the technical team.
- Ownership matrix per entity and field
- Agreed identifiers and cross-reference strategy
- Rules for reconciling conflicting updates
Events over nightly batches
Batch jobs push problems to the worst possible hour and hide them until the morning. Where source systems allow it, changes are published as events and consumed as they happen, which shortens the gap between an action and its consequence elsewhere. Older systems that offer only a file drop or a database view are wrapped rather than rewritten, so the rest of the estate still sees a modern interface.
Failure handling is the feature
Integrations spend most of their life in partial failure: a timeout, a duplicate, a malformed record from an upstream release. Idempotent handlers, retries with backoff, dead-letter queues and a replay tool are built in from the start, so a bad afternoon becomes a replay instead of a data recovery project.
Reconciliation reports run daily and compare counts and totals across both sides, because silent divergence is the expensive kind.
The endpoints that matter locally
Regional work brings its own list: UAE PASS for identity, local payment gateways and acquirers, VAT and e-invoicing obligations, customs and logistics portals, and the ERP instance that was customised heavily in 2016. Our engineers have worked across these categories and plan for their quirks, including the approval lead times that sit outside anyone's sprint.
What you get
- Integration map showing systems, direction of flow and ownership
- System-of-record matrix agreed by the business owners
- Deployed integration services with retries, dead-letter queues and replay
- Daily reconciliation reports across both sides of each interface
- Monitoring and alerting on lag, failure rate and queue depth
- Interface specifications and error catalogue for each connection
- Cutover plan covering dual running and back-out
- Runbook for the team that will support it
Typical outcomes
150+
Integrations supported across our engagements
Near real time
Replacing overnight batch on most interfaces
<0.1%
Target message failure rate after stabilisation
Stack we use
Questions
Usually yes, though the customisations decide the approach. Where a supported API exists we use it; where it does not, a controlled extraction layer keeps the integration off the customised internals so upgrades stay possible.
Not always. Smaller estates run well on a message broker and a handful of services you own outright, and a commercial platform earns its licence once you are managing dozens of interfaces with several teams.
Contract tests run against each interface and fail loudly when a payload shape changes. Combined with dead-letter queues and replay, a surprise release upstream becomes an alert and a reprocess rather than lost records.
Yes, and the technical work is usually the shorter part. Onboarding and approvals with those providers sit with your organisation, so we plan the timeline around their lead times rather than around ours.
Related
Next step
Start with a 20-minute call.
Tell us the roles you need filled, the system you need built, or both. You will speak to someone who has done the work, and leave the call with a route forward.