Ai Editorial: Managing “version control” as NDC evolves

First Published on 11^th October, 2016

Ai Editorial: As NDC moves along there will be evolving versions of the schema that will impact the specific XML messaging, in that messages themselves will change over time – new ones added, existing ones modified, etc., writes Ai’s Ritesh Gupta

IATA’s XML-based data transmission standard continues to be in the limelight.

While a section of the industry, be it for airlines, meta-search engines, GDS companies etc. is marching ahead with pilots and deployments, it is also being questioned whether a set of standard messages are sufficient, why to rely on only one standard in XML, or even can there be any better messaging format.      

One way to assess the progress is to look into how various stakeholders are looking at projects using Offer and Order management messages whose schemas are compliant with the standard NDC message schema.

-       How are things coming along as far as capability to receive and send NDC messages is concerned?

-       How the schema from the airline will impact the established workflow?

It needs to be clarified that IATA certifies the messages, not the underlying architecture and processes or workflows.

Feedback:

·          Schemas for shopping and, order management: There are schemas for shopping and, order management, and the end result is creation of Offer ID and Order ID, featuring order creation, ticketing, issuance, payment authorization and BSP reporting. So when we say different airlines have different objectives/ expectations from NDC, does it mean some are only working on schemas for shopping and, some are working on schemas for both shopping and order management? So yes, certain carriers may opt to go end-to-end; others may only end up controlling the offer and wouldn’t execute. Or, the execution on the offer becomes more of a tactical/ economical decision rather that a strategy decision. As per my recent interaction with Farelogix, the company has 20 airline customers that have adopted the NDC schema for the API that the team has built for them. The actual schema version will vary from baseline to 15.2, but all 20 are controlling and creating the offer (Offer Management). These airlines are creating and delivering just over 1.4 billion airline offers annually through their NDC API. (Not all offers are accepted and executed as tickets).

·          Capability to receive and send NDC messages: It is vital to know how does the capability to receive and send NDC messages vary as per the version of a particular schema. Messages may change and improve with new versions thanks to the addition of new elements (e.g., sending video images) or enhancements to existing elements (e.g., split PNR improvement). Airlines will adopt new versions based on whether or not the newer versions address a required business need or if they simply want to update their version usage. In today’s world of deploying an NDC API between airline and intermediaries, there will be evolving versions of the schema that will impact the specific XML messaging, in that messages themselves will change over time – new ones added, existing ones modified, etc.  So if an airline has deployed NDC schema version 15.2 and a newer version becomes available (15.4), then the airline would need to work with all their intermediaries that deployed version 15.2 in making the upgrade to 15.4. 

·          Connectivity issues: The biggest issues are in understanding the various workflows that have been established by a GDS or OTA and understanding how the schema from the airline will impact the established workflow. “It is also being prepared to make what we refer to as “implementation accommodations” to how the GDS or OTA want to utilize the specific schema elements.  There is also the concept of the end user being able to “interpret” how a particular schema element is utilized.  This is why it is very important for either the airline, or it’s developer proxy such as Farelogix, to have the technical resources (people, documentation, etc.) available to support an NDC API implementation,”  says Farelogix CEO Jim Davidson.    

In one of our recent articles, Amadeus stated that the whole industry and airlines in particular, are coming to the realisation that having a set of standard messages is necessary but not sufficient. “Connecting systems with these standardised messages is the easier part, but it takes a lot of knowledge and industry understanding to turn them into successful distribution tools. Most vendors underestimate the complexity of the integration part,” mentioned Hazem Hussein, Executive Vice President, Airline Group, Amadeus Asia Pacific, Turkey and Eastern Europe.

Dealing with different versions of schema is all about change management.

Airlines must learn how to build, deploy, manage and upgrade APIs in a way that streamlines the task of developers. Proprietary APIs tend to create “one-off” implementations that make repeatability more complex and therefore more expensive. Carriers also need to upgrade their internal systems to be able to support API-based distribution. So as carriers’ set up is gearing up to process all distribution-related transactions, it isn’t going to alter the inherent proposition of GDS, i.e. the reach they deliver to airlines. Rather they need to move on from being a transaction focusing company to a supplier of enterprise-like applications to the agency communities, based on the effective aggregation of hundreds of airline APIs. As for NDC certification, it needs to be mentioned that certifying one NDC message for one single ancillary service as part of the existing, opaque and flight-centric shopping process is easy. Leveraging the full scope of airline APIs to re-think the search and booking process and the experience delivered to users (whether they are agents or the end-consumer) is another story. Lastly, talking of online travel agencies and to a certain extent flight search engines, these organizations also have to consider their ‘flights’ offering. With carriers pushing more ancillary services as stand-alone or as part of fare families, it is imperative for online intermediaries is to evaluate how to make flight search and shopping more transparent.  

Value proposition

How are airlines going about distribution of content via API connectivity, considering that different airlines and intermediaries can have different API gateways for exchanging XML messages?

Today there are IT specialists emerging as new aggregators and are also offering NDC adapters.  

It comes down to the value proposition that can be created between airline and intermediary. NDC is really only the catalyst to enable this new value proposition. If the airline can send new and relevant content via an intermediary that can display and transact on this content better than another intermediary, then competitive pressure gets created which is beneficial for the entire travel supply chain.

Where is NDC headed in the next 12 months? Hear from senior industry executives at the upcoming 7th Mega Event Worldwide 2016, The Event for Loyalty, Ancillary & Merchandising & Co-Brands, to be held in Toronto, Canada. (25 -26 October, 2016).

Twitter hashtag: #MegaEvent16

Follow Ai on Twitter: @Ai_Connects_Us