Case in point: Regardless of whether Sabre/Amadeus have replaced their legacy layer with some sort of nosql, I can absolutely guarantee you that many of their primary APIs are literally screen-scraping terminal sessions and returning the screen as XML.
True, but TPF is scalable enough that it doesn't matter. The API is responsive, flexible, and handles the traffic. The ugliness isn't limiting new functionality, etc.
We spend very little time talking about the cruft at the bottom. The business complexity is more important.
Things like fare classes, discount codes, availability, fare basis codes, reaccommodation, and so forth. If it were all written in rust or Go + microservices it wouldn't be any more straightforward.
Your product seems to confirm that. You aren't reducing that screen scraping any. But you're adding value.
So then what is the motivation to change this now? This seems like simple economics to me.
Our theories of place and travel are slowly changing due to new technical capability. Some of the lag is due to old theories embedded in old technology. But I think a lot of it is embedded in habit, custom, protocol, and business model. And in plain old not knowing. I expect we'll thrash around for decades before a new consensus emerges.
I spend more time fighting "this is how we've always done it" than I spend fighting legacy systems.
Sorry what is TPF here?
It's completely different from the most prevalent mainframe OS (zOs/MVS).
https://en.m.wikipedia.org/wiki/Transaction_Processing_Facil...
Think of it like nosql. High transaction rates, and high contention. Great when used for it's strengths, terrible otherwise. Close to bare metal, and hard to match for transactions/second with decades newer tech. The record sizes are closely matched to hardware I/O offload cache sizes. It's an I/O beast.
Imagine an OS built specifically to ignore things like private memory space in favor of specific dedicated drivers with intimate knowledge of specific disk and cache controllers to read and write as fast as possible, skipping the CPU whenever possible. And hardware -aware record locking semantics.
Personally, I find this common observation off base. Most airlines have pushed the legacy TPF layer into a sort of nosql data store. Both Sabre and Amadeus have been able to pull the business logic out of TPF.
Any sort of lagging technical progress seems more related to either thin margins, or the complexity you point out.
There's certainly room for innovation and improvement. I just hate the framing of the problem being tied to "old systems". It is mostly not true. Varies per airline, and res system, of course.