Services
We build the layer between systems that were never designed to speak to each other: APIs over systems that do not have one, event pipelines between applications that only knew how to export files, and synchronisation with defined ownership for records that exist in three places at once.
The measure of this work is not that data moves. It is that you can prove, on any given morning, that it moved correctly and know within minutes when it did not.
When you need this
What we build
Our approach
We start from evidence: scheduled task lists, database links, service accounts, firewall rules and file drop locations. The undocumented interfaces — the FTP job someone set up in 2016, the shared mailbox that a macro reads — are the ones that break, and they are never on the architecture diagram.
Choosing a queue technology is the easy part. The decision that determines whether the integration works is which system owns each field and what happens when two of them change it in the same hour. We produce that matrix, walk the business through the conflict cases, and get it agreed before writing adapters.
Not everything needs to be real time, and pretending it does adds cost and failure modes. Customer-facing state changes are event-driven; reference data and reporting extracts stay on a schedule. Each integration has a stated latency target, and we design to that target rather than to a fashion.
Every adapter is built assuming the far end will be unavailable, slow, or will return something that violates its own specification. Retries, backoff, circuit breakers, poison-message quarantine and idempotency keys are in the first version, not added after the first incident. Duplicate delivery is treated as certain, not unlikely.
An integration is not accepted until you can answer three questions from a dashboard: is it running, is it in sync, and where did this specific record go. Correlation IDs, per-hop timing, drift figures per entity and alert routing to a named owner are part of the definition of done.
Technology
Integration and messaging
Services
Interfaces
Operations
Applied by industry
HL7 v2 and FHIR UK Core interfaces between clinical systems, patient-facing services and reporting, with EMIS Web, SystmOne and Dentally as sources and strict minimisation of what leaves the clinical estate.
Elexon data flow ingestion, supplier API integration and settlement reconciliation, with exception queues that replace the analyst spreadsheets currently absorbing mismatches.
EPOS, PMS, payment and stock integration across sites, giving one reconciled sales and margin figure per day instead of five exports that disagree.
Property and applicant synchronisation between Reapit or Alto and the Rightmove and Zoopla feeds, with a single owner per field so listings stop diverging from the source record.
Practice management, time recording, Xero or Sage and document systems connected so matter, time and billing agree without a monthly manual reconciliation.
Typical engagement
Questions
Sometimes. For a large estate with many endpoints and a dedicated integration team, a platform earns its licence. For most organisations connecting a dozen systems, a purpose-built layer on your existing cloud services costs less to run and far less to change, and does not add a vendor to your critical path. We assess both and show the five-year cost of each.
The integration layer is designed for that as the normal case: retries with exponential backoff, circuit breakers, idempotent message handling, dead-letter queues and alerting with a named owner. The business-visible behaviour under failure is agreed during design, so a supplier outage degrades one function rather than stopping the operation.
In descending order of preference: a supported API, a documented database view or replica, a scheduled file exchange with checksums, then screen or report scraping as a last resort with an explicit note that it is fragile. We state which mechanism each integration uses and what would break it, so the risk is visible rather than buried.
One system per field, agreed and written down before build. The mapping document records the owning system, the permitted readers, the update direction and the conflict rule for every material field. Disagreements about that table are far cheaper to resolve on paper than in production data.
Reconciliation is part of the build, not an operational hope. Scheduled jobs compare record counts and checksums between systems, a dashboard shows drift by entity, and thresholds raise alerts. Every message carries a correlation ID so a single record can be traced end to end through the pipeline.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us