This is my personal view from a technical point of view of the current state and usability of NDC.
In October 2012 IATA passed Resolution 787 Enhanced Airline Distribution. This was the birth of New Distribution Capability or NDC
Now, 10 years later the Airlines are boasting about NDC as if it were manna from Heaven. As a matter of fact, the NDCs today are a train wreck.
After 10 years of development most, if not all NDCs lack basic functionality. This leads me to query the competence of the various IT departments developing the software and management approving flawed design concepts and allowing snail paced progress to continue to this very day.
American Airlines developed an Airline Distribution platform in the 1960’s – Sabre. Other airlines followed over the next thirty or so years. Sabre was sold in 2000, and other airlines’ systems were also spun off around that time.
While this was a sugar hit to the airlines’ profit, they have been paying a hefty price ever since. They now have to pay for the services they used to own.
No wonder Airlines enthusiastically embraced the New Distribution Capability. They see this as a chance to reverse the short-sighted decision of twenty years ago.
So, where did it go wrong?
Some technical stuff first.
- Airlines claim the NDC is “XML based”. This is not strictly accurate.
XML is a protocol to transport data between computer programs and servers. It is Open Source, not owned by anyone. There are many other protocols that do exactly that in different ways – the content being transported is still EDIFACT.
As usual with technical stuff, you will find technicians praising the system they are using and rubbishing all the others. Rest assured, all the protocols work. There is nothing special about XML. - The data (your reservation and lot of other stuff) is stored in a database.
XML transports the content of your commands to the database and also collect the data when you are retrieving a booking. There is a lot of awe and fear about dealing with database, most of it fuelled by the exorbitant prices database engineers/administrators/programmers charge for their services.
In reality a database is the electronic equivalent of a filing cabinet.
Like a filing cabinet, there are four functions:- When you create a new file, you add that file to the filing cabinet.
This is an INSERT - When you retrieve a booking you SELECT the file
- When you make changes you UPDATE
- When the client cancels, you DELETE
- When you create a new file, you add that file to the filing cabinet.
That’s it, folks. All interactions with your reservation are functional. Therefore easy to program. Any first year Information Technology student can get a basic demonstration program done in half a day.
Airline reservation does not require us to calculate the trajectory of the Earth around the Sun in 25 years’ time. In fact, the mathematics are primary school stuff.
The difficult part with any computer program and database is the design phase. This can take a long time and is critical to the success or failure of the venture.
Some of the shortcomings of the current NDCs point to glaring incompetence in this phase.
“A booking can only hold one passenger” – have the designers ever heard of the concept of families and friends travelling together?
A well-designed database could not care less about how many passengers travel in one PNR.
Not having all four database functions fully operational after years of programming points to the incompetence of the programming teams.
Interaction with your back-office system
Over the years I have written programs to feed itineraries and accounting data into our back-office system for Galileo, Sabre and Amadeus.
You receive text-based data (plain text, JSON, XML, etc) from the GDS. The documentation tells you where to find what data. “All you have to do” is push that data into the appropriate area of your system.
It is a simple task, but because of the huge variations available, a time consuming one. Amadeus documentation is 77, Galileo 229 pages.
Once you have this system in place, there is no excuse for any back-office operator to not incorporate GDS generated NDC data.
The most time-consuming task is reading the 30-page Amadeus documentation. They should have sent us just this:
- The NDC data is exactly the same as “normal” data with two additions:
- Normally you have an airline PNR and a GDS PNR number.
- NDC adds an NDC PNR and an NDC order or invoice number to the data.
- Nothing else has changed.
All the back-office provider has to do is add those two data fields to their database and display them when needed. NDC does not affect either itineraries nor basic accounting in any other way.
If your back-office provider does not offer that, you should ask some serious questions.
The future
I acknowledge that there is a lot more involved than above critique touches on, but most, if not all, of the difficult and sensitive stuff is already in place. Security, protocols are two important parts in that category.
In the good old days, computer programs were only released once the important and basic features worked. By this standard NDC is still in the development phase.
Given the amount of money the airlines have spent already, NDC interfaces will have a future. It is debatable whether NDC will replace EDIFACT or even dominate the reservation landscape. In my opinion the answer is no.
However, NDC is here and we have to learn to live with it.
I am happy to access NDC via the GDS at no extra cost to the business.
We will not use any airline’s NDC directly until the system works and downloads are available.
The few dollars saved in the fare do not compensate for the extra work created at the back end and the extra effort required to make changes.
I have not studied any of the NDC content providers in depth because the base product is so flawed. Once NDC works properly, I will assess their offers.
