Connecting two systems is a morning’s work. That is why integration keeps getting approved and keeps going badly: the first one is easy, and nothing about it warns you what the eighth will cost.
Wire systems to each other directly and the number of links grows quadratically. Every new source has to be connected to everything already there.
| Sources | Point-to-point links | Through one hub |
|---|---|---|
| 3 | 3 | 3 |
| 5 | 10 | 5 |
| 8 | 28 | 8 |
| 12 | 66 | 12 |
| 20 | 190 | 20 |
At five sources nobody notices. At twelve, half the team’s week goes to maintaining connections nobody can draw on a whiteboard, and every schema change upstream breaks something that turns out to be load-bearing.
The fix for that half of the problem is structural and well understood: land everything in one place, then work outward from there. One link per source, not one per pair.
The connections were never the expensive part
Here is the failure that actually eats months, from a real analytics team.
Two analysts are measuring player engagement. One records session duration in minutes — 30. The other records it in seconds — 1800. Both are correct. Both load cleanly. Every pipeline is green.
The dashboard averages them.
No connector failed. No type check would have caught it — both are valid numbers in a numeric column. What broke was that nobody had decided what “session duration” means, and integration made the disagreement invisible by putting two answers in the same column.
This is the shape of most integration failures. The technical layer works; the agreement layer was never built.
Four things that actually break
Units and definitions that were never agreed. Minutes versus seconds is the easy version. The hard version is “active user”, where two systems both have the field and mean different things by it. No amount of connector quality fixes this — it needs a definition written once and used everywhere.
Duplicates with no key you control. The same customer arrives from CRM, billing and support with three different identifiers and no reliable join. Deduplication is not a cleaning step here; it is a decision about which system owns identity, made before the data lands.
Schema changes nobody announced. An upstream team renames a column on a Tuesday. Nothing errors — the field arrives null, transformations keep running, dashboards keep rendering. This is why checks belong at the source boundary, not after transformation.
Sensitive data multiplying quietly. Every integration copies data somewhere new. Whatever you pull in is now in your warehouse, your backups, your clones and your development environment. The question to ask of each source is not “can we get it?” but “do we need to store it?” — and the cheapest row is still the one you never landed.
What actually helps
Land raw, then transform. One link per source into a warehouse, not a mesh of point-to-point jobs. Raw landing also means a definition change means re-running a query rather than re-pulling history — which is the whole reason ELT displaced ETL.
Write the five definitions down before the fifth source. Not a data dictionary — five rows for the numbers people argue about, with units stated. The session-duration bug costs an afternoon to prevent and a quarter to find.
Decide who owns identity. One system is the source of truth for customer identity, and everything else joins to it. Pick before you integrate; retrofitting a key across six systems is its own project.
Instrument the boundary, not the middle. Freshness, schema and volume checks on what arrives, owned by a named person, with a stated consequence.
The takeaway
Integration projects are not usually approved on the second source. They are approved on the eighth, when somebody notices that half the team maintains connections and no two dashboards agree.
The structural half of that is arithmetic, and a hub solves it. The other half is not technical at all: it is the small number of definitions everybody assumed were shared, and finding out they were not only after two of them ended up averaged in the same column.
That is how Datablast approaches it — one governed path per source into a warehouse, definitions in version control rather than in each team’s head, and quality checks at the boundary where a silent change still costs something to find.
Originally published on datablast.io in August 2023. Rewritten September 2026.
See it on your own data
20 minutes, your questions, a live walkthrough.