Hacker News Reader

Comment by neilv | Hacker News Reader

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.

View on HN

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.

It's not a duopoly.

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.

>Did you know that Sabre charges their customers on a per-API call basis?

The original cloud service!

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.

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.

Reply on news.ycombinator.com