The request arriving in the board pack is usually framed as an AI problem.
The company wants better forecasting, faster service, automated exceptions, or intelligent product discovery. A budget appears. A platform is shortlisted. A pilot is scoped against a curated data set.
Then the pilot meets production.
The order in commerce is not the order in the ERP. Inventory in the warehouse is not inventory on the site. The customer in CRM is not the account that owns the contract price. Product attributes live in a spreadsheet, a PIM, and a PDF, and none of them quite agree.
The constraint was never the model. It was that the business cannot move trusted information through the systems it already runs.
That is an integration problem with an AI label. Why most AI projects fail before they begin explains the executive consequence. This article is about the architecture underneath it.
The Landscape Was Not Designed as One Business
Commerce landscapes accumulate. ERP is added for finance. A storefront is added for digital sales. CRM is added for accounts. WMS is added for the warehouse. POS is added for the store. Each system does its job. Few were selected with a shared information flow as the design constraint.
The result is familiar: the same SKU, customer, price, and order exist in several places, updated on different clocks, reconciled by people.
Collecting that data in a warehouse or a dashboard does not fix the operating problem. A report can show yesterday's conflict. An operation needs today's event: order created, inventory reserved, payment captured, address changed, return received. If those events cannot travel, teams will keep exporting files, re-keying records, and chasing status.
McKinsey's work on AI data readiness is useful here, not as a destination. It found that only 7 percent of companies have fully scaled AI across their organizations, and that more than two-thirds of high-performing companies name data as the primary obstacle. It also draws a distinction operators already feel: making information searchable is not the same as making it usable.
Usable, in a commerce operation, means a system can act. Available-to-promise can be trusted. A price can be honored. A fulfillment status can be shown without a phone call.
Copies Are Not a Backbone
Many integration programs still move copies. A nightly file of inventory. A weekly customer extract. An order export that finance maps by hand.
Copies create a second record. The second record starts decaying the moment it is written. By morning, the store has sold stock the file still shows as available. By afternoon, the account's credit status has changed and the storefront does not know. By month-end, two systems must be forced into agreement.
An operational event is different. The business records that something happened, once, and the systems that need to know are notified while the fact is still true. The order is not "in commerce, waiting to be typed into ERP." It is a business event that finance, warehouse, and customer service can all see.
That is the difference between synchronizing data and running the company on connected information.
Batch has a place — historical analytics, financial close, bulk enrichment. It is the wrong foundation for anything that has to be true while a customer is waiting, a warehouse is picking, or an AI system is recommending.
Point-to-Point Solves Tuesday and Constrains Thursday
The fastest way to make two systems talk is a direct connection. Commerce to ERP. ERP to WMS. CRM to the storefront. Each link is justified. Each one is someone's project.
Over time the map becomes a knot. Every new system needs a new pair of pipes. Every change to an order object has to be negotiated across several custom jobs. Failures are silent until a customer, a pick ticket, or a close cycle exposes them.
Point-to-point integration is still integration. It is not a scalable architecture. It does not give the business a place to enforce meaning, retry with visibility, or add a new channel without rebuilding last year's work.
A durable approach treats integration as infrastructure: events flow through a governed layer, systems subscribe to what they need, and the same order, inventory, and customer definitions are reused. The goal is not a diagram. The goal is that when the business adds a marketplace, a store, a 3PL, or an automation, the operating facts are already available.
Ecommerce data complexity is the companion problem: who owns the meaning of a SKU, a customer, and an order when systems disagree. This article owns the flow. That article owns the definition.
AI Inherits Whatever You Feed It
An AI initiative does not create a single version of the business. It consumes one.
If inventory is late, the forecast is a report. If price is not bound to the account, the assistant will guess. If product attributes are incomplete, discovery will miss the SKU a knowledgeable buyer would have found. If exceptions have no owner, an agent will either stop or improvise.
That is why "centralize the data, then add intelligence" is incomplete. Centralization without operational use produces a lake of conflicting copies. Intelligence without a trusted event stream produces confident answers about a business that no longer exists.
The foundation AI requires is the same foundation a well-run operation requires:
- Systems of record that are allowed to be right
- Events that move at the speed of the process
- Integration that can be observed, retried, and changed
- Workflows that can execute without a person carrying the file
Replatforming the storefront is not transforming the business for the same reason. A new front end on a fragmented information flow still produces fragmented work.
What to Fund Before the Next AI Tool
Leaders can test the architecture without a maturity score.
When an item sells, how long until every channel and the warehouse know? When an address changes, which system is believed? When an order is held, does the hold exist as a shared fact or as an email? When two records disagree, is there an owner or a meeting?
If the honest answers depend on a person, the next investment is not another model. It is the information flow that lets the existing systems behave as one business.
Start with the events that already hurt: the order that has to be re-typed, the oversell, the invoice that will not match, the pickup that cannot be promised. Connect those first, as events, with an owner when they fail. A lake of historical data will not substitute for that.
A readiness view of systems, data, and workflows can make the gap visible before another tool is purchased. Arizon Digital's Agentic Commerce Readiness Index includes integration and the data backbone for that reason. The index is not the architecture. The architecture is whether the business can move a trusted order, inventory position, and customer record without a person in the middle.
That work is not glamorous. It does not demo well. It is what determines whether automation can run, whether service can answer, and whether AI can be trusted with anything that touches a customer, a price, or a unit of inventory.
AI readiness, in this sense, is operational readiness. The budget should follow the constraint.