CLEguy

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.

JAaronT

You needed to put "Win" in your autoexec.bat

Bonehead

I probably did eventually. I loved autoexec.bat...

EWR764

Agreed, I probably experience the same issue at that rate, and I don't see that going away as it gets to the fundamentals of how SHARES handles a ticket. I would say that is my biggest criticism now, as over time most of my bugaboos have been substantially resolved, in my experience (instant ticketing, mileage credit, voluntary flight changes, rebooking to OAL, etc.).

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.

lincolnjkc

Of course it's likely a function of itinerary complexity and as a 90% domestic 1K mine typically aren't that complicated but I am noticing when something gets out of sync -- maybe once or twice a year IROPS expected more often than not if (I'm patient enough to) let it sit overnight it usually sorts itself automagically.

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.

lincolnjkc

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.

emcampbe

yeah, I’d say UAs system has most certainly improved since those rocky post-merger days. There was a bunch of stuff I liked better on the pre-merger UA web interface, but that is different than the backend - theoretically, most of the pre-UA front-end could have been connected to the current back-end. Some features may have been not useable on one vs. the other, but for the most part, probably would have worked.

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.

lincolnjkc

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)

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)

Lux Flyer

This is really what it comes down to, you need to communicate with the other airlines systems still, and you are therefore dependent on someone else for whatever change you want to make, depending on the system they use, even if you redevelop your own underlying architecture. Unless everyone agrees to change to this new architecture at the same time, to preserve interline communication, you still have to develop to support the historical standard. At which point, what makes more sense. Since you already have technology that meets the historical standard, you know how it works (and its quirks), and can just develop further, why would you risk the investment into something new that still needs to be able to meet the historical standard, on top of any new features you want it to do, but also have to deal with all the rest of the hassles that come with developing something completely new from scratch, with no guarantee you can ever sunset the historical standards holding you back since you still had to develop into this new software (because you're dependent on what your interline partners are using).

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.

SPN Lifer

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.

lincolnjkc

SystemOne Direct Access -- SODA -- was the name that SystemOne was marketed to TAs under -- iIRC SODA did have some limitations relative to what airline users could see/do (but -- again IIRC -- that was typical of all of he platforms competing for the travel agent's business whether that was SABRE, Apollo, SODA, PARS/DATAS, etc.)

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.

prestonh

Run the data through a series of logic checks and do loops. if it matches certain conditions, process it one way, if another, process it another way etc.

emcampbe

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.

lincolnjkc

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.

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

prestonh

if properly concatenated, the second string would equal the first string. I'm not seeing the problem.