Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Airlines should band together and form working group to redevelop the old system in modern open source tech.

Yes it would probably take 5+ years to develop and roll out, but they can't keep maintaining these 50 year old mainframes that cost them tens of millions a year in downtime.



For what it's worth, it's not generally the mainframes that cause the outages. It's the distributed ecosystem where you need a bunch of disparate systems from different vendors around the mainframe, all coordinating, to be able to fly planes, sell tickets, process boarding passes, etc.

There were fewer global outages when all of the functionality was on the TPF mainframes with dumb green screen clients.


TPF mainframes with dumb green screen clients

Implemented and operated by in-house staff.


> Airlines should band together and form working group to redevelop the old system in modern open source tech.

It's surprising how quickly one can suggest a solution based on... what exactly?

Imagine a doctor prescribing "this new fantastic medicine" based on "patient is sick" description. While personally I'm all for open source this is not a silver bullet and should be carefully considered.

Joel had an interesting blog post [0] back then about Netscape rewriting their software.

[0]: https://www.joelonsoftware.com/2000/04/06/things-you-should-...


I'm willing to commit to a serious effort in this area if anyone wants to collaborate - email in profile. I've been digging in to real time logistics for my existing business recently anyway, previously founded a 3300+ hotel reservation network and contributed a lot of Wikipedia content around PNR records and their political background/intelligence use, so have some familiarity with industry structure and protocols, and built and defended HA 24x7 transaction infrastructure for a major Bitcoin exchange. I would seek people with more experience close to or inside the major booking networks or airlines as collaborators.


Redeveloping large, complex systems in anything, let alone "modern open source tech", is much more difficult and prone to failure than one may think.

There are many factors that contribute to these difficulties, but tech is not near the top of the list.

There are many cautionary tales, including the $8-billion FAA AAS system rewrite failure [1].

Contributing factors include

- Regulatory processes

- Subcontracting

- Project management

- Politics and turf wars

- The extreme difficulty of reengineering a complex system when few, if any of the original designers and developers are driving it [2].

[1]: http://sebokwiki.org/wiki/FAA_Advanced_Automation_System_(AA...

[2]: https://www.dropbox.com/s/n0nud2xp2a9bxjo/Programming%20as%2...


"Redevelop the old system in modern open source tech" is a tough sell when so many of these airlines are differentiating on technology. Myself and many other frequent fliers will not engage with companies with poor functionality and bad UX. We move or stay loyal when airline tech allows us to do & see most of the things we need.


Their tech is not open enough to even allow for proper innovation and differentiation. That's the main issue with legacy IT.

When you live in a world w/ Docker, REST (and every other open tech there is), you can build systems which are way more innovative.


When you live in a world w/ Docker, REST (and every other open tech there is), you can build systems which are way more innovative

That's quite funny because Docker and REST are just half-arsed reinventions of mainframe features from the 1970s.


I completely get where you're coming from, but you also have to acknowledge for example that Docker is open source.

That's not a trivial add-on to IBM mainframes, it provides every developer (w/ minimal resources e.g a laptop or free tier cloud service) the ability to run production-like environments.

Sometimes, we take that for granted, but having worked for an airline IT, I noticed the bottleneck didn't come from hard algorithmic issues (most advanced route features were very basic to implement), but from the huge leap between production and dev environments: this was not Ubuntu on a server VS a MacOS on a laptop (manageable...), this was Ubuntu VMs (so should be close to prod?) vs cryptic data center clusters that had impossible-to-replicate features.

As for REST, airline IT use an outdated messaging mechanism. It implements versioning and grammar, so should be clean and nice to work with? Not really... The messages were impossible to read for an inexperienced dev (opposed to XML or JSON).

I heard plans to put JSON blobs in one of the fields of the messaging mechanism (completely destroying the value of versionning and grammar btw). That was not necessarily a bad idea, just a reaction to the lack of supported tooling, and readability for an obscure messaging mechanism.

Again, I get where you're coming from, but I'm just allergic to nostagia for the sake of nostalgia where the old features clearly lacked essential features for 2017.


They can build a open-source back-end and differentiate in the front end.

Or even build common components/ technologies together and then build their back-ends on top - that is basically what the rest of us are doing...


Is that not how Amadeus happened?


Yes, they should build an even bigger system with more requirements from each of the airlines, and have the same consulting company implement it. What could possibly go wrong?


You think these organizations can agree upon anything deeply technical?


redeveloping legacy systems (innovation) is a concept that is diametrically opposed to reliability.

I'd rather fly on an airline that hasn't 'upgraded' core systems.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: