Is SHARES a better system now vs years ago?
#16
Join Date: Sep 2010
Location: Chicago
Programs: Hyatt Glob; UA 1K; BonVoyage LTT (RIP SPG); HH Dia; JX Insighter
Posts: 1,643
Did UA invest materially more in those areas than AA/DL? The functionality of the underlying system presumably has an impact on what you can roll out, how quickly you can roll it out, and how much that development costs.
#17
Join Date: Nov 2002
Location: SFO
Programs: UA 1K MM, Marriott Gold
Posts: 4,768
#19
Join Date: Jan 2005
Location: New York, NY
Programs: UA, AA, DL, Hertz, Avis, National, Hyatt, Hilton, SPG, Marriott
Posts: 9,452
I think that's exactly true, and while I can't speak to what AA/DL invest in their IT platform, since the pandemic I fly AA/DL more than ever before, and United's self-service options are far and away the best for my needs. I think that is in part a consequence of United's systems architecture. Part of the reason to go with SHARES was the cost savings, as well, as United's license for the Apollo system was more expensive.
#20
Join Date: Feb 2005
Location: CLE, DCA, and 30k feet
Programs: Honors LT Diamond; United 1K; Hertz PC
Posts: 4,164
They've definitely improved the integration of the bolt-ons to the core system to reduce errors over the last decade, but I'm still having ticket sync issues ~monthly.
I don't think the decision to use SHARES vs Apollo was consequential to the UA web/app experience; the web/app experience relative to competitors is due to an incredible amount of investment UA has put into those interfaces.
I don't think the decision to use SHARES vs Apollo was consequential to the UA web/app experience; the web/app experience relative to competitors is due to an incredible amount of investment UA has put into those interfaces.
I don't think it's hugely consequential but I do feel like it gave the new UA a bit more of a running start because a lot of the tools that I don't feel are well duplicated (detailed flight info/seatmaps outside of booking flows, where's this thing coming from, etc.) existed in some from in the CO world... of course they've evolved and continued to improve over the decade but I remember being immensely frustrated trying to do things in United-land during the post-Star Alliance but pre-integration age and I think it would have taken longer to get back to the same point (if even possible with Apollo's architecture and licensing) with pmUA's systems. But I'm kind of the "I like the color of my grass just fine, why look at the other side" mentality on this one.
#21
Join Date: Feb 2005
Location: CLE, DCA, and 30k feet
Programs: Honors LT Diamond; United 1K; Hertz PC
Posts: 4,164
I think that's exactly true, and while I can't speak to what AA/DL invest in their IT platform, since the pandemic I fly AA/DL more than ever before, and United's self-service options are far and away the best for my needs. I think that is in part a consequence of United's systems architecture. Part of the reason to go with SHARES was the cost savings, as well, as United's license for the Apollo system was more expensive.
#22
FlyerTalk Evangelist
Join Date: Oct 2006
Location: SFO/SJC
Programs: UA Silver, Marriott Gold, Hilton Gold
Posts: 14,889
I'm a little foggy on this but I seem to recall the "old" United -- in addition to paying relatively crazy licensing/support fees for Apollo had a contract to migrate to a new-to-UA (and more SAAS-oriented) GDS -- I want to say it was Amadeus -- and that got killed as part of the integration so I think those coming from the pmUA side were going to be in for a transition/migration of some kind anyway -- whether that was Apollo -> SHARES as wound up happening or Apollo -> Amadeus as would have been virtually inevitable if the merger had never happened. Now the "Could have" "Would haves" can run rampant -- some of the development in Aero/Jet that UA has done may have been avoided with off the shelf tools from Amadeus but then UA wouldn't have that ability to differentiate itself. Likewise for all of the foibles of UA.com I feel that it's immensely more powerful than those of Amadeus-hosted carriers. How much of that is a platform capability vs. airline desire (and vs. my familiarity with the platform) I honestly have no idea but I hate servicing my reservations anywhere else.
with regards to Amadeus, yeah, UA was supposed to move to that - which was what *A was encouraging to have as many carriers as possible on the same platform. My understanding was management seemed to think they had more flexible ways to use SHARES so it was better for them - read: that meant more ways to charge for things like E+, upgrades, subscriptions, etc. not sure if that is still the case now, but at the time, that’s what they seemed to say. For me, the issue with not being on Amadeus is that most of the other * carriers (or at least most that I have flown) have transitioned to Amadeus by now - AC, NH, LH [all group carriers], TG, TK (I think), SQ, etc. - even AI has announced they are transitioning. That means when flying on combined itineraries on these carriers, the experience is more seamless than with UA and one of these. I also recall one of the arguments against SHARES was that UA was going to be the only carrier still using it (US Air was, but they transitioned out at the AA merger). And the difficulty in getting, for examples, programmers vs. other systems which are much more in-use.
honestly, the entire airline world is running on antiquated software - many systems built on top of systems from the 1960s and 70s - would be nice to build a brand new system based on modern technology (not just for UA, but really, industry-wide). How much longer are the current, outdated systems really last? I know there will probably a visceral reaction from some, but I kind of wish an Apple or Google (doesn’t have to be those two specifically, but a company like them, at least) that could build a modern, next generation, user-friendly system that works for all of the industry, carrier and passenger sides. I’m skeptical this will ever happen, at least in my lifetime, but would be great to see something like this.
#23
Join Date: Feb 2005
Location: CLE, DCA, and 30k feet
Programs: Honors LT Diamond; United 1K; Hertz PC
Posts: 4,164
honestly, the entire airline world is running on antiquated software - many systems built on top of systems from the 1960s and 70s - would be nice to build a brand new system based on modern technology (not just for UA, but really, industry-wide). How much longer are the current, outdated systems really last? I know there will probably a visceral reaction from some, but I kind of wish an Apple or Google (doesn’t have to be those two specifically, but a company like them, at least) that could build a modern, next generation, user-friendly system that works for all of the industry, carrier and passenger sides. I’m skeptical this will ever happen, at least in my lifetime, but would be great to see something like this.
Some of the newer/don't-play-nicely-with-others airlines have started on more modern platforms that are cheaper to run but also more limited with things like interline eTicketing (IET)
I think the problem with "clean sheet"-ing something comes down how mammoth of a project it is and how small a market it is -- first you have 70 years of accumulated features (plus bugs that have reached the level of feature through simple seniority), edge cases, truly odd purchasing/fare rules, etc. that you have to evaluate and translate to something new, then you still have to support all of the legacy interfaces for all of the partners you may interline with (unless you do the "not in my sandbox you don't" route which may be fine for a non-inspirational domestic carrier but would truly be limiting for a carrier with international aspirations or limited domestic markets and fleet of your own -- how MIAT, the Mongolian flag carrier pulls it off is amazing, IMO) and you have to train everyone, and you have to try to do open heart surgery and not completely botch everything during a live transition (if you could completely shut the airline down for, say, 48 hours that would make things a little easier... but that's unlikely to happen) the ROI and risk-reward becomes questionable, compared to a system that mostly works 100% of the time that has and can be iterated upon relatively gradually and even the overlays that agents interact are non-destructive -- UA can roll out Jet without impacting Aero users, and rolled out Aero without impacting native SHARES users (and when Aero or Jet misbehaves agents can still revert to the less convenient but still working underbelly).
If it makes you feel any better a lot of the standards that make the Internet work are, at their cores, reaching similar ages -- and have been incrementally enhanced over the years and have some of the same problems with attempting a whole-sale change. The major difference is that the Internet was designed as distributed everything whereas Shares comes from a real-time monolithic processing model
(But this is just what an aviation technology geek has pieced together over decades of trying to peer behind the curtain. Completely ready for someone to tell me I'm insanely wrong in my suppositions and analysis)
#24
Join Date: May 2017
Posts: 2,279
IIRC the actual compute platform SHARES is running on is a relatively modern architecture -- still with 60s/70s roots however. Heck most of the inter-airline messaging though routed over IP networks is still at it's core based on teletype messages. In a way Google already is in the mix -- when you buy a ticket on ua.com the pricing engine is driven by ITA software, a Google company, though still filtering down to SHARES for the actual ticket purchase and fufilment.
Some of the newer/don't-play-nicely-with-others airlines have started on more modern platforms that are cheaper to run but also more limited with things like interline eTicketing (IET)
Some of the newer/don't-play-nicely-with-others airlines have started on more modern platforms that are cheaper to run but also more limited with things like interline eTicketing (IET)
The other option, which I believe UA has partially done (but not for the overall reservation), is you develop a system that runs completely independent of the historical industry architecture, but you have a separate interface to translate between your new architecture and what is being communicated with other airlines. But again, that opens its own can of worms, it's easy enough to "dumb down" your output so it can go in your partner's systems by taking out whatever information doesn't fit properly, but what about the reverse, can't really "smarten up" the information coming from the other airline's system.
As a real existing example of this problem, take the middle name field. I can easily create a separate field for a middle name in my new system. John Jeff Doe, and when I send that to another airline's system (or my own internal system...) that doesn't have a middle name field, I'll just combine the first and second name sending them Johnjeff Doe. But working that in reverse, say the information is coming from the OA's system as Johnjeff Doe. How does my system know where it should split to make the middle name, since the OA's system has no way of communicating it by the nature of not having a separate middle name field? Is it Johnj Eff Doe, Jo Hnjeff Doe, etc?
So to bring it all back, it really comes down to, do you want to develop something new, with all the pain of new/cost development that also needs to still support historical systems. Or do you want to just build on what you already have? I know what wall street would want the airline to do. And in truth, absent a 3rd party organization they all subscribe to publishing new reservation/record standards with a cross-over implementation period, and managing the translation between those standards until the new standard is fully in effect, I don't think any airline is going to want to voluntarily go down that route.
#25
FlyerTalk Evangelist
Join Date: Mar 2002
Location: Saipan, MP 96950 USA (Commonwealth of the Northern Mariana Islands = the CNMI)
Programs: UA Silver, Hilton Silver. Life: UA .57 MM, United & Admirals Clubs (spousal), Marriott Platinum
Posts: 15,050
When travel agents called who used Apollo, it was much easier for us because we could see the whole PNR.
#26
Join Date: Feb 2005
Location: CLE, DCA, and 30k feet
Programs: Honors LT Diamond; United 1K; Hertz PC
Posts: 4,164
In the mid-1980s when I was a UA Reservations Sales Representative (RSR) at SFORR, the travel agents using the EA SystemOne referred to it as SODA. I don't recall what the last two letters of the acronym stood for.
When travel agents called who used Apollo, it was much easier for us because we could see the whole PNR.
When travel agents called who used Apollo, it was much easier for us because we could see the whole PNR.
My understanding is that more or less to this date the standard is that the native PNR will hold the 'whole picture' while the foreign PNRs in other platforms is only require to have the segment before and the segment after (e.g. if you fly UA AAA-BBB-CCC then LH CCC-DDD-EEE then UA EEE-FFF-GGG with the ticket booked on UA SHARES has to reflect all segments but LH (Amadeus?) is only required to reflect BBB-CCC/CCC-DDD-EEE/EEE-FFF. My suspicion is that that was an intentional tradeoff in the time of high-cost storage and slow communication links to allow the non-native airline to see where the passenger was coming from and where they were going without having to duplicate the entire PNR.
#27
Join Date: Jan 2007
Location: Bellingham/Gainesville
Programs: UA-G MM, Priority Club Platinum, Avis First, Hertz 5*, Red Lion
Posts: 2,808
As a real existing example of this problem, take the middle name field. I can easily create a separate field for a middle name in my new system. John Jeff Doe, and when I send that to another airline's system (or my own internal system...) that doesn't have a middle name field, I'll just combine the first and second name sending them Johnjeff Doe. But working that in reverse, say the information is coming from the OA's system as Johnjeff Doe. How does my system know where it should split to make the middle name, since the OA's system has no way of communicating it by the nature of not having a separate middle name field? Is it Johnj Eff Doe, Jo Hnjeff Doe, etc?
#28
FlyerTalk Evangelist
Join Date: Oct 2006
Location: SFO/SJC
Programs: UA Silver, Marriott Gold, Hilton Gold
Posts: 14,889
or, with this example, it doesn’t have to split it at all. Even today, UA has a middle name field, but when the name goes on the [UA] BP, it is Last/FirstMiddleTitle. Not sure if this is more the case of a newer (user-facing) system interacting with an older backend that issues the BP, for consistency with any OAL that may share the reservation (as other carriers squish the names as well), or some other reason.
#29
Join Date: Feb 2005
Location: CLE, DCA, and 30k feet
Programs: Honors LT Diamond; United 1K; Hertz PC
Posts: 4,164
or, with this example, it doesn’t have to split it at all. Even today, UA has a middle name field, but when the name goes on the [UA] BP, it is Last/FirstMiddleTitle. Not sure if this is more the case of a newer (user-facing) system interacting with an older backend that issues the BP, for consistency with any OAL that may share the reservation (as other carriers squish the names as well), or some other reason.
I've heard various reasons including that the - is a 'command key' (see my example in one of the first few posts to check a passenger in/issue a BP) but for whatever reasons it's not supported. I think this may actually date back to the pre-computer telegraph era as the 1910 Scientific American Handbook of Travel that I'm currently reading makes reference to not being able to send - in telegrams, so possibly that carried forward and someone in the 1960s was like "Welp, if it can't be sent in a message, we can just repurpose that key for our uses" -- and here we are 100+ years later we're still dealing with the lowest common denominator of systems and bad error handling.
Getting this back to UA **some** of their systems are very much aware of the hyphen (like MP) but at least early post migration what they did with it was very inconsistent after that: Sometimes it got preserved -- like the incessant credit card mailings, sometimes it got replaced with a space [my least favorite handling because people tend to assume it's a middle name], and sometimes it got deleted entirely. Since then they seem to be more consistent: If it's a credit card offer the hyphen stays, if it's anything else it gets tossed.
But you take those challenges and multiply them across all of the possible data points and all of the quasi-autonomous entities and business processes implemented for a paper era and... Wow. There are days I'm amazed that Interline eTicketing happened -- but that likely only happened because all (or a sufficient majority of the self-interested autonomous entities realized how much money they could save if they hopped on that bandwagon. And remember CO with SHARES was one of the first 'network' airlines to really and completely embrace eTicketing at a large scale. And without eTicketing the business processes to support so much of what we love (instant ticket exchange/self-service rebooking, mobile boarding passes, ...) largely wouldn't be possible, at least in the form we know them today. Of course Apollo wasn't long for the bandwagon either...
*- That I've come across, at least
#30
Join Date: Jan 2007
Location: Bellingham/Gainesville
Programs: UA-G MM, Priority Club Platinum, Avis First, Hertz 5*, Red Lion
Posts: 2,808
Names are just generally problematic. For example I have a hyphenated surname with part that is incredibly common and part that I think there are fewer than 15 of us on the planet (think Smith-Dgerersedf though obviously not that). No airline reservation system on the planet* supports a hyphen in a name field, so my boarding passes always come out as SMITHDGERSEDF/LINCOLN(middle), but some systems want the exact name from the ID, etc. and then they both barf on each other because obviously SMITHDIGGERSEDF is not the same as SMITH-DIGGERSEDF so we can't validate the name. I had this happen in real life in the early days of TSA when an overzealous agent at DTW freaked out that the name on my driver's license didn't match the name on my BP and wasn't going to let me through... A supervisor finally listened to reason that a single, non-alphanumeric, character difference probably was nonconsequential. It happened once more somewhere else, but hasn't happened since so I assume that may be covered in training.