Solution
Everything is connected to everything
Integration sprawl
Point-to-point integration is the right answer for the first few connections and a liability by the twentieth. Each one was reasonable when it was built. Together they form a landscape where no one can say what happens if a given system goes down, and where adding a system means touching many others.
The fix is not a product. It is a set of patterns, contracts, and operating rules that make connections predictable, observable, and replaceable. A purchased integration tool without those produces the same tangle inside a more expensive interface.
You are probably here because
- An integration failed, and finding where it stopped took longer than fixing it.
- Replacing one system means renegotiating its connections with every other system.
- The same data is being copied between systems, and the copies have started to disagree.
What settles it
Explicit contracts between systems
Interfaces that are versioned, documented, and owned, so a change on one side is a negotiation with a schema rather than a surprise for whoever was depending on it.
Translation at the boundary
Legacy and vendor systems keep the interface they have, and the platform absorbs the differences, so one system's constraints stop propagating into every consumer downstream.
Observability across the chain
For any message: where it came from, what happened to it, and where it stopped. Correlation across hops, so the answer does not require logging into five systems.
Defined behaviour when something is down
What happens to a message when the far side is unavailable, who is told, and how it gets through afterwards without manual repair in a database.
Start with the integration that broke most recently and the one that blocks the next system replacement. Those two usually cover the same ground, and moving them first pays for the platform before the rest of the estate is touched.
how this gets delivered
Capabilities, cases, and further reading
Delivered through
- Integration Platforms
Structured, reliable, and observable integration platforms that replace fragile point-to-point connections.
- Systems Architecture
Designing architectural foundations that allow complex organizations to operate reliably and evolve safely.
Where we have done it
- Min Beboer Parkering
Role-based parking operations with resident, controller, and admin workflows across properties.
- Vareoprettelse
Cuts the manual effort of onboarding products, and every published value can be traced back to its source.
faq
Frequently asked questions
- Do we need to buy an integration platform product?
- Not necessarily. The platform is primarily a set of patterns, contracts, and operating conventions. A product can support them, and for a large estate it usually earns its place, but a product adopted without those conventions reproduces the same point-to-point landscape inside a more expensive tool.
- Can we do this without a big-bang migration?
- Yes, and it should be incremental. New connections are built on the platform, and existing ones move in an order that takes the most fragile first. Older links retire as their systems are touched for other reasons, so no single migration carries the whole risk.
- How do we integrate with systems we cannot change?
- By translating at the boundary. The vendor or legacy system keeps its existing interface, and the platform handles the differences in format, protocol, and error behaviour, so its constraints do not spread to everything downstream.
- What about national and sector integration standards?
- In public-sector and regulated work they are design inputs from the start rather than a later conformance exercise. Retrofitting identity federation, defined exchange formats, or documentation requirements into a finished platform is considerably more expensive than designing for them.