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!
OpenTravel is partnering with the Open API Initiative to fight API chaos in travel.
Stu Waldron is the chief technical advisor for OpenTravel and has decades of experience integrating numerous suppliers into the API ecosystem. Stu is also the leader of the travel special interest group (sig-travel) at OAI.
Today’s traveler is increasingly shopping for an experience, not just a seat on a plane or bed in a hotel. In fact, the travel experience begins from the booking environment itself where consumers expect a single portal to connect across travel providers and travel retailers. People are looking for the convenience and value of the delivery and ride sharing apps that they use in their day-to-day lives and want that applied to the travel experience. The reason the travel industry as a whole has lagged behind modern expectations is because it has lagged behind the latest technological trends.
Easier Said Than Done
The process and protocols largely used today between providers have their base in travel standards agreed to in the 1960s and modified over time. Initially created to address airline interlining, allowing a single ticket to include flights on multiple air carriers, they have been pressed into service across the travel verticals. As time has gone on the once workable solution has begun to show its limitations. There are multiple efforts in the industry to break with the past and pursue an approach where a travel offer may be handled much like any other retail offering in the digital space. Travel however has some unique needs as products are transient (an empty seat is worthless after departure time) and in most cases specific to location (airplanes must land at an airport). Also, in most cases a travel product must be combined with another travel product to satisfy a request to create a trip. Creating an end-to-end journey implies a combined offer from multiple offers proposed and/or serviced by multiple providers. This adds a level of complexity, maintaining relationships between offers, other retail categories avoid. Focusing on the experience as a new approach to travel retail requires a new level of interoperability amongst participants in the travel market.
Addressing Interoperability to Open Up Opportunity
Solving the issues to support experience based, total trip, retail at scale could unlock massive economic opportunities for many of the current distribution channels operating today or create new ones. Mainstream distribution channels focus mainly on air which in the US had a total operating revenue of $120[1] billion. However, the total US travel revenue for 2019 was $1.1[2] trillion. Much of that figure is consumers figuring out for themselves how to make arrangements, a huge, missed opportunity to leverage automation. To build the experiences people are looking for, outside of immediate travel and lodging portals like Expedia, consumers are bouncing between websites and calendars to find restaurants, museum passes and jet ski rentals. The reason we aren’t seeing a wider variety of offerings is not hard to understand: For the mainline distributors it’s not worth the effort to connect, maintain and monitor small suppliers thru bespoke APIs. By unlocking interoperability, providers of travel products and services would have access to channels they are currently shut out of due to costs and complexity. The public is eager to get out of the house and experience the world again but would like to avoid the odious task of DIY travel orchestration and management. They want experience led retailing which industries like hospitality are investing in but only at the property level, not at the full trip level. The travel industry cannot afford to allow API chaos to continue to be a barrier to more effective retailing.
Getting Alignment on the Solution
In response the OpenTravel Alliance (OTA) and the OpenAPI Initiative (OAI) will work together to focus on API conventions and standards, not just messages. Within OAI, there is now a special interest group to focus on travel issues (#sig-travel). The travel SIG will be the conduit for the needs of the travel industry that pertain to the OpenAPI Specification (OAS). The OAS is a broad specification intended to help developers solve real world business issues with as much flexibility as possible. What is needed for interoperability and to reduce API chaos and hence distribution costs in travel is more consistency in API behaviors. OpenTravel will take the lead on providing open-source tooling and publishing reference architectures with refence implementations that adhere to the OAS. OTA 2.0 with its model driven approach will form the basis of this more comprehensive approach that supports all travel verticals. This will be in cooperation with existing travel standards bodies and trade associations. The overriding goal will be to lower the cost of connectivity to publish, acquire, distribute, and market digital travel products.
For more information on the OpenAPI Initiative and #sig-travel, join the conversation on slack. https://open-api.slack.com/archives/C0122NPKUR2
If you need a slack ID, go to: https://join.slack.com/t/open-api/signup
For more information on OTA 2.0, including becoming an Open Travel member, go to www.opentravel.org or contact Jeff ErnstFriedman at jeff.ernstfriedman@opentravel.org.
[1] Source: Phocuswright White Paper, Air Sales and the Travel Agency Distribution Channel April 2019
[2] Source: U.S. TRAVEL AND TOURISM OVERVIEW (2019), US Travel Association.
FROM: GLORIA GUEVARA, President & CEO of the WTCC
No one can doubt that we are in uncharted territory. The coronavirus pandemic means the world is facing a threat on multiple fronts not seen in peacetime. The Travel & Tourism sector is uniquely exposed, and we estimate 50 million jobs globally are at risk. To put it bluntly, Travel & Tourism is in a fight for survival.
Travel is the backbone of economies around the world. It brings in essential currency and inward investment, creates jobs and stimulates every sector. WTTC figures show Travel & Tourism contributes to 10.4% of Global GDP and 320 million jobs. It is responsible of creating one in five new jobs and, for eight successive years, has outpaced the growth of the global economy.
View the full letter from WTTC here (pdf).
The OpenTravel Alliance member LinksRez announced it has received NDC Certification Level 3. IATA New Distribution Capability – or NDC – is growing adoption amongst airlines and has similar functionality to OpenTravel Messaging. By achieving this certification, LinksRez will advance the OpenTravel mission of interoperability across the entirety of the travel vertical.
“LinksRez and OpenTravel are at the forefront of interoperability and is excited to be in a position to bridge the decreasing gap between OpenTravel Messaging and NDC,” said Brian Bell, President of LinksRez and member of the OpenTravel Governing Board. “For over twenty years OpenTravel has been promoting the adoption of data messaging standards in the travel industry and is excited to strengthen alignment between IATA and OpenTravel.”
The dev team at LinksRez is a regular contributor to OpenTravel workgroups evolving data messaging standards specializing in hospitality, golf, ground transportation, and air. LinksRez is a member of the OpenTravel Alliance and IATA.