Every enterprise retailer has a version of the same integration story. The OMS went in five years ago. The WMS was added two years later from a different vendor. The storefront migrated platforms three years ago and needed to connect to both. Each connection was built as a point-to-point integration by whoever was available at the time. The developer who built the OMS-to-WMS connector left the company. The storefront connector was documented once and the documentation is now out of date.
Today the integration layer is a mix of scheduled batch jobs, SFTP file transfers, some REST API calls, and a small number of webhooks. Nobody has a complete map of it. When something breaks, the debugging process involves reading code that nobody currently on the team wrote, tracing event flows across systems that log in incompatible formats, and hoping the failure generated an error message that is specific enough to be useful.
This is not a failure of the teams that built these integrations. It is a predictable outcome of building point-to-point connections incrementally over time without a shared integration architecture to govern them.
Why Point-to-Point Integrations Accumulate Technical Debt
A point-to-point integration between System A and System B is not inherently bad. It is the right solution for a small system with stable requirements. The problems emerge when you have a growing number of systems that each need to communicate with multiple others, and when those systems evolve independently.
The maintenance burden grows quadratically. Two systems require one integration. Three systems require three integrations. Five systems require ten integrations. At seven systems, you have 21 potential point-to-point connections to maintain. Each connection has its own authentication scheme, its own error handling, its own retry logic, and its own monitoring requirements. The time spent maintaining integrations starts to compete seriously with the time available to build product features.
The failure mode is also difficult to monitor because each point-to-point connection has its own failure characteristics. A batch job that fails silently is a different failure than a webhook that starts returning 429s is different again from an API call that times out. There is no single place to look to understand the health of the overall data flow between your systems.
The Canonical Architecture That Survives Growth
The integration pattern that holds up at enterprise scale is a hub-and-spoke model with a dedicated integration layer in the center. Instead of System A talking directly to System B and System C, System A sends events to the integration layer. The integration layer routes those events to the appropriate downstream systems, handles translation between data formats, manages retry logic, and maintains an audit log of what was processed and when.
Each spoke system connects to the hub once, with a well-defined contract: this system produces these event types with this schema, and consumes these event types with this schema. Adding a new system to the network requires building one new spoke, not one connection to every existing system. Removing a system requires disconnecting one spoke, not hunting through multiple point-to-point connections for all the places that system is referenced.
This architecture also makes failure monitoring tractable. The integration layer is the single source of truth for event flow health. An event that was published but not consumed shows up as a single entry in the integration layer's audit log. A system that has stopped consuming events shows up as growing lag on its subscription. You do not need to check each system pair independently to understand the state of your integrations.
What Changes for OMS-WMS-Storefront Specifically
The OMS, WMS, and storefront triad is where integration problems are most operationally consequential. An inventory update that does not reach the storefront results in an oversell. An order that does not reach the WMS results in a fulfillment delay that looks like a pick error. A shipment confirmation that does not reach the storefront results in a customer who still sees "processing" long after their order has shipped.
In a hub-and-spoke model, the storefront subscribes to inventory update events. The WMS publishes those events whenever stock levels change. The integration layer delivers them to the storefront. If the storefront is temporarily unavailable, the integration layer queues the events and delivers them when the storefront reconnects. The oversell protection is now a function of event delivery latency and the integration layer's queue management, not a function of whether a direct API call between WMS and storefront succeeded.
The same pattern handles order flow. The OMS publishes an order created event. The WMS subscribes to order created events and begins fulfillment. The WMS publishes a shipment confirmed event. The OMS and storefront both subscribe to that event and update order status accordingly. The integration layer manages delivery and handles retries if any subscriber is temporarily unavailable.
What changes in practice is not just the data flow, but also who owns the integration contracts. In a point-to-point world, the integration contract between OMS and WMS is implicit, embedded in the code that connects them. In a hub-and-spoke world, the event schemas are explicit, versioned, and documented in the integration layer. When the OMS needs to publish a new field on the order created event, that change is published as a schema update with a version number, and downstream subscribers can choose when to consume the new field. This is how systems evolve without breaking each other.
The Migration Question
The honest challenge with moving to a hub-and-spoke integration architecture is that you typically cannot do it all at once. You have existing point-to-point integrations that are running today and cannot be taken down for a migration. The path from current state to target state has to be incremental.
The practical migration sequence: start with the most fragile connection, the one that breaks most often or costs the most time to debug. Build the hub-and-spoke equivalent. Run both the old and new integrations in parallel until you have confidence that the new one is reliable. Then decommission the old one. Repeat for the next most fragile connection.
This approach means you will have a hybrid architecture for a period of time, which introduces its own complexity. But the alternative, a big-bang migration of all integrations simultaneously, carries a risk profile that most operations teams cannot accept. The incremental path is slower but safer.
We want to be clear that this migration approach has a real cost in engineering time and operational attention. It is not a quick project. The payoff is a system that is significantly easier to maintain and extend over the following years. Whether that payoff justifies the investment depends on how much the current integration problems are actually costing you, which is a calculation specific to your situation.
Connector Quality and the Long-Tail Problem
A common objection to hub-and-spoke integration architectures is that building spokes for all the systems you need to connect takes significant time. This is true, and it points to the value of pre-built connectors for common commerce systems.
OMS and WMS platforms in enterprise retail are not infinitely varied. A handful of platforms cover a large share of the market. A connector library for the most common platforms reduces the spoke-building effort from weeks of custom development to days of configuration. The custom engineering work concentrates in the long-tail cases: the niche system that your operation runs for a specific function and that has no pre-built connector available.
The long-tail cases are real, and they require real engineering effort. But separating the common-platform connectors from the custom connector work makes the scope of the custom work clearer and more manageable. The operations team knows which connections are supported by pre-built connectors and which ones require custom development, rather than treating all connections as equally uncertain.
The structural improvement from moving to a well-designed integration architecture is that each new connector you build makes the overall system more robust, not just the specific connection it handles. The hub keeps track of what connected and when, catches problems before they cascade, and makes the whole system easier to reason about as it grows.