Published in Travolution magazine Q1 2013 http://www.travolution.co.uk/

For Travel Technology suppliers such as Comtec we have to do many things.  We have to have a flexible sales product that facilitates a variety of holiday components: Packages, Dynamic Packages, Tailor-Made, flight only, Car hire, Accommodation.  You name it, we have to provide it!  We also have to adhere to payment card processing rules and regulations (PCI-DSS) and other legal requirements such as ATOL Flight+ Certification.

It takes us many days of development and testing to implement new 3rd party interfaces for accommodation, car hire, flights: Low cost and GDS, extras such as theatre tickets and excursions.  This is because each one of these suppliers we connect with has their own bespoke interface.  We know that an hotel bed requires a duration, a passenger configuration, a room type, extras like fruit or a bottle of champagne. So why do we have to write a specific interface to add a new bed bank or low cost flight API? Surely the requirements are the same for each?

The problem is that any standard has to be adopted to become a “standard”.  The Open Travel Alliance (open travel.org) has tried to set such a standard. The problem is that only a few suppliers have implemented it, and then, because it can often fall short of requirements, those who have implanted it have to add their own set of extensions to support their product.  This then makes the standard non standard, and so it goes on.

So, what do we have to do to become standard?  We have internally tried to write a standard interface and originally started to use the OTA format but quickly realised only some of the 3rd party suppliers product would be supported by it.  If there were an adopted standard we could implement integrations quickly and would probably only need to test the interface rather than analyse, write and test each bespoke integration.  What would happen to integrators who’s only role in the supply chain layer is to consolidate 3rd party suppliers?  Maybe that’s the answer, to adopt an integrator who has all of the product you need and integrate to their interface?  Therein lies another problem: finding a consolidator who has all of the product demanded by our customers: it doesn’t exist!

The mapping suppliers are providing standards such as KML, GPX and KMZ.  This enables a developer to integrate mapping quickly and easily.  Apple iPhone developers can use standard modules and tools to mashup maps, location and other services and use them in their apps using nothing more than “drag and drop” so why not supplier API’s.

Each week I get suppliers asking us to integrate their product – we look at their interfaces and realise it’s going to cost us to develop the integration.  We then have to workup the ROI to see whether any time spent on the integration is going to provide us with a good return on investment.  If not we might never integrate the supplier.  I have asked three suppliers in the last week if they are OTA compliant and one said: “whats the OTA” and the other two said no.  So, it is here that I have stumbled on the answer.  It’s the suppliers that need to get together and make sure their API is based on a standard.  Suppliers: then give us a call and we can get our customers to sell your product quickly and easily: which is what you want?  If you don’t have an appetite to do this then perhaps we can do this for you?

Now…let’s talk about web browsers standards!