Two systems, one version of the truth.
Systems integration is the work of making two applications agree about the same data without anybody re-typing it. In practice that means naming one source of truth for each type of record, connecting the rest through documented interfaces, and running the old process alongside the new one until the two agree every day.
Personal reply from Andrew within one business day.
What is systems integration?
Systems integration is the practice of connecting two or more applications so that a fact entered once appears, correctly and without re-typing, everywhere else the business needs it.
The symptom is always the same and it is rarely described as an integration problem. Somebody exports a file every Friday. A spreadsheet exists whose only purpose is to make two reports agree. An order is typed into the website, typed again into the accounting system, and typed a third time into whatever the warehouse runs. Nobody planned that; it accumulated, one reasonable decision at a time, and it is now a permanent tax on the week.
The first decision is not which tool to use — it is which system owns which data. Customers, products, prices, stock levels, invoices: each one needs a single system named as its owner, with everywhere else holding a copy that may be read and may not be edited. This sounds obvious and it is where most of the argument happens, because naming an owner means telling somebody their screen is no longer the place they type that number. Get it agreed before any code is written and the integration is mostly mechanical. Skip it and you have built a way for two systems to overwrite each other faster than a person could.
The second decision is the interface, and there is a clear order of preference. A documented, supported API first — OData v4, REST with JSON, a webhook that pushes rather than a poll that guesses. A scheduled file exchange second, where the vendor offers nothing better and the data can tolerate a delay. Writing directly into another product's database is last, and usually the answer is that it should not be done at all: it bypasses the validation the application performs, and it breaks silently at the vendor's next upgrade because nothing promised it would keep working.
The third decision is what happens when it fails, because it will. A network drops, a record is rejected, a vendor rate-limits an endpoint mid-run. What separates an integration you can rely on from one you cannot is whether a failed write is retried safely, whether sending the same record twice creates two invoices or one, and whether an error ends up somewhere a person will actually see it. An integration that fails silently is worse than no integration, because the business stops checking and the divergence compounds unwatched.
The Accredo-specific version of this work, including which paths Saturn supports and which it does not, is set out on Accredo API integration. For a worked example where these decisions were made in public, the field service case study covers a two-path integration and the reasoning behind splitting it.
What does an integration actually look like?
Two paths in each direction and a third that nobody thinks to ask for. The reconciliation path is the one that decides whether the other two are ever trusted.
where the work is captured
The read path is the easy half and it is where most integrations should start. Pulling reference data one way — customers, products, prices — into a system that will only display it carries almost no risk, because nothing downstream can be corrupted by a copy that cannot be edited. It is also the fastest way to find out whether the two systems agree about what a record even is, which is the question that decides everything after it.
The write path is where the care goes, and idempotency is the word that matters. If the same job is posted twice — because a retry fired, because somebody double-tapped, because a response was lost after the write succeeded — the receiving system must end up with one record, not two. That is achieved by carrying a stable reference on every write and checking for it before creating anything, so a repeat becomes a no-op instead of a duplicate invoice. Duplicate invoices are the single most common way an otherwise sound integration destroys trust in itself, and they are entirely preventable.
The reconciliation path is what nobody asks for and everybody needs. Counting both sides on a schedule and comparing the totals is unglamorous work that produces nothing visible when it is working. It is also the only thing standing between a quiet failure and a quarter-end discovery. The rule worth holding is that a difference must reach a person rather than a log file: an alert nobody has arranged to read is the same as no alert, and it is worse in one respect, because it creates the belief that the problem would have been noticed.
Which way should two systems be connected?
Four options, and the first one is doing nothing differently. For low volumes it genuinely wins, which is a sentence most integration projects would have benefited from hearing early.
| Keep re-keying | Scheduled file exchange | API integration | Retire one system | |
|---|---|---|---|---|
| What it is | A person reads one screen and types into another, on a rhythm everybody has learned. | One system exports a file on a schedule, the other imports it. Usually CSV, often over SFTP. | The two systems talk directly over a documented interface, in near real time or on a trigger. | One of the two stops being used and its job moves into the other. |
| Where it wins | Low volume, high judgement, or a process about to change anyway. | Bulk reference data, overnight batches, and vendors that offer nothing better. | Anything transactional, anything time-sensitive, anything a customer sees. | When the second system was only ever bought to work around the first. |
| What it costs | Nothing to build. A recurring slice of somebody who could be doing something else. | Modest to build. Ongoing attention when a format shifts or a file does not arrive. | The largest build cost, and the smallest running cost once it is stable. | Licence savings, against a migration and a period where nobody is comfortable. |
| How it fails | Typos, backlogs and the day the person who does it is away. | Silently. A file does not arrive, nobody notices, and the divergence dates from Tuesday. | Loudly if built well, silently if built badly. Duplicates and rate limits are the classics. | By discovering three months in that the retired system did something nobody documented. |
| What it needs from you | Nothing new. | Agreement on a format and somebody who checks the file arrived. | An agreed owner for every data type, and a vendor with a supported interface. | A full inventory of what the retiring system is actually used for, including the informal parts. |
The honest first question is whether the last column applies, because an integration between two systems that overlap by eighty per cent is often an expensive way to preserve a decision that should be revisited. The second question is volume. Ten records a week, re-keyed in four minutes, is roughly three hours a year — an integration will not repay that in the lifetime of either product, and saying so early is worth more than the work would have been.
Where an API integration does win, it wins decisively, and the reason is not speed. It is that the interface is a contract: the vendor documents it, versions it, and is expected to keep it working. A file format that two parties agreed informally has none of that protection, and a direct database write has less than none.
How does an integration get built?
Three phases in a fixed order. The middle one is the part people picture, and it is usually the shortest of the three.
Name the owner of every field
- Inventory of data types and volumes
- One owning system per type, agreed
- The exceptions people handle by hand
- What each vendor actually supports
Nothing is built in this phase. It exists because the disagreements it surfaces are cheaper to have over a table than over a live sync, and because the informal exceptions — the customer who is invoiced differently, the order type somebody rekeys deliberately — are what break a design that never heard about them.
Connect the smallest useful thing
- One data type, end to end, first
- Supported interfaces, no database writes
- Idempotent writes and safe retries
- Errors into a queue a person reads
One data type working completely is worth more than five working partly, because it proves the whole path — authentication, mapping, error handling, monitoring — against something real. Everything after the first is a variation on a route that has already been walked.
Run both until it is boring
- Parallel running, old process intact
- Both sides counted and compared daily
- Differences investigated, not explained away
- Cutover only after a quiet stretch
This is the phase that gets compressed when a project runs late, and compressing it is how an integration goes live carrying a fault nobody finds until a month-end. The old process staying available costs very little; discovering the fault after it has been switched off costs a great deal.
- Records moved without re-keyingcounted, not estimated
- Reconciliation differencesexpected: none
- Failed writes awaiting retryvisible queue
- Manual steps still remainingnamed individually
The last one is deliberately awkward. Every integration leaves some manual steps behind, and listing them by name — rather than reporting a percentage that rounds them away — is what stops a project being declared finished while somebody is still exporting a file on Fridays. No figures are published on this page, because the only honest numbers are the ones measured in your business against its own baseline.
Not sure whether the answer is an integration or a smaller change? That is exactly what the free audit is for.
Book a free process auditWhen is an integration the wrong answer?
Often enough that it is worth checking before anything is scoped. Four situations account for most of them.
The volume does not justify it. A handful of records a week, typed by somebody who is already at their desk, costs a few hours a year. An integration costs more than that to build and something to keep running. If the number is small, the right recommendation is to leave it alone and spend the budget where the week is actually going.
The two systems disagree about what a record is. If one department counts a customer per site and another counts one per account, an integration does not resolve that — it encodes it, permanently, in code that is harder to argue with than a spreadsheet was. The definition has to be settled by people first. This is the most common reason an otherwise well-built integration is quietly abandoned.
One of the systems should not exist. Where the second product was bought to work around a limitation in the first, connecting them preserves a decision worth revisiting. Sometimes the honest recommendation is a smaller custom piece that removes one system entirely, or a configuration change in the one you already own.
There is no supported way in. If a vendor offers no API, no export and no documented interface, the remaining routes are screen automation and direct database access. Both work until an upgrade, at which point they stop without warning. That is a finding to take back to the vendor or to weigh against replacing the product — not something to build a business process on top of and hope.
Questions about systems integration.
What is the difference between an API and an integration?
An API is the doorway a system offers; an integration is the thing built through it. The API is provided by the vendor and defines what can be read, what can be written and under what rules. The integration is the design decisions layered on top — which system owns which field, what happens when a write fails, how the same record is prevented from arriving twice, and how anybody finds out when it stops. A product having an API says a connection is possible. It says nothing about whether the connection you need is a week of work or a month.
Do we need middleware or an integration platform?
Sometimes, and less often than they are sold. A platform earns its subscription when there are many connections to manage, when non-technical staff need to change a mapping without a developer, or when the monitoring and retry machinery it provides would otherwise be built from scratch. For two systems and one data flow it usually adds a monthly cost and a second thing to learn, without removing any of the decisions that actually matter. The decisions do not move: something still has to own each field, handle failures and reconcile. A platform changes where that logic lives, not whether it is needed.
How do you decide which system owns a piece of data?
Ownership follows the place a record is created and corrected in the ordinary course of the work, not the place it is most convenient to look at. If sales create customers in the CRM and finance correct them in the accounting system, one of those two has to give way, and the decision belongs to the business rather than to whichever system is easier to write to. The test worth applying is simple: when the same field disagrees in two places at once, which one does everybody accept as right? That system is the owner, and everywhere else holds a read-only copy.
What happens when the integration fails overnight?
It is designed on the assumption that it will. Transient failures — a dropped connection, a rate limit, a timeout — are retried automatically with a delay, and because every write carries a stable reference that is checked before anything is created, a retry cannot produce a duplicate. Anything that cannot be resolved by retrying lands in a queue with the record and the reason attached, and that queue is somebody nominated at your end rather than a log file on a server. The failure mode being designed for is not the outage; it is the outage nobody noticed.
How long does an integration take to build?
The connection is rarely the long part. Authenticating against a documented API and moving the first record is usually the quickest phase of the project. What takes the time is agreeing which system owns what, discovering the exceptions people have been handling by hand for years, and the parallel run at the end — which is measured in weeks rather than days, because its whole purpose is to give a full cycle of the business enough time to disagree with you. Anyone quoting a duration before phase one has happened is quoting the easy third of the work.