It's not often I write about standards with my OpenTravel hat on, but I thought it important to share some ideas on where standards are going and why, more than ever, they are important to travel.
When my company first developed Rezgo we decided that we wanted open connectivity to be part of its DNA. We didn't want the API to be an afterthought or something we'd eventually get to when we had time.
We wanted to "eat our own dog food" and build an API that we would use every day, so we would know that it worked and we could share it with other developers.
But building an API, especially one from scratch is time consuming and laborious, so we decided to look around and see if anyone else had an XML API that we could duplicate or at least use as a starting point for our own.
You see, that's how most software companies work, they look for code that already exists and they re-purpose it so they don't have to re-invent the wheel. No one wants to re-invent the wheel.
One of the first places we looked was the OpenTravel schemas. Why? Because they are the holders of all travel messaging are they not?
Well, for us, they were not. Having found no existing tour and activity schemas that we could use, we eventually developed an entire set of eighteen XML messages from scratch.
But that's not the end of the story.
You see, when the opportunity arose, we chose to donate the schema for those eighteen XML messages to OpenTravel in order to jump start the development of standard messages for the tour and activity space.
"But that's your intellectual property, why on Earth would you open source it like that?" I hear you ask. Simply put, our intellectual property does not reside in the messages that we develop, it resides in the sophistication of the system that produces and consumes those messages.
This, it seems to me is the reason why the importance of messaging standards is shifting. You needn't look further than Google, Twitter, or Facebook to realize that making your application available through an API (most likely XML) can have a significant impact on its adoption.
In the early days of travel distribution messaging, the focus was of moving messages away from edifact and into a more flexible container, like XML.
What we saw, however, was a duplication of message structure only wrapped in XML tags versus in edifact format. Over the years, we've seen messages balloon to hundreds of elements each one dealing with a unique business need championed by one or two trading partners.
Even though the core OpenTravel messages are used by hundreds of trading partners millions of times a day, they are highly complex and not particularly easy to implement, and they were certainly not designed for the web, mobile, or the world of mashups that we live in today.
But with new opportunities comes change and a desire to evolve. At the recent OpenTravel Advisory Forum in Las Vegas, I saw fierce competitors leave their brands and business rivalries at the door and sit down together at working group meetings to talk about ways to make the standards better, not just for them, but for the industry as a whole.
During the Tnooz THack Vegas event, I saw small companies, in some cases individual developers, create applications that combined APIs from 2,3, and even 4 different data sources in a mobile web application that was built in a week with no budget.
I saw light bulbs go off, eyes widen, and hands come together in applause for what could be and for what is the connected web; a web where APIs rule, where XML is key, and where simplicity rather than complexity is the order of the day.
Later, a developer from one of the GDSs stood up and asked: "Why are we talking about APIs at a standards conference?".
Simple, I thought, because the practical application of the messaging standards that we strive to build and foster everyday are the APIs that use them.
The APIs, though many of them were not built on the messaging standards, should have been, if the standards supported lighter weight implementations.
Welcome to OpenTravel 2.0
No, it's not a take on Web 2.0 and has nothing to do with social media or the rise of user generated content. OpenTravel 2.0 is an evolution of the way the messaging standards we are developing are changing to better suit the interconnectedness of the web and the needs of lightweight applications.
The goal behind OpenTravel 2.0 is to make it easier for trading partners to use OpenTravel standard libraries to create messages, that are based on the standards, but specific to their requirements. It's innovative, timely, and relevant.
In the last two years, I've seen a shift happening in OpenTravel. The big messages like air, car, and hotel are still there and they still get a lot attention, but we're now seeing more and more demand from developers, just like me, who don't want to re-invent the wheel.
These developers aren't building mainframe programs, Windows Desktops, or apps for IBM AS/400. Most of them are developing web applications like hotel reservation systems, dynamic packaging applications, golf tee time booking platforms, and even insurance quotation systems.
The key, however, is that these are applications that live in an interconnected world, they co-exist with other systems, they feed and are fed by other applications and data sources. In other words, they all require messaging.
I'm excited by what I've seen. Don't get me wrong, there will always be competing interests and priorities, but having an organization like OpenTravel helps bring everyone to table and makes sure that the egos are checked at the door.
If there is one thing I have learned as the chair of OpenTravel, it's that a standard is only a standard if it gets used and OpenTravel based messages are used millions of times a day across the globe.