Integration Architecture Is the ERP Decision Nobody Budgets For

Every ERP system I have worked on has integrations. Almost none of them started with an integration architecture. There is a real difference between the two, and it tends to stay invisible until the system has been running long enough for the difference to matter.

What happens instead is ordinary and, at each step, reasonable. Someone needs the CRM to talk to NetSuite, so a connection gets built. Six months later the shipping system needs order data, so another connection gets built — often by whoever has the time, sometimes touching the same records the first connection touches. A year in, there are a dozen point-to-point integrations, each one defensible on its own, none of them designed with the others in mind.

The failure mode is not a broken integration. It is an accumulated one.

Individually, these connections tend to work fine. What fails is the system they add up to. Two integrations write to the same field on different schedules, and nobody ever decided which one wins. A sync job retries on failure in a way that creates duplicate records instead of surfacing the error. An integration sized for go-live volume falls over quietly at three times that volume, and nobody notices until finance cannot close the month cleanly.

None of this shows up in a demo, and none of it shows up in testing against a handful of clean records. It shows up eighteen months in, once the business has grown into the seams nobody designed for.

Point-to-point is not the mistake. Unplanned point-to-point is.

I am not against point-to-point integration as a pattern. For two or three systems it is often the right answer, and a middleware platform can be more infrastructure than the problem actually needs. The mistake is treating each connection as its own isolated decision, with no view of how many connections the architecture will eventually have to carry.

The question worth asking early, on any implementation touching more than two or three systems: what does this look like at ten integrations, not two? If the honest answer requires a different pattern — an integration platform, a proper API layer, an event-driven approach — that is a decision to make deliberately, before the first three connections are built in a way that makes the fourth one expensive to add.

The decision that actually matters: who owns the data when systems disagree

Most integration failures I get called in to fix are not technical in the way people expect going in. The code usually runs as written. What was never decided is which system is the source of truth for which piece of data, and what should happen when two systems disagree about it.

A customer record gets updated in the CRM and in NetSuite in the same afternoon. An inventory count comes from a warehouse system and from a manual adjustment in the ERP within minutes of each other. Without a documented answer for who wins, the system develops its own answer — usually "whichever job happened to run last" — which is not a decision anyone made, and not one anyone can explain when it turns out to be wrong.

The fix is rarely more sophisticated technology. It is assigning ownership per data domain, in writing, before the integrations are built, and designing error handling that surfaces a conflict for a person to resolve instead of quietly resolving it in whatever order the jobs happen to fire.

Monitoring is part of the architecture, not an afterthought

The other gap I see consistently: integrations get built, tested against a handful of records, and shipped with no real answer to "how will we know when this breaks." A failed sync that fails silently is worse than one that fails loudly, because the loud one gets fixed the same day and the silent one gets discovered months later, usually during an audit or a customer complaint that never should have happened.

Every integration that touches the close process or customer-facing data needs its own monitoring — not a shared dashboard nobody checks, but an alert that reaches a person who can actually act on it, the same day. This is inexpensive to build in at the start and expensive to retrofit after the business has already learned not to trust the data.

Across more than 50 NetSuite implementations, the ones with the fewest integration incidents were never the ones with the most integrations, or the fewest. They were the ones where someone senior made the ownership and error-handling decisions explicit before the first connection went live, instead of letting them get made by default, one urgent request at a time.