When a retailer talks about replatforming, the conversation almost always starts with the storefront. New theme, faster pages, a headless front end, maybe a fresh design language. The storefront is visible, it is what executives see in a demo, and it is the thing customers touch. So it gets the attention, the budget, and the launch date.
Then the project hits the order management system, and everything slows down.
This is the pattern across composable commerce builds. The front end is the easy half. The hard half, the one that quietly decides whether the whole replatform succeeds, is the system that takes a completed checkout and turns it into a delivered package. That system is the order management system, the OMS, and in a composable architecture it is the real engine. The storefront just collects the promise. The OMS is what has to keep it.
What an OMS actually does
Strip away the vendor language and an OMS answers one question for every order: can we fulfill this, and from where?
To answer it, the OMS has to do several jobs that the storefront cannot. It holds a single, near-real-time view of inventory across every location: warehouses, stores, drop-ship vendors, third-party logistics providers. It decides whether to accept an order at all, based on what is genuinely available to sell. When an order comes in, it sources it, choosing which location or combination of locations will fulfill each line. It routes the work to those locations and to carriers. It handles order splitting when no single site has everything. It tracks the order through its lifecycle, manages changes and cancellations, and runs the returns process, which is its own routing problem in reverse.
Forrester frames the category around four core capabilities: enterprise-level inventory visibility, distributed order management, customer service, and store fulfillment. None of those live naturally on a storefront. The storefront is a presentation and checkout layer. It is good at showing products and capturing payment. It was never designed to reason about inventory across a fulfillment network.
Distributed order management and available-to-promise
Two ideas sit at the center of what an OMS does, and both are worth understanding plainly.
Distributed order management, or DOM, is order fulfillment when inventory is spread across many locations instead of one. In the simple world, you had a warehouse, you shipped from the warehouse, done. In the real world a mid-sized retailer might have several distribution centers, a few hundred stores that can each ship or hold orders, and a set of suppliers who drop-ship directly. DOM is the logic that looks at one order and decides, line by line, the best place to fulfill it. Best is not one thing. It might mean closest to the customer for speed, or the location with the most slow-moving stock to clear, or the fewest parcels to cut shipping cost, or simply the store with staff free to pick today. A good DOM engine balances those rules. A weak one ships everything from the default warehouse and burns money on split shipments and slow deliveries.
Available-to-promise, or ATP, is the number behind the promise. ATP is the quantity a business can actually commit to a new order right now. It is not the same as what is physically on a shelf. On-hand stock includes units already allocated to other orders, units reserved for pre-orders, units held for quality inspection, units being transferred between locations. ATP is what is left after all of that is subtracted: inventory you can genuinely sell. When a product page says "in stock" or a checkout shows a delivery date, an ATP calculation should be standing behind it. When that calculation is wrong or stale, the retailer oversells, and overselling means cancelled orders, refunds, and on marketplaces, penalties. Amazon's order defect rate, for example, can put a seller account at risk if it climbs too high.
ATP and DOM are tightly linked. ATP tells you whether you can take the order. DOM tells you how to fulfill it. Both depend on inventory data that is accurate to the minute, not the hour. This is why the OMS, not the storefront, is the system of record for the fulfillment promise.
Where the OMS came from
The OMS is not new, which makes its neglect harder to excuse. The discipline took shape in the early 2000s as retailers began selling across catalog, web, and store and discovered their warehouse and ERP systems could not coordinate the result.
A useful marker is January 2005, when Sterling Commerce acquired Yantra for 170 million dollars. Yantra built distributed order management and supply chain fulfillment software, and its suite already covered the modern feature list: distributed order management, inventory synchronization, reverse logistics, and delivery scheduling. IBM acquired Sterling Commerce from AT&T in 2010, and that lineage became IBM Sterling Order Management, still one of the heavyweight enterprise OMS products.
So the hard problems of order orchestration were named and productized two decades ago. What changed is that composable architecture pulled the OMS out of the monolith and made it a separate, deliberate choice. In an old all-in-one platform, basic order logic came bundled. In a composable stack, you select an OMS, and you own the integration. That shift is exactly where projects get into trouble.
The market says the OMS matters more, not less
If composable commerce were making the OMS less important, spending would be flat. It is not.
Forrester projects the global OMS software market to reach 1.9 billion dollars by 2026, nearly double the roughly 1 billion dollars in 2021, a compound annual growth rate of about 12.3 percent. Retail and wholesale account for close to 70 percent of that spend. Independent OMS vendors are raising money on the same thesis: OneStock, a European OMS provider, raised 72 million dollars in 2024.
The vendor landscape reflects how specialized this layer has become. Enterprise buyers look at IBM Sterling Order Management, Manhattan Associates, Blue Yonder, and Kibo. Composable and mid-market builds bring in Deck Commerce, Fluent Commerce, fulfillmenttools, Nextuple, and HotWax. Some of these vendors do nothing else: Fluent Commerce, founded in Sydney in 2013, has built only order management for its entire existence. The fact that a healthy independent OMS market exists at all is the tell. If storefront platforms covered order orchestration well enough, you would not need a separate category of software to do it.
Why the storefront is not enough
Here is the trap. Modern storefront platforms do include order features, and they look sufficient in a demo. Shopify supports multi-location inventory, buy online pick up in store, and ship from store. For a single-warehouse direct-to-consumer brand, that is genuinely fine.
The limits appear at scale. Shopify allocates inventory immediately, so holding stock or scheduling a later ship is awkward. It restricts mixing pickup and shipping in one order. Its routing optimizes on a few parameters like market and distance, and anything richer needs custom code. None of this is a flaw in Shopify. It is a storefront doing storefront things. It is simply not a distributed order management engine, and a retailer with stores, multiple distribution centers, and drop-ship suppliers will hit the ceiling. The same is true for any commerce engine asked to do the OMS job alone, including composable ones.
The failure modes when the OMS is an afterthought
When teams treat the OMS as just another interchangeable block, the same failures recur.
The first is overselling from stale inventory. The OMS must sync with the warehouse management system, the ERP, stores, and marketplaces. If those systems sync on batch cycles, hourly or nightly, while orders arrive every second across channels, the OMS routes against numbers that are already wrong. The result is sold-out items still on sale and exception queues that consume the operations team.
The second is inventory divergence between systems. The OMS believes stock is available; the WMS has already committed those units to other orders. Now you have an order routed to a location that cannot fill it, which triggers expedited reshipping or a cancellation.
The third is rebuilding order logic in the wrong place. When the OMS integration looks hard, teams take a shortcut and code routing and allocation rules into the storefront or a custom middleware layer. That logic is now scattered, fragile, and impossible to change without engineering. The retailer has recreated the monolith inside a stack that was supposed to be modular.
The fourth is the fractured post-purchase experience. Pre-purchase data lives in one system and order, fulfillment, and returns data in another. Customer service cannot see a full order. Returns are painful. The customer feels the seams.
Why replatforms stall on the OMS
The OMS is the hardest integration in a composable build because of where it sits. It is wired into the storefront, the ERP, the WMS, payment systems, carriers, and every third-party logistics partner. The MACH model preaches loose coupling, but the OMS is, by its nature, deeply connected. Every one of those connections needs schema mapping, error handling, and monitoring, and inventory and order data must move in near real time, not in nightly files.
So the storefront ships, looks great, and then the project enters the long phase: getting the OMS to talk correctly to the ERP and the WMS, reconciling inventory feeds that use different SKU and location identifiers, and proving that ATP is accurate before go-live. That work is unglamorous, it does not demo well, and it is routinely under-scoped. The honest fix is to size the OMS integration before the storefront, not after. Some retailers go further and stand up the OMS first, letting it shield customer-facing channels while slower back-end systems change behind it.
The agentic stakes raise the price of getting it wrong
A newer reason makes the OMS even more central. Shopping is starting to move into AI assistants, and the payment networks are building the rails for it. Visa launched its Intelligent Commerce program in April 2025, and in October 2025 it introduced the Trusted Agent Protocol with partners including Shopify and Stripe. Mastercard launched its own agentic checkout framework in late 2025. The direction is clear: the buyer is increasingly an agent, and an agent's core question is operational. Can you deliver this to my user in their timeframe? The agent does not care about hero imagery. It cares whether the availability and delivery promise is true.
That promise is an OMS output. ATP decides whether the item can be sold, distributed order management decides how fast it can arrive, and the OMS exposes both. An agent that is repeatedly told an item is available only to find it is not will simply stop recommending that merchant. In an agentic channel, fulfillment reliability is the ranking signal, and the system that produces it is the OMS. The storefront stops being the store, and what is left, the part that still has to work, is the engine underneath. For enterprises moving toward agent-readable commerce, getting the OMS right is no longer a back-office concern. It is the front line.
The lesson for any composable build is short. Admire the storefront, but budget for the OMS. It is the harder system, the one that decides whether the order is real, and the one quietly running the whole machine.
Council summary
This post argues that the order management system, not the storefront, is the system that decides whether a composable commerce build succeeds, because the OMS owns available-to-promise and distributed order management, the logic that turns a checkout into a delivered package. The review verified every figure against primary sources: Forrester's projection of a 1.9 billion dollar OMS market by 2026 at a 12.3 percent CAGR, the roughly 1 billion dollar 2021 base, the nearly 70 percent retail and wholesale share, Sterling Commerce's 170 million dollar Yantra acquisition in January 2005, IBM's later purchase of Sterling Commerce from AT&T, OneStock's 72 million dollar 2024 raise, and Amazon's order defect rate threshold. The future section was given a concrete anchor with the 2025 launch of Visa and Mastercard agentic payment rails, and the vendor discussion now notes that some OMS providers, such as Fluent Commerce, do order management and nothing else. The takeaway for any team replatforming: size and sequence the OMS integration before the storefront, because it is the harder system and the one the whole machine runs on.
Comments