baby computer
1072 days ago
 

Open APIs in travel need to grow up

Open APIs (those that are freely or cheaply and easily available) are great – the travel industry has a long and checkered past with proprietary access to information that has, as most here will argue, stifled innovation.

That past also led to high development costs, slow time-to-market for new products and new partners, and continuing consumer frustration with the travel research process.

To support innovation and satisfy consumers, as Stephen Joyce points out in an earlier Tnooz post, APIs need to be open and fairly simple to use (and I would add scalable, but that’s another post). But I would argue we need to add one more adjective here – standard.

The proliferation of open APIs is a welcome change, but it’s a double-edged sword. It’s marvelous that access to data is so easily available, but now companies will have to write to multiple APIs if they are interested in aggregating similar products and providing unique offerings.

And if every API is different… well, shall we go back to talking about high development costs and extended time-to-market for new products and partners?

What is the problem?

Open APIs serve the needs of one company. Just one. And just because a company has an open API doesn’t mean it’s any good.

Sure, XML and other modern messaging languages are so much easier to work with than, say, EDIFACT, but every Joe and Jane out there now thinks they can write a decent message. And many of them can’t.

The obstacles that face companies trying to launch new business and/or products in an industry as noisy and competitive as travel – limited resources, lack of familiarity with the industry, pressure to launch – are daunting, so adhering to a voluntary distribution standard can, and does, fall down the priority list.

The attractiveness of writing an API that best serves the needs of your product, and writing it quickly to get it out there and into production so your company can generate revenue, can’t be underestimated.

I get that.

But what happens when your company moves past just getting your product to market, when your company needs to grow and move into new markets?

Here’s what will happen – when your product set or market expands into other segments in travel, one of the factors potential partners will evaluate is how rational it is to connect to whatever information or inventory is shared.

An open API will only get you so far. A standard API, created with the consensus of the industry in a transparent and collaborative process, will get you farther.

How?

The use of a standard message gives potential trading partners, up front, an idea of your API’s structure and validity. It also gives them an idea of the level of effort that will be needed to connect to your company.

The use of standard messages provides your company with technical credibility during the initial conversation with a potential trading partner. And credibility, especially for a start-up, is critical to being taken seriously by the market.

Setting a standard

Now let’s talk about how participation can benefit companies more than just writing to a standard.

Participation in a well-organized standards body is especially beneficial to smaller companies because in many standards bodies, including OpenTravel, each company (not each participant) gets a vote.

So small companies wield just as much influence as larger companies. Several small companies participating can also provide a common voice for requirements or considerations that are specific to smaller companies (for example, larger companies tend to like more complex messages).

And one can’t overlook access – standards bodies tend to be supported by large players in a given industry, players that smaller companies may not easily have access to.

In a work group meeting, your company works side by side with industry leaders in a collaborative and open environment, a perfect opportunity for your company to impress others with your commitment and brilliance… without having to cold call.

NB: Image via Shutterstock.

 
 
Valyn Perini

About the Writer :: Valyn Perini

Valyn Perini is a contributing Node to Tnooz and the Vice President of Strategic Relationships for Nor1.

She was most recently the CEO of the OpenTravel Alliance, where she oversaw the operations of the organization, including developing and executing strategies to reach the goal of standardized electronic distribution of travel and traveler information.

Her travel career includes stints with InterContinental, Westin and Swissôtel, with PricewaterhouseCoopers as a travel technology consultant, and as the director of product strategy for Newmarket International.

Valyn speaks on industry topics at events around the world, and writes about travel when she can find the time.
Originally from Atlanta, Valyn now lives in Boston.

 

Comments

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

  1. Judith Leist Blog | Judith Leist Blog

    [...] Open APIs in travel need to grow up [...]

     
  2. Timothy O'Neil-Dunne

    I will add a few elements to the industry debate. APIs need to be reliable. Too often reliability of the API means that the API needs to have extensions. XML was supposed to make all that possible. After all isnt that what the “X” was for?

    Open APIs have no discipline so people take them and modify them. Prior generations of “Industry” APIs have also been guilty of the same sin. Then they become “modified” APIs and dont work across multiple scenarios.

    Call me nostalgic but many of us in the old days used to work to the Lanyon standard on PC based APIs. SMTBF – who remembers that.A royal pain to work with – bBut it was consistent. One person owned it and made it work.

    Today we dont have in our industry verifiable APIs. This is something we need. Creating a standard is fine but we need to be sure that the darn thing works consistently. We need a reference test harness.

    So the next time anyone creates a standard – think carefully of its use. And dont have a bunch of people in a room designing something with no accountability. That isn’t a standard, that is a boat anchor.

    Cheers

     
  3. Ben Jackson

    Nice article Valyn. Having aggregated about 40+ proprietary feeds across the tour operator space I hear what you’re saying, its painful and incredibly resource intensive. In this space I see it as a combination of fear, competitiveness, lack of IT knowledge and resources that is stopping companies from working together in this space. In most cases they are just so new to this that they don’t yet get it.

    I can hear some top manager asking their IT team “We built this feed like you said we should why is only 3 people using it?” The other thing I see companies doing is putting so many restrictions on their data because they are too scared what people might do with it. Others yet provide 3/4 of their data in the feed and their marketing team manually adds to it after the fact so the feed is deficient…

    Maybe we should provide a standard API of all the aggregated touring product we collect. Not sure how we’d monetise it, would anyone like one?

     
  4. Micah Christensen

    The lack of standardization and seemingly constant, arbitrary shifts in API availability has certainly been a major issue in our work. I appreciate you bringing up the issue and would be very interested in knowing about any progress you see in the overall industry regarding standardization.

     
 
 

Newsletter Subscription

Please subscribe now to Tnooz’s FREE daily newsletter.

This lively package of news and information from Tnooz’s web site provides a convenient digest of what’s happening in technology that drives the global travel, tourism and hospitality market.

  • Cancel