From the blog
Connecting a new system
to the ones an organisation already runs
The hard part of integration is almost never the protocol. It is the question of who is responsible for what, and which system holds the truth.
When an organisation describes an integration project, the description usually sounds technical: "we need to pull data from the existing system". But the real difficulty surfaces later, and it is almost always one of four: who identifies the user, which system is the source of truth, what happens when the other side is unavailable, and who is responsible when something breaks.
In every case described here, making the connection itself was the short part of the project.
The four real difficulties
- Identity. A system living inside an organisation has to authenticate against what is already there — not stand up a mechanism of its own. In the FIBI Group's messaging system, that means every action taken from inside the conversation runs in the bank's systems of record, under that banker's permissions. In Sheba's appointment booking, identification runs against the hospital's patient registry and the national population registry, and only then is a one-time code sent to verify the phone — two layers, because medical information must not be exposed to someone guessing an ID number.
- The source of truth. The first question in any connection is which system holds the datum. At Sheba the appointment store is Q-Flow — so available slots are pulled from it in real time rather than kept by us. A system that keeps its own copy of a datum that is not its own produces contradictions nobody knows how to resolve.
- Availability. The other side does not always answer. A process that assumes it is always available will fail in front of the user at exactly the worst moment; a process built properly knows what to do in the meantime — hold, retry, or tell the user honestly what happened.
- Responsibility and traces. When something breaks between two systems, the first question is whose problem it is. The only answer that works is a log: what was sent, what came back, when, and under which permission. In a banking system this is taken for granted; we recommend it on every connection, including the ones where nobody asked.
And when there is no interface at all
Many older systems were never built to be connected to. This is almost never a blocker: the connection can go through the database, through files, or through a service wrapper around what exists. The route is chosen at specification — after seeing the system, not before, and not according to what is convenient for us.
What does matter is the direction: it is always better for the new system to adapt to what exists than for what exists to be changed to accommodate it. Every change forced on an old system running in production is a risk the organisation absorbs, not us.
Working with the existing system's vendor
There is almost always another vendor on the other side, and sometimes a natural tension between the two. The approach that works is simple: define the interface together, write down explicitly what each side provides and when, and do not rely on verbal understandings. That is how we worked against bank systems, a hospital and clearing providers.
The practical rule: an interface with no document is not an interface, but a temporary understanding between two people who will move on.
Not breaking what already works
A successful integration project is measured also by what did not happen. Two examples from our own systems: at Isracard, a form version that has been sent is frozen — so no future change can retroactively alter what a customer already signed. At Sheba, a new clinic or a new service goes live through configuration in the admin system rather than a software release — meaning routine change does not require touching code already running in production.
Both patterns look like technical details, but they are what lets a system keep changing for years without every change becoming an event.
Questions we get
We have an old system with no API — can you connect to it?
Almost always. The connection can go through the database, through files, or through a service wrapper around what exists. The route is chosen at specification, after seeing the system.
Do we have to replace the existing system?
In most cases no, and it is not our recommendation either. A system that runs in production and does its job is an asset; the new system connects to it. See the messaging system at the FIBI Group, built around the bank's existing systems.
How is the connection kept secure?
Minimal permissions, encrypted transport and a log for every call. A connection to a core system gets exactly what it needs — and nothing more.
And for your project
If you have a process that runs today across several systems that do not talk to each other, that is exactly our starting point. See integration between systems and enterprise development.
Let's talk about the project
Tell us which systems need connecting, and how the process works today.