Modern Airline Retailing fundamentals. A series of short explainers on MAR — the terminology, the structure, and what changes when airlines move from PNRs to orders.
The previous posts have described OOSD as it exists in theory — the schema, the structure, the standards. This one is about what it's like to actually build on top of it.
The short version: it's complex, it's ongoing, and the spec and the implementation diverge more often than you'd expect.
The bilingual system problem
One of the central challenges in building a modern Delivery Management System is that the legacy world hasn't gone away. Airlines still use systems built around PNRs, SSRs, and six-character booking references. Ground Handling, baggage, APIS run on legacy identifiers. You can't simply replace the old world with the new one; you have to hold both simultaneously.
One approach is to build what you might call a bilingual system: rather than translating between the legacy and the new world, you hold both representations in parallel within the same system. The system understands PNRs and it understands orders; it can communicate in both directions without losing information.
In practice, the pull towards divergence is real. The new world has different constraints — or in some cases, no constraints where the old world had hard limits. An order can have 200 passengers. A PNR booking commonly maxed out at 20. A system that was built assuming 20 will eventually need to be rebuilt to handle 200. Keeping the two worlds in sync for as long as possible buys time, but it doesn't buy forever.
Building alongside the OrMS
There's an additional wrinkle: in many implementations, the Order Management System and the Delivery Management System are being built at the same time, by different teams, against the same evolving standards. As one side changes, the other has to change. You end up co-developing against a moving spec, and when the spec itself changes (which it does), both sides have to respond.
This isn't a criticism of the standards process; it's an honest reflection of what it means to be an early implementer. The standards are designed by committee and ratified over time; the edge cases and practical contradictions don't always surface until someone tries to build.
What the spec doesn't cover
Some parts of the operational picture sit outside the OOSD schema entirely but are still part of the day-to-day reality of running a Departure Control System. Schedule messages, MVTs, SSIMs, ASMs, aren't part of OOSD, but a DCS still needs to hold schedule data. For now, that means continuing to receive something like those legacy messages from the OrMS, even in an otherwise modern implementation.
Similarly, interline and codeshare add a layer of complexity that the schema handles at a conceptual level; there's a distinction between the Offer Responsible Airline, the operating carrier, and the marketing carrier, but the practical implementation is murky and often needs to be worked through case by case.
The distinction between seller and delivery provider
One concept worth understanding if you're building in this space: the schema distinguishes between a seller (the entity that added items to an order) and a delivery provider (the entity responsible for updating delivery status codes). These are different roles with different access rights. Sellers can't see each other's items in an order. A delivery provider needs visibility of the full order: all items, all services, regardless of who sold what, because they're responsible for servicing the passenger through their whole journey.
If you're building a DCS, you're a delivery provider. That means your access model, your data requirements, and your responsibilities are different from those of a selling system.
Q: Has building on OOSD thrown up significant challenges like the passenger limit mismatch?
Yes. The order standard has no passenger limit, but a legacy DCS might have a hard limit of 20. That's just one example of the kind of mismatch that comes up constantly. You find it everywhere: in how identifiers work, in how schedule data is modelled, in how interline bookings are handled. The honest answer is that building this kind of system is a multi-year project, and a lot of the work is in handling the gaps between the old world and the new one.
Q: Are these integration challenges and edge cases being documented anywhere?
They should be. There's real value in capturing what the spec says versus what actually works in practice, both as an internal resource and as something useful to the wider industry. The irony is that the teams best placed to document it are the ones too busy building it. It's a known gap.