ITA Software (acquired by Google) built its own non-mainframe GDS, and then ARS, which integrated into the legacy mainframe network.
If you just look up some of these concepts and protocols, it looks cryptic but doable, but it's harder than it looks, and there's also some less-straightforward opcodes. Although there's documentation, it's not always enough, and consulting experts from IBM was necessary. There was also building regression test suites from captured real-world protocol traffic, to verify that you can mimic the behavior of the parties.
Perhaps of side interest to HN: ITA stated publicly that they decided they had to use Lisp, to have the complex undertaking be tractable. Which meant they hired a ton of Lisp people, and got a lot of high-powered people who normally wouldn't want "legacy mainframe" anywhere near their resume.
This article was interesting because it described how Sabre and Amadeus came about in the first place, but (from my perspective as a consumer), they've done nothing incredible since the seventies. They did nothing but sit on their duopoly.
Even when the internet became popular, the first search engines (like Travelocity and Kayak) really sucked.
It wasn't until ITA Software came about that there was an honestly good and useful travel search engine. ITA is really the "technology that changed air travel" in the internet age.
And almost all online booking services are using the same duopoly with the same legacy tech anyway.
As with all B2B backbone systems, consumers are hardly ever aware that the even exist. Power grids, pipelines, shipping, ERPs, airline booking all are systems people ignore until something goes wrong. And those systems are shielded from consumers by multiple layers of middleware and middlemen that hide the complexity of things.
Good for consumers, the downside is that the actual knowledge of hoe things works gets more and more concentrated on a very small group of experts that have to keep the lights on while proverbial Jane in Accounting or Bob in marketing don't like the UI and tech bro Chad prevers to move fast an brake things with management assuming agile is the solution to everything.
Around 2007-2008, Sabre went on an acquisition spree and bought the major clients of Amadeus around the world. Then proceeded to force them to use Sabre instead (quite inferior results and heavily biased towards AA and other related companies). And finally when the 2008 crash happened, did massive restructuring and layoffs on such companies. Even for profitable ones. Some were sold afterwards for pennies on the dollar. The hit and run on Amadeus worked.
Got to love central bank backed corporations. (0% interest loans of unlimited amounts)
Sabre is an invincible Goliath. Amadeus is a David just trying to survive.
Source: I worked for one of those companies at the time.
Technically there's a third, Travelport, the smallest, and there are a few others that serve regional markets.
You're right that existing GDS systems have done nothing interesting for decades, though. Did you know that Sabre charges their customers on a per-API call basis? Airlines like to minimize the number of times they call into Sabre for that reason. You might imagine that the Sabre people are not especially motivated to make their API simple and modular enough to lower the number of calls required.
I can't decide what's harder, whether it is writing a non-mainframe GDS from scratch, or replacing 100% of a mainframe GDS by common Red Hat / Suse servers while staying 100% in business.
Also, most IATA standards I've read are littered by the statement "or a different convention by bilateral agreement between the parties" multiple times per page, so documentation only gets you halfway there. Having actual customers and defining how each customer deviates from the standard is the harder half.
When i read your note about "or a different convention by bilateral agreement between the parties", i immediately wondered jokingly that if math was "picked up" by business years ago, it might go somerthing like: 2 + 2 = 4 ...or resulting in a different sum by bilateral agreement between the parties...! lol :-D
I'm currently consulting on a project with Alaska Airlines and I can tell you that it's complex, but not in the way math or physics is complex. There are just a lot of details and a foundation of legacy going back to the 60s. For example, the details of EDIFACT[1] leak out far and wide, and the codes are still essentially the same. For example, the codes on a boarding pass[2] are essentially unchanged.
I don't know for sure that Lisp would be required (for the functional aspects?), but I can see the appeal.
As far as lack of documentation, it's not really any worse than any other field. Sometimes there's huge, detail-filled document from some organization like the IATA, with lots of revisions, sometimes the documentation is out of date, and some times it's missing. The worse problem is that all the original knowledge retired with people long ago, and the game-of-telephone version we have now is also walking out the door, because of pandemic-related disruptions in the travel industry generally.
It's a huge industry, and airlines are motivated by both profit and regulation to accommodate all kinds of things you wouldn't necessarily think of.
Speaking of profit, yes, extra bag charges, seat changes, and upgrades are explicitly revenue generators. They aren't just covering the extra cost, airlines will upsell you a variety of extras (would you like fries with that? some dipping sauce maybe?) in pursuit of profit.
Booking travel mostly meant you had to go through a travel agent and if you were doing anything off the beaten path (flight, cruise, major hotels), you probably wanted a specialist agency of some sort. Guidebooks and magazine articles were probably your main sources of information. This was all generally true as recently as about 25 years ago. Airlines also had ticket offices in major cities.
When entities like Expedia started coming online, it was a major sea-change. At my first job after grad school in the 80s, the company actually had a travel agent on premise in our main building to help employees book both business and personal travel.
It’s still worth using them for some trips. They know a lot, and booking anything even remotely complex online quickly becomes a hassle. As far as I have seen every large company still engages with travel agencies, although having humans on-site is Marne not that common especially post-pandemic.
I still miss it for biz travel to be honest. A typical input to a business trip is something like, "i need to be in Dallas for a 9am on Tuesday, SF for a team meet at 11 on Thursday and I have a call at 1230 the same day." Travel sites make the user futz around trying to find a schedule that works, is in policy, and isnt ridiculous. This can easily take an hour or more, even worse when multiple colleagues are involved. Much better to have a specialist do it who knows geography really well (eg Kansas City airport is not near kansas city), understands the corporate policy, knows your travel preferences etc. But no, we outsource the job to all the employees and burn their time instead. seems weird to me.
I remember when I was at Google (2013->15), the travel system was "gamified", and was an enormous waste of time. You had to come in at or below the median price for a trip. If you came in below the median, you could bank the difference and eventually use it to get a nicer hotel, first class upgrade, etc on future travel. And if you came in over the median, and had no banked credits, you had to get a VP to sign off on your expense report.
This all sounds great on paper, and I'm sure it reduced the travel expense line in Google's budget. But unanticipated effect was that you had engineers making mid 6-figure total comp spending way too much of their time finding travel deals so they could come in below the median. Talk about penny wise and pound foolish.
Except they don't really. I often like to see the tradeoffs laid out for me and, if it's not obvious, maybe spend a bit of time thinking about it--especially if I'm mixing in some personal time as well.
I also think you're attributing way too much knowledge to "specialists" at a generic travel agency. As far as they're concerned you can (as most people will) just grab a taxi from the airport to your hotel--or rent a car--however far. I doubt they'd know about BART from SFO to downtown and TBH most of my co-workers likely wouldn't even consider a transit option either even if it were basically as convenient as a cab, as in the example.
As I wrote in another comment there are specialist services that deal with mostly pleasure travel in particular locales but that's different from the traditional travel agent who mostly booked cruises, flights on major carriers, tours, and business or resort hotels.
Certainly agree that calling a generic agency would be a miss. You need in house expertise. It is certainly possible for a small slice of the business (I cant imagine that Satya or Sundar or Jeff spend hours on Concur or Expedia, say), but scaling that to cover the whole thing would be very valuable (and quite difficult).
They have executive admins (or multiple) and others who handle all the details--and they also don't expect to grab a few hours off for sightseeing unless that's explicitly part of their schedule. Otherwise they're probably eating breakfast, lunch, and dinner with customers. And, of course, that's not really scalable and I imagine a lot of technical people would absolutely hate to be working that way.
1.) Online booking systems are good for the 95% case (or maybe more). But I've spent way too much time wrestling multi-jaw international trips requiring non-major airlines into submission. To be sure, not sure how good our corporate travel would have been but maybe they'd have saved a lot of legwork and reservation would have been in one place.
2.) I've done things like long distance walking trips in England. Absolutely worth it to have someone book the places, arrange luggage transports, any shuttles, etc.
I had that, too. I wish companies still had someone to take care of it, but that went out the door along with all the other employees that existed to provide services for ordinary workers. No office manager, no secretary, no administrative assistant. Work says you have to travel? Prepare to spend half a day booking your own flights, accommodations, etc. Unless you do it all the time, even with the online tools we have now, it's just a pain.
This article takes me back to a time when I worked in Revenue Management for an airline. Amadeus was one of my mains tools.
One interesting aspect of the GDS is that they made efforts to have a better GUI, with point and click options, to facilitate the steep learning curve of the tool.
That effort was botched because of the existing use base was so well used to the DOS-like command interface that they simply ignored the GUI. A similar thing happened to Bloomberg and their terminals.
When I moved to tech and had to deal with experience revamps I always took this example with me. Even though you might have a better experience to users, do not underestimate the lock in of the current users to your existing UI.
Another great example of that is the now infamous Dig revamp....
A very few number of times, to younger direct reports on non-tech teams that i led, i've explained CLI as if it was a sort of google search (like google search hacking)...and i found that it helped them understand better. Apologies to all CLI zealots!
I'm laughing thinking of the Online Reservation System based on the Air Defence System. You have to wonder at some point did an IBM salesman or trainer say "Where you see 'incoming missile' that's 'new reservation'"
Not as funny, but rail tickets are available through the same GDS. It’s not straightforward to tell them apart from flights in the system, so you can occasionally find them when searching for flights on any travel website.
Air+rail is not uncommon in markets with sufficiently developed high speed rail and regional rail (HSR pretty much decimated the London-Paris market, for instance.)
There’s been a bit of a movement in Europe to ban short haul connections since most European hubs are connected to rail, the issue is usually that the connection leaves a lot to be desired (e.g. rail is not in the controlled areas of airports, often there is no baggage through handling)
Interestingly absent is a discussion about bots abusing these booking systems. GDS' usually have a look-to-book ratio threshold with their airline customers. If the airline (via end users and bots on its website) does too many computationally intensive searches without booking a flight, that airline pays overages per their contract with the GDS.
You can imagine how a third party entity would make constant searches for seat and flight availability, spurred by all the possible permutations of airports and flight schedules. This flurry of activity rockets up the number of "looks" to the number of actual "books".
These third parties might be Online Travel Agencies trying to get around their own contractual limits with the GDS, or it might be companies that sell the schedule and fare data as competitive intelligence.
For now, the GDS' and airlines try to solve the problem with anti-bot solutions to keep contractual overages low.
If someone could instead solve the underlying structural problem (computational intensity? cost of compute? cost of running a GDS? offer free fare and schedule data to all?), they could probably crack open a multi-million dollar market opportunity.
I was working for Air New Zealand part time while I was doing my MSc (~2000) which also coincided with when direct online sales jumped from being a niche sales channel to the airlines major source of revenue- I loved it so much I dropped out of school to work full time so this article was a great trip down memory lane.
AirNZ is a Sabre customer, and their travel agents used it directly for years, but had such a steep learning curve that they built a wrapper for it - still a command line system, but divided the screen into quadrants to display different colors information, and some macros that automated some common tasks.
Despite the simplification, it still took 2 weeks full time training before agents could use it, and even then the first week was as a buddy system where you had someone helping you for a week (most of that time was learning the system, but also included time to learn all the three letter airport codes and other acronyms used for reservations).
Some old timers would switch down to Sabre for complicated tasks because it was faster than using the wrapper and it was amazing to watch them interact with the system.
One colleague I worked with had been with the airline for nearly 50 years and remembered pre-computer days where the ‘booking system’ was just a big shared blackboard.
> GDS systems, however, did not adapt with them.
Air New Zealand was one of the earliest airlines to experiment with different fare classes (premium economy, ‘saver’ fares with no baggage etc) and better tools (flexible date search), I remember being involved with RFQs with Sabre and competitors to enable a flexible date search of +/- 3 days the quotes coming back for sometime like 9 months of development for a crazy amount like $2M. Maybe doesn’t sound like much now, but back in 2000, revenue from online sales hadn’t yet even crossed $1M per year, so that single feature cost more than 2 years of online revenue.
This was the incentive for AirNZ to invest early in their own internal software development which was a very smart move- as it allowed us to experiment and give customers features that even our larger competitor (QANTAS) couldn’t match.
I’m so happy I got to experience all of that- definitely the highlight of my career to date.
33 comments
[ 3.0 ms ] story [ 77.4 ms ] threadIf you just look up some of these concepts and protocols, it looks cryptic but doable, but it's harder than it looks, and there's also some less-straightforward opcodes. Although there's documentation, it's not always enough, and consulting experts from IBM was necessary. There was also building regression test suites from captured real-world protocol traffic, to verify that you can mimic the behavior of the parties.
Perhaps of side interest to HN: ITA stated publicly that they decided they had to use Lisp, to have the complex undertaking be tractable. Which meant they hired a ton of Lisp people, and got a lot of high-powered people who normally wouldn't want "legacy mainframe" anywhere near their resume.
Even when the internet became popular, the first search engines (like Travelocity and Kayak) really sucked.
It wasn't until ITA Software came about that there was an honestly good and useful travel search engine. ITA is really the "technology that changed air travel" in the internet age.
As with all B2B backbone systems, consumers are hardly ever aware that the even exist. Power grids, pipelines, shipping, ERPs, airline booking all are systems people ignore until something goes wrong. And those systems are shielded from consumers by multiple layers of middleware and middlemen that hide the complexity of things.
Good for consumers, the downside is that the actual knowledge of hoe things works gets more and more concentrated on a very small group of experts that have to keep the lights on while proverbial Jane in Accounting or Bob in marketing don't like the UI and tech bro Chad prevers to move fast an brake things with management assuming agile is the solution to everything.
Around 2007-2008, Sabre went on an acquisition spree and bought the major clients of Amadeus around the world. Then proceeded to force them to use Sabre instead (quite inferior results and heavily biased towards AA and other related companies). And finally when the 2008 crash happened, did massive restructuring and layoffs on such companies. Even for profitable ones. Some were sold afterwards for pennies on the dollar. The hit and run on Amadeus worked.
Got to love central bank backed corporations. (0% interest loans of unlimited amounts)
Sabre is an invincible Goliath. Amadeus is a David just trying to survive.
Source: I worked for one of those companies at the time.
You're right that existing GDS systems have done nothing interesting for decades, though. Did you know that Sabre charges their customers on a per-API call basis? Airlines like to minimize the number of times they call into Sabre for that reason. You might imagine that the Sabre people are not especially motivated to make their API simple and modular enough to lower the number of calls required.
The original cloud service!
Also, most IATA standards I've read are littered by the statement "or a different convention by bilateral agreement between the parties" multiple times per page, so documentation only gets you halfway there. Having actual customers and defining how each customer deviates from the standard is the harder half.
I don't know for sure that Lisp would be required (for the functional aspects?), but I can see the appeal.
As far as lack of documentation, it's not really any worse than any other field. Sometimes there's huge, detail-filled document from some organization like the IATA, with lots of revisions, sometimes the documentation is out of date, and some times it's missing. The worse problem is that all the original knowledge retired with people long ago, and the game-of-telephone version we have now is also walking out the door, because of pandemic-related disruptions in the travel industry generally.
It's a huge industry, and airlines are motivated by both profit and regulation to accommodate all kinds of things you wouldn't necessarily think of.
Speaking of profit, yes, extra bag charges, seat changes, and upgrades are explicitly revenue generators. They aren't just covering the extra cost, airlines will upsell you a variety of extras (would you like fries with that? some dipping sauce maybe?) in pursuit of profit.
1 https://en.wikipedia.org/wiki/EDIFACT
2 https://www.thesun.co.uk/travel/5703214/boarding-pass-codes-... although the trend towards electronic boarding passes and scanners means the letters and numbers are disappearing into the barcode or Aztec code.
When entities like Expedia started coming online, it was a major sea-change. At my first job after grad school in the 80s, the company actually had a travel agent on premise in our main building to help employees book both business and personal travel.
This all sounds great on paper, and I'm sure it reduced the travel expense line in Google's budget. But unanticipated effect was that you had engineers making mid 6-figure total comp spending way too much of their time finding travel deals so they could come in below the median. Talk about penny wise and pound foolish.
Except they don't really. I often like to see the tradeoffs laid out for me and, if it's not obvious, maybe spend a bit of time thinking about it--especially if I'm mixing in some personal time as well.
As I wrote in another comment there are specialist services that deal with mostly pleasure travel in particular locales but that's different from the traditional travel agent who mostly booked cruises, flights on major carriers, tours, and business or resort hotels.
1.) Online booking systems are good for the 95% case (or maybe more). But I've spent way too much time wrestling multi-jaw international trips requiring non-major airlines into submission. To be sure, not sure how good our corporate travel would have been but maybe they'd have saved a lot of legwork and reservation would have been in one place.
2.) I've done things like long distance walking trips in England. Absolutely worth it to have someone book the places, arrange luggage transports, any shuttles, etc.
One interesting aspect of the GDS is that they made efforts to have a better GUI, with point and click options, to facilitate the steep learning curve of the tool.
That effort was botched because of the existing use base was so well used to the DOS-like command interface that they simply ignored the GUI. A similar thing happened to Bloomberg and their terminals.
When I moved to tech and had to deal with experience revamps I always took this example with me. Even though you might have a better experience to users, do not underestimate the lock in of the current users to your existing UI.
Another great example of that is the now infamous Dig revamp....
All software is command-driven
There’s been a bit of a movement in Europe to ban short haul connections since most European hubs are connected to rail, the issue is usually that the connection leaves a lot to be desired (e.g. rail is not in the controlled areas of airports, often there is no baggage through handling)
You can imagine how a third party entity would make constant searches for seat and flight availability, spurred by all the possible permutations of airports and flight schedules. This flurry of activity rockets up the number of "looks" to the number of actual "books".
These third parties might be Online Travel Agencies trying to get around their own contractual limits with the GDS, or it might be companies that sell the schedule and fare data as competitive intelligence.
For now, the GDS' and airlines try to solve the problem with anti-bot solutions to keep contractual overages low.
If someone could instead solve the underlying structural problem (computational intensity? cost of compute? cost of running a GDS? offer free fare and schedule data to all?), they could probably crack open a multi-million dollar market opportunity.
AirNZ is a Sabre customer, and their travel agents used it directly for years, but had such a steep learning curve that they built a wrapper for it - still a command line system, but divided the screen into quadrants to display different colors information, and some macros that automated some common tasks.
Despite the simplification, it still took 2 weeks full time training before agents could use it, and even then the first week was as a buddy system where you had someone helping you for a week (most of that time was learning the system, but also included time to learn all the three letter airport codes and other acronyms used for reservations).
Some old timers would switch down to Sabre for complicated tasks because it was faster than using the wrapper and it was amazing to watch them interact with the system.
One colleague I worked with had been with the airline for nearly 50 years and remembered pre-computer days where the ‘booking system’ was just a big shared blackboard.
> GDS systems, however, did not adapt with them.
Air New Zealand was one of the earliest airlines to experiment with different fare classes (premium economy, ‘saver’ fares with no baggage etc) and better tools (flexible date search), I remember being involved with RFQs with Sabre and competitors to enable a flexible date search of +/- 3 days the quotes coming back for sometime like 9 months of development for a crazy amount like $2M. Maybe doesn’t sound like much now, but back in 2000, revenue from online sales hadn’t yet even crossed $1M per year, so that single feature cost more than 2 years of online revenue.
This was the incentive for AirNZ to invest early in their own internal software development which was a very smart move- as it allowed us to experiment and give customers features that even our larger competitor (QANTAS) couldn’t match.
I’m so happy I got to experience all of that- definitely the highlight of my career to date.