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.
There were fewer global outages when all of the functionality was on the TPF mainframes with dumb green screen clients.
Implemented and operated by in-house staff.
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-...
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...
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...
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.
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.
I'd rather fly on an airline that hasn't 'upgraded' core systems.