Three vendors will tell you their software orchestrates the automated warehouse. The warehouse management system vendor says their new execution module eliminates the need for a third party. The automation vendor says their control system handles all routing and order release, reducing the management system to a simple inventory ledger. Neither of them wants to talk about the integration layer where these systems actually meet. If you do not explicitly define the boundaries between your warehouse management, execution, and control systems, the vendor who wins the hardware contract will define them for you.
The hard boundary between these systems is not a feature matrix. It is defined by latency and time horizons. A management system operates in seconds and minutes. It handles database transactions, inventory allocation, and worker tasks. A control system operates in milliseconds. It talks to programmable logic controllers, reads scanner strings, and fires pneumatic diverters. The execution layer lives in the awkward middle, translating order-level intent into equipment-level work.
When organizations try to collapse these time horizons, the physical world breaks. In a cold storage facility, a tote reaches a scanner on a routing conveyor. The scanner reads the barcode and passes the string to the control system. The control system queries the management system for the divert destination. The management system takes 800 milliseconds to query its database and return the payload. The tote takes 600 milliseconds to travel from the scanner to the mechanical divert shoe. The shoe fires late, the tote misses the divert, and manual runners spend the next three shifts pulling misrouted frozen goods off the reject line. The management system was built for transaction integrity, not millisecond response times.
Because the middle layer controls the flow of work, every vendor wants to own it. Automation vendors no longer want to sell just metal. They want software recurring revenue. To get it, they expand their control systems upward, adding order-release logic and workload balancing, branding it as an execution layer. If you buy their execution software, you lock your warehouse logic to their specific hardware. When you try to add a second automation vendor later, the first vendor’s software cannot orchestrate the new equipment, forcing you to rip out the logic or build an unsupportable bridge.
Management system vendors are defending their turf by moving down the stack, releasing modules to handle waveless picking and equipment routing. But traditional management architectures are built for batch processing—dropping waves of thousands of orders at once. A true execution layer needs continuous, real-time stream processing to release work only when a specific zone has capacity. A management vendor’s execution module is often just a batch engine running on a shorter timer.
System of record is too broad a label to resolve these disputes. The useful questions are narrower. Which system records a unit as picked? When does a carton become shipped? Who can reverse either state after a failed induction?
The management system must be the sole system of record for inventory and order status. The control system must be the sole system of record for hardware state—faults, speeds, and the physical location of specific carriers. The execution layer owns the state of work in progress, balancing capacity across zones. Integration fails when a control system tries to allocate inventory, or a management system tries to dictate the exact path a tote takes through a conveyor network.
Conflict arises when multiple systems believe they own the same state, especially during exceptions. A warehouse can run normally while its architecture is wrong. The gaps appear when a tote loses its label or a wave is canceled after cartons have entered the conveyor. During a go-live weekend, an operator clears a jam and puts three cartons back on the line. The sorter sees all three. The execution system expects two because it canceled one carton while the line was stopped. The management system still shows that carton allocated to an order. The physical tote is lost for hours while dashboards show the interface as healthy. An acknowledgment proves that a message arrived. It does not prove that a carton moved.
The integration specification is a political document. It says who can change what without telling the other party. Read it for what it forbids, not what it describes.
Sub-optimization is the default. The control system optimizes for sorter throughput. The execution layer optimizes for labor balance. The management system optimizes for order promise dates. Nobody optimizes for the whole building unless someone is explicitly assigned to. In one facility, the management system dropped a massive wave of orders because it calculated that inventory was available and the shipping cut-off was approaching. It had no visibility into the fact that the pack-out stations were understaffed. The high-speed sorter recirculation loop filled to capacity and jammed. The management system thought in transactions; the physical building was constrained by human labor.
You cannot test these boundaries with a clean order flowing through every component. That proves less than it seems. The seams are the test plan. You have to inject failures at the boundaries. Kill the execution layer mid-wave. Send a malformed priority from the management system. Simulate a control system fault that clears without notifying the upstream layers.
Map the exception vocabularies before go-live. Every layer has its own fault codes, retry logic, and escalation paths. The management system has a short-pick workflow, the execution layer has a re-route, and the control system has a hardware fault code. Mapping those three vocabularies is the actual integration work. If two systems can issue conflicting instructions, or neither can resolve the exception, the boundary is not yet drawn.
Fallback paths are architecture. If the execution layer goes down and the building stops, you did not design a fallback. You designed a dependency. If the management system can release work directly to the control system when the middle layer fails, you have a contingency. If it cannot, you have a single point of failure you did not draw on the diagram.
At 2 a.m., the on-call engineer has three vendor hotlines and one monitoring dashboard. The dashboard shows the management system is up, the execution layer is up, and the control system is up. The warehouse is stopped. No single vendor sees the whole picture. Vendor escalation paths do not match the control hierarchy. You have to design the escalation before you need it.
Dictate the integration architecture in the procurement process. Force vendors to provide their standard API payloads and exception sequences during the bid. Draw a sequence for each important exception before finalizing interface ownership. Include the operator action, the physical state, every message, and the inventory adjustment. The boundary is the decision a system is allowed to make, not the screen on which an operator can see it.
Take it with you
Takeaways
- Latency and time horizons define the real boundaries between warehouse systems
- State ownership conflicts surface during exceptions, not normal operation
- Fallback paths and exception vocabularies are architecture decisions, not afterthoughts
Asked and answered
Questions
Why can't a WMS vendor's execution module replace a standalone WES?
Traditional WMS architectures are built for batch processing—dropping waves of thousands of orders at once. A true execution layer needs continuous, real-time stream processing to release work only when a specific zone has capacity. A WMS execution module is often just a batch engine running on a shorter timer.
What happens when a control system tries to allocate inventory?
Integration fails when a control system tries to allocate inventory or a management system tries to dictate the exact path a tote takes through a conveyor network. The management system must be the sole system of record for inventory and order status. The control system must be the sole system of record for hardware state.
How do you test the boundaries between these systems?
You cannot test them with a clean order flowing through every component. The seams are the test plan. Inject failures at the boundaries: kill the execution layer mid-wave, send a malformed priority from the management system, simulate a control system fault that clears without notifying upstream layers.