Technology that changed air travel

In the future, we're hoping to write a piece about how air fare pricing works too. There's a lot of interesting stuff re. fare buckets, forecasting supply + demand, etc. It's also very topical with COVID: https://www.flyertalk.com/forum/united-airlines-mileageplus/...

(If HN has any ideas about what else we should write about, let me know! I'm david AT retool.com)

I'm Tim, and I lead airline partnerships at [Duffel][1] (YC S18) - although I'm an engineer by trade ;) We're building a new API platform to make it easy for anyone to sell flights (think "Stripe for travel").

We make integration simple with our beautiful REST API (no XML or EDIFACT) and allow anyone to sign up in 30 seconds, with no need to become an accredited IATA agent.

We're rebuilding the industry's infrastructure from scratch, with direct connections to 20+ airlines' systems using the new technology mentioned in the article, NDC, rather than going through the traditional GDSs like Sabre and Amadeus.

If you want to give our API a try for yourself, you can sign up on our website and book your first flight in our sandbox in less than 2 minutes.

Equally, if this sounds like an interesting problem space to you - we're hiring, so do reach out. My email is in my bio.

[1]: https://duffel.com

https://www.youtube.com/watch?v=1PHJkm_nNL8

Typing commands starts at 2:05 in. Watching this left me feeling like I was being taught how to use the "rm" UNIX command while logged in as root on a production machine that wasn't backed up and this was my final chance to keep my job.

Although the story describes in a technical way that the EDIFACT, XML, etc standards are cumbersome, inert, and resistant to change, I think the real story is somewhat external to the "code" level reasons. And it will also be a lesson (for the proponents of some change to any kind of standard) about why just a technically better solution doesn't always win.

Because, if you look at almost any standard, there's generally nothing stopping someone from proposing an alternative or better version. It's the adoption that's the tough part.

The more fundamental root cause of why this particular "bad" or outdated standard persists so long is that airlines are a very risk averse and capital intensive business. Any change -- especially one so fundamental as could interfere with their minute-by-minute booking engine (companies can lose billions if that system goes down) -- is highly risky. And it wasn't really built with incremental changeability or "hot swappability" in mind. Changing it involves retraining thousands of people, changing computer terminals, keyboards (with special character keys coded in plastic), practices, interfaces to yet other vendors. And when your company is burning dozens of millions of $ per day, that's something that you don't risk unless it's a strategic decision.

So that dynamic flows down into what your software vendors are incentivized (or become attuned) to produce or charge you for. Until there's some ground-level shift -- for example suddenly everyone needs to charge baggage fees -- no airline was actively asking for that capability to add on ancillary fees. And no GDS provider was seeking to innovate on it. Airlines simply wouldn't pay the extra for that unnecessary functionality... until they did.

Old, expensive, risky industry -- and that's why sometimes the change has to come from new entrants who aren't tied to these legacy systems. Although, and this is an even more involved topic, sometimes those new entrants find they have to tie into the legacy system to survive and get customers.

While it sounds horribly inefficient, I can't understand what sort of archaic process can make reserving a ticket a 1.5 hours task. Any ideas?

My first job was in that sector.

I learned a lot during that time. It was an enormous c++ codebase (as I remember it, millions of lines) and as much as I profoundly disliked some aspects of it, there were also a lot of interesting things. IIRC they had a pretty large platform team maintaining their own compiler and eclipse plugin.

One aspect of pricing (and availability, just because there are free seats on a plane does not mean they are available to you) that is not touched in that article is not multi legged flights are almost all the time deeply favored by the algorithm.

So if you absolutely NEED to go somewhere but the website shows zero availability, try to search for a multi leg trip including your intended destination.

Another place where this leaks through is if your initials are similar to "Mr", you'll get very strange tickets once in a while because the system doesn't actually have the components of your name in separate fields. It parses them from a text command.

The NDS change should solve all of these things, but it's a costly exercise so expect it to be delayed by the current downturn in the travel sector.

Timely :/

Side note, I can get faint hints of how this topic relates to Retool (eg, the GDS CLI is not a good internal tool), but it's pretty rare in my experience for a corporate blog to not try to shoehorn its own solution into the picture, and there's literally no mention of Retool in here. Kinda novel to just have a vaguely related exploration on a company blog.

Unfortunately, the booking part is almost the most pleasant aspect of it all.

Almost looks like Uber and Lyft!

While Uber and Lyft might not be as crazy-profitable as people had hoped, establishing a marketplace by connecting a large number of suppliers with a large number of buyers is a valid business. The other big commonality is that both air travel and taxis are low-margin.

Fascinating article, but the wild optimism about air travel at the end was almost creepy. Then I looked at the publish date, 18 November 2018.

When you see a person entering something like "flight from Istanbul to Moscow with a mandatory 24-hour layover in Frankfurt for a family of three" in under 5 seconds, your worldview is shattered :)

https://travel.stackexchange.com/questions/149323/my-name-ca...

HL7 for health information. https://www.hl7.org/

MARC for bibliographic information. https://www.loc.gov/marc/ https://www.loc.gov/marc/

XML has been the vehicle for attempted rework of these formats. I wonder, though, whether the time might be ripe for less cumbersome reworks, maybe using JSON with validated schemata?

Metasearches more or less killed OTA's since. Nobody cares about user experience anymore, if tickets are 1 dollar cheaper on some other OTA, traffic will go there.