Moving Airline ops from legacy to order management systems

In the airline business, there has long been an effort to break away from legacy (Global Distribution System) to move towards a retailing approach using an order instead of just a reservation. This transition creates the domain known as airline order management, a core domain for the airline industry.

IATA strives to create standards, best practices, and domain recommendations, among other things, to help airlines transition from a legacy architecture to an order-centric platform.

A crucial point in this transition is ensuring an airline that uses GDS can begin using a domain like order management and ensure integrity, low data loss, and up-to-date information that will live in both the legacy (GDS) area and the order.

If an airline plans to transition to the order management domain, it needs to understand how to synchronize a reservation with an order. 

It is common for an airline to use GDS like Sabre or Amadeus, among others, where all the information related to a flight is available, such as the itinerary, the passengers, the tickets, coupons, etc. Various actions are also allowed, such as booking a flight, searching for flight offers, making changes to a reservation, refunds, etc.

When an airline moves to the order management domain, it creates a bounded context that will modify its ubiquitous language by adding new words like order, and items/products, among others. It needs to keep the information in a GDS reservation updated with the order living in this new domain, necessarily outside the GDS and possibly on the airline’s platform, to generate a phased transition from one phase to another.

Microservices and CQRS

Microservices are essential to implement a decoupled CQRS that interacts with a service that persists the order information. This service must solve  what changes the order has undergone over time.

Abstraction

It is crucial to have a layered structure that guarantees the abstraction of external systems. For this, we can generate a service that connects to the GDS. This layer aims to try to remedy various coupling to external services, and in the event of a GDS migration, this layer would suffer the consequences. Still, the rest of the platform internally should have been fine.

GDS Events and pub-sub

With the help of a new service that interacts with the GDS that allows knowing the marks that the GDS leaves on the reservation, it can trigger events on a pub-sub that allows notifying the order of any change.

Examples

Let’s see an example to understand better. If, for some reason, there is a contingency and the first to find out is the GDS, they may end up marking a remark or leaving a mark on the reservation. When this happens, the service interacting with the GDS finds this mark and places a reserve contingency event in the pub-sub. All those subscribed to that event find out, and among those is the service whose goal is to obtain all the information about the changes and send it to the CQRS to update the order information.