Jumping into our time machine, back to the days of ACP/TPF, most airlines and eventually car/hotels (and banks) gathered around a booking solution from IBM (ACP/TPF) and Unisys (USAS). This was due to the fact when one purchased a mainframe you also got a copy of the res system complete with application code.
Software as a revenue driver wasn’t a thing yet. Airlines were regulated so more likely to cooperate on non-competitive issues like IT systems. In the good old days, they competed on customer service. Once airlines were deregulated, IT cooperation deteriorated but some level of sharing continued for a few decades. The point remains that the overall pattern and for the most point codebases were common across the industry including large players in car and hotel.
Even when outright code was no longer shared, skills were as experienced developers moved around throughout their careers. Someone experienced on an airline system moved seamlessly to another airline and with only a minor learning curve to car/hotel. Some even jumped over to banking as they used the same TPF system. To be clear, this wasn’t just about one knowing the operating systems but unusually in IT, the applications themselves only had minor differences. Once you understood how a PNR worked in one company, it was 90% the same anywhere else. There was an undervalued reuse of people and skills not realized until it went away. Today I may know Linux well and all the common programming languages and DBs, but I’d be starting from scratch on the applications themselves. To a large extent, the travel industry was based on a community based, commodity, package of travel sales and management functions.
It’s worth mentioning that for the most part there are no off-the-shelf reservation or any related travel retail solutions. Despite there being over 450 airlines, a dozen large hotel chains, fewer car rental chains, a large number of rail systems, etc. it’s not a large market. We’re not talking about financial accounting systems where the market is 10s of thousands of large customers and innumerable mid to small customers for scaled down versions. The market for travel solutions is too small for any provider to make the huge investments necessary to deliver and support for the long term.
The pattern one will see is hosted solutions often reusing a system where that huge investment by a major travel provider was a cost of doing business over the years. Even today there are travel providers letting go of their legacy systems in favor of a hosted solution for base functions. There are nuances and exceptions to this to argue about but for the most part, this is the status of the base travel management function available.
The major investment in solution building tends to be the customer facing retail functions built upon that base. The trend is not to be open and share what any one travel supplier or channel is doing with other suppliers and channels. What I do with my retail functions is a competitive advantage, or is it?
Due to the history of travel solutions the process flow of shopping, booking, payment and confirmation (for some, ticketing) is still very common. The number one API called in travel is availability which is also at times called a shop function. There are hundreds and maybe over 1000 variations out there on availability APIs. It depends on if and how one chooses to group the APIs. One company may put out 10 APIs that expose slightly different options while anther puts out an omnibus API with loads of parameters. Anyway, the point is for the API consumer this is a nightmare; for the API provider, a ton of bespoke code to maintain at one’s own cost.
It’s a bad deal for all concerned as this represents a very large amount of redundant labour expense to support, along with tons of other APIs needed, largely with the same process flow to purchase a travel product. Over the past 20 years or so, 100s of millions of dollars have been spent by the industry to replace legacy messages with SOAP/XML messages. Hugely redundant efforts. This is happening again with the move to REST/JSON, only this time it is even more expensive as REST is really different and there is a shortage of developer and engineering skills.
Even if you can find the developers, there is a learning curve as they need to build solutions upon the travel solution history, with a lot of weirdness we have talked about. As an industry we should have learned from our “XML phase” but we are plowing ahead to make same mistakes on our “JSON phase”.
The alternative is to come together as a community to sort out how much of travel retail processing is not actually a competitive advantage but should be a commodity. Organisations are available to help like TTI, HTNG, HEDNA, IATA, OSDF, UIC and many others including OpenTravel. The point being we don’t have to invent new organisations to organise the community, they are already in place but need a new mission.
OpenTravel is focused on defining a common taxonomy and producing reference implementations of common functions at the API level. How one defines their APIs in terms of behaviours (like how security handshakes work) is not a competitive advantage. Other companies in the industry have the talent to define base functions behind the APIs. If the industry comes to some convention on base functions, that changes the calculus for IT providers. They can get more reuse out of their investment in a solution. This is the only way to really make an impact on labour costs and overall IT costs by greatly increasing the reuse of solutions in the industry.
Like the old days, compete on service. Compete leveraging new technology to enable personalization of offers. Compete on price and value. The vast majority of IT functions supported redundantly by individual companies or even hosted solutions is no longer a competitive advantage, just a cost of doing business that could be a lot lower.
