One data model beats eleven integrations

Integration is not a feature. It is the tax you pay for having split the data in the first place, and every euro spent on connectors is a euro spent undoing a decision somebody made years ago when buying software by department seemed obvious. The alternative is not a better integration platform. It is not needing one.

How the split happened

Nobody chose fragmentation. It arrived one sensible purchase at a time.

Finance bought the ERP because it was the best ERP. Sales bought the CRM for the same reason. The warehouse bought a WMS that understood picking. Each decision was locally correct, and each one carved off a piece of the same underlying reality — an order, a customer, a product — into a private schema with a private update cycle.

The company then hired people, or a platform, to stitch those pieces back together overnight. That stitching is now a permanent cost centre that produces no product and cannot ever be finished, because it exists to compensate for a structural decision rather than to solve a problem.

What it actually costs

The licence for the integration platform is the smallest part.

Latency. The join happens on a schedule. Between runs, the company operates on a picture that is hours old, and every decision made in that window is made against stale state.

Ambiguity. Three systems hold a customer. Two disagree. There is a documented rule about which one wins, and there are four undocumented exceptions that live in one person’s memory.

Lost context. The reason two records belong together — that this credit note relates to that damaged pallet — is usually not in either system. It is in an email. When you export the data, the facts survive and the meaning does not.

A ceiling on automation. This is the expensive one. Anything you might want an agent to do that crosses two domains requires the agent to resolve the same ambiguity a human resolves, without the institutional memory a human has. Most agent projects die here, and the post-mortem blames the model.

What changes with one model

When the order exists once and everything else references it, several problems stop being problems rather than getting easier.

There is no reconciliation window, because there is nothing to reconcile. There is no question about which system is authoritative. Context — the note, the exception, the reason — attaches to the record itself instead of living in a mailbox. And an agent asking a question that spans finance, stock and delivery is asking one question of one model, not orchestrating three imperfect APIs and guessing at the joins.

That last point is what makes an AI-native system feel different in use. The gain is not that the model is cleverer. It is that the question is answerable at all.

The objection, and the honest answer

“One model for everything” sounds like a monolith, and monoliths have a deserved reputation. The objection is fair and the answer is architectural: one model does not mean one lump of software.

The model is the shared vocabulary — entities, relations and events. Behaviour stays modular: replaceable components for warehouse logic, for pricing, for compliance, each reading and writing the same entities rather than owning private copies. You compose functionality without re-fragmenting the truth. That is the difference between a monolith and a platform, and it is entirely about where the boundary is drawn.

Where to start if you already have eleven

You do not begin by migrating. You begin by building the model above what exists, read-only, and letting it prove it can answer questions the individual systems cannot.

Then processes move one at a time, in the order of how much pain their current joins cause. Most companies find the first two moves pay for the rest — usually order-to-cash, and whatever the warehouse currently reconciles by hand.