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 OpenTravel specification contains the building blocks for business functionality.
With interoperability at its core, the specification’s object model design spans numerous travel segments.
OpenTravel Messaging is designed to reuse elements across travel segments so that there is an easy to understand architecture that facilitates partnerships and ease of integration.
In addition to established suppliers, including airline, car rental, and hotel, OpenTravel schema products support emerging segments such as day tours & activities, golf, and ground transportation.
Since 2001, OpenTravel has built, promoted and evolved the data messaging standard for the travel industry. The combined efforts of all of our stakeholders over the years have resulted in a unifying specification that has been implemented by hundreds of travel companies – representing thousands of brands and properties – worldwide to create commercial solutions.
Millions of messages are exchanged every day using OpenTravel schema…
|
|
OpenTravel is pleased to announce the 2019A 2.0 Object Suite Specification is available for public review. This release is primarily focused on hospitality and includes the messaging for pushing hotel content as well as requesting full or partial hotel content and responding to that request.
OpenTravel welcomes your comments, which can be entered here .
The member review comment period will end on Friday, Dec. 13, 2019.
This release contains messaging for the following functions:
To download the specification please click on the following link:
Public Review – 2019A 2.0 Specification Publication
Thank you to our hospitality content project sponsors Marriott and LinksRez and to all of the many companies that participated in this effort. Without our member companies these specifications would not be possible!