The IATA NDC Implementation workshop Miami, Feb 19-21, 2019

Midoco had the opportunity to join the NDC implementation group for a workshop conducted by the IATA. The three-day meeting gave insight into the state of development, the persons and companies contributing and the key discussion points on the table regarding the strategic focus of the NDC development. As a mid-office software provider, we were invited present our view on NDC highlighting aspects that we think need to be addressed. Attendees were airline related NDC project members, as well as many IT related/technical participants (from GDS side or independent companies), plus some representatives of IATA responsible for the organisation of the work groups. All the above stakeholders are either working on current implementations of the NDC standard or working to get the standard defined. The multiple subjects discussed were direct sales, the standard definition, ONE order, TMC and agency sales, PCI/DSS, TIDS, GDS developments regarding NDC, airline profiles, look to book ratio, code related subjects and plans for messaging systems handling notification.

Day One

Direct Sales / ONE Order / TMC and Agency Sales / PCI DSS

The first point on the agenda mainly involved direct sales topics with an emphasis on the construction of airline specific websites for various markets. Direct sales being one of the drivers of the standard of course have a legitimate priority. Nonetheless Midoco providing a software for TMCs and agency sellers pointed out that TMCs and indirect sales have a gravity that needs to be recognized especially, when half of the global travel business originates from business travel. Business travelers belonging to the most valuable group of travelers, that travel multiple times per month. The gap identified, is that the standard to date has no attributes that pay attention to traveler profiles or special payment scenarios so far. Moreover, the whole idea of ONE order cannot replace the old structures as intended as long as a great deal of passengers are booked current systems, because of their proven performance in terms of e.g. speed! ONE order can only work when the whole process chain is “order-aware”, including the mid-office/back-office/settlement systems (like ARC or BSP).

Another topic discussed was PCI/DSS. Some airlines do not want to get involved and search for mechanisms how to get their systems out of scope, when implementing the new NDC processes and performing direct sales. Currently they do not need to care, because almost every payment action is done within environments hosted by the GDS like Amadeus, Sabre and Travelport. When implementing things for themselves, airlines need to think about secure payment, not only for website sales, but also for agency sales. A very good presentation of SAS brought up this aspect and led to a discussion, about PCI/DSS compliance of the airlines and the agencies as well.

Demonstrations of Navitaire and United Airlines showed that there are already visible steps taken to implement a ONE order concept, but still there is a long way to go.

Day two

TIDS / GDS developments regarding NDC / Experience with integrating Farelogix and the unified back-office notification standard / Messaging, best practices / Look to book ratio / Airline Profiles

We started with a discussion about TIDS (which is an (existing) ID scheme for agents with an IAT license). Within the NDC messages there are places where an agent is defined by an ID, but it is not clear which type of ID should be used. The general idea brought up by the IATA is to use these TIDS in the NDC messaging, including non-IATA agents. This was discussed vividly. On the one hand this being a pragmatic approach and on the other hand the implementations process being too long and too expensive. Since NDC is usable for non-IATA airlines as well as for non-IATA agents, this would be a too big obstacle to getting started. The TIDS is also a mechanism, which includes several checks in the enrollment process, and currently sometimes leads to certain privileges (e.g. who can book which rate). This might be not necessary for non-IATA agents. The benefit would be that the system is already in place. IATA promised to work on the duration and business model.

With this controversial discussion, the agency sales process was addressed again. A very impressive demo of Travelports progress to include NDC content in the Galileo system showed where GDS are heading to. Amadeus is working on an integration as well and Sabre recently bought a solution with Farelogix, which is likely to be integrated somewhere in their existing user interfaces. The first steps are taken, and GDS appear, happily to discuss about how this should be done with their customers, as well as with their competitors. At the moment, an NDC booking is completely separated from the „normal“ PNRs and will be presented as a ghost PNR to the agency, which is very limited.

Also other presentations of self booking tools or airline integrations seem to be promising and already functional.

In my second presentation I pointed out (together with José from Lufthansa Group) what issues we encountered on our first steps in integration of NDC through Farelogix. The acceptance issue and the need to support very special cases was discussed. The idea to define a unified back-office notification standard was brought up. Since this would not really influence the sales process, a separate messaging could be defined without affecting the actual defined messages. Obviously, such a standard message would include or duplicate parts of the original NDC messages and should be prepared to address the ONE order mechanisms.

Discussions showed that at present a variety of versions of NDC messages are being used, even mixed versions within one airline implementation or even parts of different versions within one message. This of course will be getting better over the time, since the NDC protocols hopefully become more stable within the next years.

The huge variety of message versions leads to certain issues on the aggregator side, which are solvable, but ugly. When the upcoming releases will hopefully be more downwards-compatible, these issues should not be that problematic any more.

Some discussions arose around some standard related subjects like the purpose of specific messages, the need for a directory of known defects including workarounds. Also a set of „best practices“ should be worked on.

The idea of airline profiles (already defined) was discussed, currently not really implemented by anybody, which could prevent unnecessary requests (look to book ratio) to an airline system for city pairs which are not in the portfolio of this airline.

A brainstorming session concluded the second day with the purpose of identifying possible gaps in the scheme (e.g. actions are not defined). The results were passed to the standards team to evaluate.

Day Three

Technical subjects / Servicing / Messaging system handling notification

The technical subject that caught the attention of the workshop participants was the duplication of common types in each message and the effects for realization in Java programming language. Also, a proposal was brought up to implement a central messaging system handling notification of changes (from airline to seller). This is very interesting, but maybe it is hard to operate, since a central system would be a critical 24x7 product which would affect every airline when a downtime occurs.

The idea to generally construct a PNR for each passenger for better handling was discussed controversial. There are reasons to do this, but strange effects might arise, e.g. for families on different PNRs sitting in separate planes at the end of a modification.

A further topic that had the attention of the workshop participants was servicing in terms of how this works with NDC. The necessary structures are mainly defined, but there are certain issues identified which are not clear, especially how changes from airline side should be pushed, or re-shopping will occur after a change. The variety of message versions also concerned this topic as not all airlines have implemented the same versions or even do not handle specific messages.

Altogether a great deal of subjects were touched. My general impression is that a lot of reasonable people are involved with a common vision in mind. The discussions are not over, but mostly target-oriented and driven by the right persons with good understanding of the process. What scares me a little bit is the huge variety of message versions and multiple ways to work with the messaging. This will be hard work for anybody trying to present a unified booking platform based on the standard. For me, it was very interesting to see how the standard evolves and we will continue contributing, by either commenting the existing work or introducing additional ideas.

Check the link below to have a look at the slides shown by the participants of the workshop.

https://airtechzone.iata.org/community/events/#mia19