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!
Best known for the globally adopted industry-standard travel specifications, OpenTravel is also home to a robust tool kit that helps all parties of the travel ecosystem leverage and enhances the existing travel messaging.
Find us on GitHub
This Open-Source toolkit – known as OTM-DE – is available for download on the OpenTravel GitHub Repo. Designed to interact directly with OpenTravel specifications, it provides dev teams with a GUI to leverage, enhance and deliver OpenTravel messages.
Before we get into what is new, let’s talk about what the tooling can do. If you are already familiar, you can skip to the list of enhancements.
Check out all the latest on our repo and we look forward to hearing about your implementations and feature requests!