"Airlines are very much currently burdened with a legacy that was cemented in sometime in the 50's."
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.
Sorry, I possibly stated that poorly - what I meant was: The current state of duopolistic airlines technology suppliers means that there may not be sufficient motiviation to evolve the capabilities of the old systems.
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.
"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.
> The current state of duopolistic airlines technology suppliers means that there may not be sufficient motiviation to evolve the capabilities of the old systems.
So then what is the motivation to change this now? This seems like simple economics to me.
Is the legacy only technical? I was speaking of something far broader than just the database they're using at the heart of something.
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.
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.