Where orders actually get stuck
Ask a team where their order process breaks and the answer is usually a person's name rather than a system's. Someone re-keys the order into the accounting package. Someone checks stock in a second screen because the first one is not trusted. Someone chases a status by email because there is nowhere to look it up.
Each of those is a seam between two systems that were never properly joined, and each one adds delay, an opportunity for a transcription error, and a version of the truth that disagrees with the others. Mapping the seams - literally drawing every point where data leaves one system and enters another - is the first hour of work worth doing.
One source of truth per fact
Every fact about an order should have exactly one system that owns it. Stock level, price, customer address, fulfilment status, invoice state: pick the owner for each, and make every other system read from it rather than keep its own copy.
The failure mode this prevents is the expensive one. When two systems both believe they own stock levels, they will eventually disagree, and the business will find out when it sells something it does not have. Copies are fine as caches; they are not fine as authorities.
- Name the owning system for each fact before writing any integration code
- Give every order a single identifier that travels with it across every system
- Make derived data obviously derived - cached, timestamped, and refreshable
- Decide what happens when the owner is unreachable, before it is unreachable
Integrations are the hard part
The order interface is a week of work. The integrations are the project - which is why most custom software development budgets are really integration budgets. Payment providers, couriers, marketplaces, accounting packages, and warehouse systems each have their own idea of what an order is, how it is identified, and when it is final. In the UAE, e-invoicing through an accredited service provider is about to join that list for B2B and B2G sales.
Two decisions carry most of the weight. First, whether the integration is synchronous or queued - a queue costs more to build but survives the other side being down, which will happen. Second, whether it is idempotent: if the same message arrives twice, does the customer get charged twice? Getting these right at the start is far cheaper than retrofitting them after the first duplicate shipment.
Design for exceptions, not the happy path
The happy path is perhaps eighty per cent of volume and twenty per cent of the effort. The remaining orders are the ones that pay for the system: partial shipments, out-of-stock substitutions, cancellations after payment, returns, and split deliveries across warehouses.
A system that handles only the clean case pushes every exception back to a person and a spreadsheet, which is precisely the situation the project was meant to end. Enumerate the exceptions before building, decide which the system will handle and which will go to a queue for a person, and make that queue a designed part of the product rather than an inbox someone improvises.
Rolling it out without stopping the business
Order systems cannot go dark for a weekend. The safe pattern is to run the new path alongside the old one, send a narrow slice of real traffic through it - one channel, one warehouse, one product line - and compare outputs against the incumbent until they agree. It is the approach we took when replacing a legacy ERP and invoicing system the team used every working day.
Widen the slice only when the comparison is boring. Keep the ability to route back for longer than feels necessary. The cost of running two paths for an extra month is small next to the cost of a cutover that has to be reversed under pressure.
