Personalized trip level experiences accessible from any device combining any travel product such as air, car hotel, cruise, rail, ground transportation, along with things to do, restaurants, golf, tours, conventions, amusements parks, at scale, meeting the needs of all travelers.
The travel retail industry is evolving to focus on delivering comprehensive experiences rather than just individual services. This shift necessitates enhanced interoperability among travel providers and retailers. Current protocols, rooted in standards from the 1960s, are outdated and insufficient for modern needs. The industry requires a new approach to handle travel offers as digital retail products, considering the unique characteristics of travel services, such as their transient nature and location specificity.
Addressing these challenges can unlock significant economic opportunities by automating travel arrangements and providing access to previously excluded suppliers. This proposal outlines the creation of an open-source foundation to revolutionize travel retail, fostering a community-driven approach to share costs and risks.
The travel retail market is ripe for disruption as many of the current constraints are rooted in legacy technology upon which business processes and revenue models were built. The latter making it extremely difficult for any one company or industry segment (air, car, hotel,,,) to unilaterally change. Opensource based approaches have had success in such scenarios as they pull together a community which act together to share costs and risk.
To meet the demands of travel retail today and in the future, the Open Travel Alliance is expanding its mission by becoming the Open Travel Foundation as part of the Linux Foundation.
At the Open Travel Alliance, our core purpose drives every initiative we undertake. Our mission and vision statements articulate the essence of our commitment and the future we aspire to create. They serve as the foundation for our strategies and daily operations, guiding our efforts towards achieving meaningful impact
Enhance the future of travel by enabling the transition of our travel industry members to digital retail supporting today’s app-based consumers demanding personalized solutions. Empowering members via message standards, reference architectures, and reference implementations to support their efforts to move to modern APIs and cloud-based solitons that in turn support digital retail at scale.
The Open Travel Alliance is a cross-sector technology enabler for the travel community providing open-source support for ubiquitous offers capable of omnichannel personalization that will remove barriers to the publishing and consumption of travel products. Any product, offered and sold on any channel, while obeying the supplier’s price and rules.
Curious to hear more? Visit our website where we will be posting more detail when it becomes available. You may also request to meet and discuss how the foundation will benefit your business on that same page.
Building on the November TTI post on offer/order standards, let’s look at what this could mean to travel retail.
In summary, the Open Travel Alliance would provide a standard on data structure, message schema, and offer/order minimum behaviors. Offers and orders would be containers that can accommodate any product, price, and rules such that the offer is actionable “as is”. That is, convertible into an order. This moves a majority of processing away from the data centre to the edge of the network (cloud based). Backends handle orders much as they do today. The actual shop functions would be competitive, using this universal offer capability, where the better ones win the marketplace. Details on how this works is in previous and soon, subsequent posts.
How this may affect the travel retail industry can be explained using an example of a prior disruptive change in technology. Prior to MP3 and MP4 standards, the music and video industry was very constrained. Products were brought to market in a limited number of ways that were tightly tied to consumption technology. In the “Boombox” era, you had vinyl, various forms of tape (reel, cassette, 8 track), CDs, DVDs, video disks, and a few others. This allowed companies to constrain distribution given the limited number of channels for distribution and make high profits. Nearly impossible for any creator to distribute on their own. Consumption was a little better as there was some competition between suppliers of devices capable playing the limited formats.
The advent of MP3 and MP4 standards blew the revenue model to pieces. Now anyone could publish and given no physical assets were needed (digital distribution), this was easy and cheap. Consumption was also unlocked as nearly any device could consume the product. Companies like Circuit City failed as the majority of their revenue was based on CD and DVD sales. Once those products were gone, they could not survive on sales of electronics alone. Record companies and others had to reinvent themselves as they could no longer control creator access to distribution.
Travel is still in the Boombox era. Most obvious is airline tickets which are still severely constrained on who can sell and process a ticket. Hint, they are value bearing documents even in eTicket form.
Not just anyone is allowed to print money. As many trips include an air segment, this is limiting who can be a travel retailer. Beyond legacy air there are constraints affecting everyone.
Everyone presents their product or service via proprietary messages and APIs. This is our above example of a half dozen distribution forms on steroids. There is some consolidation as distributors may pull in products from a dozen or more formats and pass them along with their own proprietary format. The main effect however is increased cost. Any company providing travel retail to the consumer has to deal with 1000s of proprietary formats. Even worse, pricing is hopelessly complicated with hundreds to thousands of possibilities, no MSRP, and no easily accessible rules on those prices.
The constraint on the industry here is very few distribution or retailing companies have the knowledge, talent, and funding to do travel retail at scale. Any startup originator of a travel product may create a set of APIs or pay someone else to use theirs, but no distributor or retailer is likely to pick up your product. Too costly to connect to your proprietary APIs given a very low profit opportunity. You may have just built your 100 bed hotel but that’s not near large enough for any major channel to connect to you. The ones who do connect will charge large fees to recover the cost.
The net for the traveler is you are constrained to a small number of retail outlets (online or apps) and what they can sell is a fraction of what is out there to be purchased.
As a travel product/service provider, this is a hard business to break into. Crazy high fees by those that will connect to you, and you are not likely to get to the higher value customers. To be a startup with a great idea for a killer travel app, you can’t get to much content without paying large fees to an established distributor.
Like MP3/MP4 for music and video, a universal offer with a standard data structure, message schema, and offer/order behaviours, removes these barriers. Anyone can publish their travel product/service cheaply and any channel/app can pick it up cheaply. This won’t fix airline tickets, that would be another long blog how to fix that, but this addresses the rest. It’s time to move beyond 80s and 90s travel retail distribution and revenue models. Time to ditch them with the Boombox.
Many non-profits for charity or standards bodies struggled to make it through the COVID crises. Members/donors pulled spending back for 3 to 4 years, only now in 2024 are there indications of putting back funding in 2025 budgets. OpenTravel has struggled since late 2020 but enough members continued their support to make it through the crises. Funding levels were low but despite the challenge, DEx and message updates continued. A dozen or more code lists updates were published while work on XML and 2.0 model (JSON) updates continued. There will be a new release of XML message soon and an OTA 2.0 release later this year. DEx security was enhanced and we set up a virtual desktop environment. This virtual desktop provides a ready to use sandbox for working with the 2.0 model, producing and testing resulting JSON APIs.
The OpenTravel website has been extremely busy. During this “down” period thousands of message/model downloads supporting hundreds of projects at hundreds of companies across 18 countries. This has provided high value to the travel industry.
However, this cannot continue at current funding levels, nor can new efforts be initiated to address the needs of the industry to move to JSON/REST and offer/order paradigms. In response to this need a group of travel industry leaders met on September 12th, 2024, to reboot OpenTravel.
The reboot will evaluate the needs of the travel industry to support digital retail via a more consistent approach to APIs. Companies using OpenTravel messages as a starting point for their JSON based API enhancements still leaves too many needless differences in API structure and behavior. We need more consistency between travel suppliers and consumers to work effectively with each other. The scope includes defining the capabilities and behaviors of offer and order approaches using well known, successful, open-source patterns. Once an approach to bring consistency to APIs and hence lower costs is defined, membership and funding models will be proposed. This may include becoming part of a larger existing open-source community. This would define globally how offer and order works for all travel retail with multiple open source offerings to help solution providers to speed up their own product plans.
Stay turned and check the opentravel.org website periodically to track progress or to sign up and be an active participant in defining the future of travel retail.
A trend in software development for many years now is spend less money and time in coding and testing and more upfront to define clearly what the product or service to be created actually does. If one was looking at a typical workflow of design and development steps, this would be shifting left in the workflow.
Some background in travel: Back in the 70s when I started in travel retail programming I had already been working for an airline for a few years. Most of the people I was working with also started outside the IT department. Some were gate agents or worked on the ramp, in hospitality many worked at properties. This was due to the fact there were not a lot of IT people out there to hire. Travel companies did a lot of hiring from within and had education departments to provide the IT skills. The result was 10 years down the road there were a lot of very experienced developers that also knew the business of the airline, hotel, car rental, rail and other companies pretty well. A fair amount of the product people were the same. Someone who started as a res centre agent was now defining the reservation capabilities needed to meet changing business demand.
Having this kind of shared experience between product teams and developers meant that product definition documents didn’t need to be too detailed. In fact most were fairly vague. But it worked as a product person could tell me what they wanted to see on the availability screen and I knew what they meant. I knew how everything on that screen already got there and so I knew what I had to do to add new data requests.
However, this happy arrangement didn’t last for long. As companies grew and now there were graduates to hire with IT skills from colleges, it began to fall apart. More so than the product teams, increasingly the developers didn’t understand the business. Vague product definition documents (use cases) were still the norm but developers had no idea what they meant. Years later, as development starting moving to outsourcing and offshore, this disconnect got much worse.
The result was a lot of design and redesign as acceptance testing was rejected by product teams as not what they asked for. Animosity between product and development grew and still seems fairly bad today in most companies. In developer speak we call this a context switch problem. Product owners and developers don’t speak the same language.
Product teams feel they are describing what they want clearly and developers find that does not actually tell them what they need to do. Developers, as they now do not know the business, don’t have the context to understand where the data needs to come from, what the relationships between data elements are, and many often unwritten use cases and roles that have to be followed (like when a plane crash happens, what data gets locked down). At many travel providers this ongoing issue has caused efforts to revamp the development life cycle and among several goals, attack the context switch issue. Most would have heard of moving to agile or even scaled agile (SAFe) which include efforts to shift left and use various means to touch base with product teams early and often. The goal being to find any disconnects with product earlier when they are easier and cheaper to fix.
These approaches found their way to API development with patterns like API first. Create a mock (wireframe) of what you think product wants via a set of lightweight APIs, probably with static data, to show the product team. Then iterate and build out from there. However this still is a pattern of repeatedly showing product teams some mock ups until they agree. It’s a workaround of the context switch issue, instead of asking are there ways for product teams to describe what they want that is easier for developers to work with.
There are practices and products for use case development that achieve this but it does mean a learning curve for many product teams. I know this as I led architecture teams as part of a move to SAFe and still struggled to get product teams change how they did use cases. There is another approach under development. As I mentioned in my last post, there is a new specification from OpenAPI called Arazzo. The spec defines how to describe how a series of APIs work together including the data. This will facilitate (AI based) tools that automate the workflow including code generation. What OpenTravel provides already are object (data) models that define the data with context (semantics) that is used to create the API description documents. For a single API, it’s a next step to add Arazzo.
Description documents are another, possibly large, step to the left for APIs. It’s easy to envision AI based tools that, with access to the object (data) models from OpenTravel, can know what data is available and what the semantics are. Tools that can work with a more conversational approach for product teams but producing the API description documents. I want to emphasise that point, product owners describe what they want largely as they do today. Those description document are in turn used for further automation to generate APIs and code for some mock tests.
Envision a process where product teams, with a little developer help, can iterate quickly by gradually updating their descriptions and immediately seeing what the result is. What’s being built now is the specification foundations for this between OpenAPI and OpenTravel. Tool providers are involved in the specification work while investing and updating their products to get to market as quick as they can.
Maybe we can get back to the 70s when product people and developers got along. Peace and love!
The OpenAPI Initiative, A Linux Foundation project, has announced a new specification that could have a large impact on travel API providers, and more importantly, API consumers (channel and apps). Travel may be unusual in that there may be more labor hours spent on consuming APIs than creating and supporting APIs. Think about it, every travel provider now publishes their products and services via APIs. Most are created by the travel providers themselves but often contracting out the actual development. Either way, they publish customized APIs. There are a lot of increasingly advanced API tooling available meant to increase the productivity of the API developer. But what about the API consumer? This group includes channels like online travel agencies but also the GDS, consolidators, TSCs, switches, and of course the suppliers themselves when they want to direct connect to another suppliers. Lets not forget startups trying to make that killer app to get into the travel retail market. I can speak from experience having been a VP of architecture at a major GDS the nightmare of being an API consumer in travel. Multiple thousands of availability APIs, each needing custom code as they do nearly identical work but data and format varies. What’s really varied is the workflow of a common booking flow (shop, avaibility, order, payment, fulfilment, etc.). Travel APIs at best, are described in a text document (PDF, etc.) which frequently is out of date and/or at a high level hence lacking the detail necessary. The docs often focus on the “happy path” and leave out many of the possible use cases. This leads to many hours of trail and error testing by API consumers to sort it all out.
OpenAPI already produces a specification which allows the API developer to describe the structure and attributes of the API. This is predominantly used by tool vendors to automate the process to publish an API for use. What has been added is a spec of similar design that allows for the description of the relationship of one API to the next. This spec describes the sequence of APIs and the passed data elements in a way that tool providers can start automating the workflow itself. Early use may be to allow an API consumer to easily see how a sequence of APIs work together in what is called a mock test. Down the road the automation will extend to the runtime itself by generating code that will handle the various use cases. Given the proliferation of similar but different APIs in travel, this approach can have a dramatic impact by lowering the (labor) cost to bring new travel content on board via APIs. Reducing the current very long lag time to onboard new content by a retailer. At OpenAPI, I run a travel special interest group working on prototyping common travel API workflows using the new spec. As we get those reference implementations done, they will be published on the OpenTravel website. I presented this and other OpenAPI activity on April 15th at the Linux Foundation Open Source Summit in Seattle. You can access the pdf at:
https://static.sched.com/hosted_files/ossna2024/a6/OpenAPI%20MiniSummit%20April%202024.pdf
The spec itself can be viewed thru the OpenAPI website.
Think of APIs as a means to transport your product, a hotel room, airplane or rail seat, tour, cruise, rental call, etc. to a consumer. That’s the sole purpose of publishing an API that travel distribution channels or apps will consume. The traveler no more sees the API than a customer in a grocery store sees the truck that delivered the crate of oranges.
In retail , I can’t find any product provider that builds their own trucks. There are those like Amazon and Walmart that brand their own trucks, but they don’t make them. Yet in travel retail it’s very common for product providers to build their own APIs to transport their goods. There are some analogies to my example with Amazon and Walmart for product providers that are hosted on a service provider’s CRS/PMS, but the service provider is building their own trucks (APIs).
The distributor of the product in my grocery store example builds one type, one instance of a loading dock that can handle any truck. This is because trucks are fairly consistent in their shape, size and attributes. If a truck manufacturer made a truck taller, longer, wider than others they would not sell many trucks. They would be useless to perform their function to deliver goods to most business who are not going to build a loading dock for this unique truck. This is true of any mode of physical transport one can think of. If the truck, plane, rail, bus, ship, etc. cannot be accommodated easily by the receiver, it’s useless. But that’s exactly what we do in travel retail with APIs. Everyone creates unique APIs to transport their products, travel commodities like seats, rooms, cars, berths, etc. expecting the receiver to make accommodations for each supplier. Most would agree that the competitive value or differentiation of the travel product would be in the service it provides and at what price, not by what the digital truck that delivered it looked like. Yet over the decades I lost count of how many product teams I have worked with that did, and still think, proprietary APIs are a good thing.
A travel distributor, such as a GDS, aggregator, TMC, channels or others, has to deal with 1000s of bespoke APIs. In effect making and maintaining instances of bespoke loading docks. Some instances have minor differences, some major. Either way, any time there is a change required to the software, a major testing effort is required to validate all the bespoke instances.
All this comes at a high cost which needs to be passed on to someone. It may be in higher booking fees, transaction fees, or other types of service fees. It also adds to throttling of shop/availability messages where over a certain look to book rate it’s not worth it to a GDS or other distributors to deal with you. Same is true for taking on content from smaller providers like boutique hotels or tour operators. API support and processing costs are too high to turn a profit without charging unacceptably large booking fees.
It does not have to be this way. Today there is not a full standard for travel APIs that would guide not only what the message looks like but how the API behaves. Attributes that in our truck vs loading dock use case would have the same effect. That is, attributes that would allow API consumers to have one loading dock that can handle the delivery of any travel product.
Consistency in how travel retail APIs work would not only save distributors and channels loads of money, it would also greatly reduce cost for travel providers (providers of the APIs).
This is not a failing of the existing standards bodies. OpenTravel, OpenAPI and others are ready to work together to solve this. It’s the prevailing narrative in the travel industry that proprietary APIs are somehow a competitive advantage and a means to retain market share as it is hard to change providers. It’s narratives that everyone should follow the air standard (including non-air), while rail, hospitality, restaurants, tours and others also think they, not air, have the best standard. For others, they are building their own silos and don’t care what anyone else does.
It is also the lack of understanding that while you may in fact deploy some great APIs, it’s still going to mean high labor costs to someone else just because you are different.
In closing, you may make a really cool digital truck to deliver your product. But if everyone one who wants to work with you has to build a custom loading dock, your cool digital truck is a barrier to commerce, not an advantage.
Community standards make travel retail work. Various organizations like OpenTravel, IATA, HTNG (now part of AHLA), the UIC, and others have provided the language by which travel organizations can work with each other to sell their products. There could be significant improvements in retail capability such as cross channel personalization of trip packages. This would take closer cooperation of the industry players to enhance standards and produce reference implementations of common API activities that are noncompetitive.
Standards bodies have traditionally been supported by the major players in industry verticals. Such as airlines for IATA, Hotels for HTNG, rail for the UIC. Major online channels have not participated all that much. In fact, very few consumers of the message and API standards participate in the creation and maintenance of standards. This is odd as there is far more labor spend on API consumption than API production. Much of the potential improvements to the standards along with reference implementations would be to the direct benefit of distributors and channels as they could greatly lower the cost to acquire actionable content. The use of XML and JSON message standards from OpenTravel is overwhelmingly by consumers of travel APIs. In the past 24 months there have been downloads by over 1000 individual users. This calculated by eliminating duplicate and missing email addresses. These by individuals working for hundreds of companies across 18 countries. However, there is no support for what is a community, nonprofit, effort by the consumers of APIs.
OpenTravel is rolling out a donation capability in the model of Wikipedia to provide an opportunity for those that are benefiting from the standards to contribute back to community. Working with partners like TTI to get the word out that standards and much needed reference implementations don’t happen on their own. Donations will be used to fund support for workgroups and the creation of JSON based object models by experienced modelers. This in turn supports the move of the industry to REST based APIs and away from bloated and stateful XML/SOAP messages. Doing this as a community would speed this transition and lower the cost of travel retail for all. Lower costs for content acquisition means more content in the retail channels. More commonality in API functions like identity management and how offers are constructed means enablement of cross channel personalization. No one player in the travel market can do this. It needs to be a community effort that is fairly funded by the community.
As explained in Wikipedia, “Game theory is the study of mathematical models of strategic interactions among rational agents. It has applications in all fields of social science, as well as in logic, systems science and computer science. The concepts of game theory are used extensively in economics as well.”
Said a little more plainly, game theory studies interactive decision-making, where the outcome for each participant or “player” depends on the actions of all. The interesting cases are when a group of people must decide to cooperate with each other or not given the possible outcomes. A commonly used example is multiple people are arrested for a crime. If no one talks, they may all get a light sentence as the authorities don’t really know who did what (lack of hard evidence). However each individual may decide to inform on everyone else. They would get no sentence and the rest get a harsh one. If everyone informs on everyone else, they all get a harsh sentence. Game theory is predicting who will do what and why.
How does this relate to travel retail? Currently travel providers and channels are creating bespoke APIs for retail that do pretty much the same as everyone else (shop, book, pay, ticket/entitlement). They could choose to cooperate on the non-competitive, technical, aspects of API development and delivery, such as taxonomy, syntax, message structure, callback functions, query methods, etc..
They could choose to use organisations like OpenTravel and TTI to create common use reference implementations to be shared by all. This would greatly lower the API production and consumption costs for all. This would not affect product, price or rules which can be unique per implementation but following a common architecture, it could actually enhance ones ability to compete as the money saved on redundant low level API work could be used for product and personalisation improvements.
However the industry does not cooperate where it makes sense. There remains a long standing notion that it is somehow an advantage to have APIs that are different from everyone else. Harder to adopt, hence harder to change partners, aka vendor lock in. That somehow their own staff, on their own, can create better APIs than anyone else and that will make a difference. That somehow offloading everything to a service provider will make them more competitive. That service provider would use their own bespoke APIs (lock in) across multiple travel companies but also the same product, price and rule capabilities. That latter being a concern for a travel provider as they may be limited on how they can differentiate their product.
Currently in travel retail, no one cooperates with anyone else. They all see the worse outcome, they all get a harsh sentence meaning high IT costs. Loads of redundant effort and APIs that make selling across channels or partnering to promote each other’s product extremely painful. If there was ever a time to take two steps back and use game theory to examine how cooperation may benefit all, it is now.
The industry is moving towards shared nothing architecture in order to leverage cloud computing (beyond simple hosting) and what truly distributed personalized retail could look like. Doing that in a bespoke way company by company won’t work. Reach out to OpenTravel at https://opentravel.org/contact-us/ if you want to dig deeper into how cooperation would work.
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.
Companies have been trying, and oftentimes failing, to get rid of legacy systems for decades. It was mostly an economic attempt to remove costs, but costs were often higher even where the migration happened. When it came to mainframe systems in particular, the replacement strategies failed to account for all the functions hosted and the real economics implied. Aside from major reservation functions, the mainframes sometimes hosted numerous other functions that were supported at a nominal incremental cost.
There was also consistency and reuse of the skills, tools, and operational infrastructure already in place due to the mainframe. We are not advocating to go back to the mainframe, but rather see it as a lesson learned. The lesson is to fully understand the architecture and the cost model of current state and future state when planning large strategic projects. The replacement of one, or a few, major business functions may leave other smaller but critical functions in a terrible cost and support model.
Another factor in legacy replacement is availability of skills, tooling, and operational infrastructure. It’s been hard for a while to find assembler programmers, and surprisingly hard to find C/C++ skills and tools. It is near impossible to find recent graduates of university that have been taught the necessary skills for programing and maintaining server functions (as opposed to client/user interface). In most companies, the age distribution of staff working on legacy systems is worrying at best, with most of the staff probably having AARP subscriptions.
Another large area of concern that does not get much attention is data privacy. The various system and data architectures in major use, until recently, were not built with data privacy for individual customers in mind. They were built to make sharing and exploitation of data across the enterprise and partners easier and faster. Security to the access of a database is relatively good, but not granular. Since the rollout of privacy standards like GDPR, travel companies have worked to understand where customer information is stored. Once documented however, is quickly out of date. For the travel industry, the data privacy and protection problem are not easily fixed in most systems older than 5 or so years.
Moving to the cloud following a REST architecture is a means to address these three areas. But there are large impacts that are a challenge to understand ahead of time. Costs are better for many functions that have seasonal highs and lows. However, this also means moving from a CAPX to an OPEX focus for accounting. Speaking from experience, this is not trivial. Just this one aspect illustrates a knock-on effect of fundamentally changing how things work, which affects many other teams in the enterprise.
The skills issue helps developers working on business function with modern tools, and many others as support and maintenance functions are passed to the cloud provider. However, this is also a major change in how things work. Data privacy and protection is now doable at scale as the cloud and REST imply a shared nothing architecture. The concept of a centralized database is replaced by views of business objectives defined around data privacy. Individual travelers and hotel or car providers have different views regarding trip level itineraries and wallet spend. Regardless, cloud/REST as architectures were defined with data privacy in mind.
In conclusion, there are more reasons than ever to move away from legacy systems and move towards what we call cloud native solutions. It is important to not underestimate how the fundamental changes will impact across the enterprise. The opportunity here is to cooperate as a travel community on many of these issues, rather than individually working to solve the same issues repeatedly. Individuals may think that they, or a designated vendor, have it all sorted out. But exchanging ideas may help find better (cheaper) solutions for known, and possibly unknown, problems.
A final word more on the point of OpenTravel. As stated, these changes have wide knock-on effects. These effects affect enterprises and customers and suppliers as well. Solving the many challenges as one offs represent unnecessary cost and risk.
Content By: Stu Waldron, Open Travel. (https://lnkd.in/d6FrRSTs)
Post/Edits By: Kristina Giacchetto, LinksRez (https://lnkd.in/eEz6SQxJ) (https://www.linksrez.com/)