Nick Lanyon

1. Business problem
2. The schedule
3. Other challenges
   1. Cross-industry needs and relationships
   2. No general-purpose XML infrastructure yet
   3. Key players doing their own things
   4. Legacy standards organizations
   5. Conflict of speed against scope
   6. Distance
4. Achievements
5. Plans for the future
6. Bibliography

Business problem

People who travel think of a typical journey or trip as a compound entity, involving components from several airlines and other suppliers. The intermediary that organizes the journey has a similar view. Historically, it has only been the intermediary (usually a single travel agency, via the Global Distribution System or GDS that it uses) that has had access to all the data needed to plan and manage a journey.

As discussed in the OpenTravel Alliance’s [White Paper], for any one journey there has thus only been a single distribution channel, consisting of the travel agency and its GDS. This has presented restrictions, as GDSs offer limited content. Perhaps because of the lack of channel competition, distribution costs have moreover risen to the extent where airlines, in particular, wish to reduce the approximately 20% of their revenues that these costs consume.

The Internet and the World-Wide Web offer rapid access to content that is provided directly by suppliers. There is thus an opportunity for suppliers to offer journey components directly to travelers, and in particular to the employees of corporations, and the travel management companies formerly known as travel agencies working for them. The problem is that these components are described on the Web in HTML, so they are difficult for a computer to assemble into a compound journey.

HTML is fine for presenting things to people. But the computers that are used to plan and manage journeys can only ‘screen scrape’ HTML to capture the information they need – a laborious and error-prone process that is subject to defeat whenever a supplier changes the presentation of its services on screen. As observed by many others, XML is a good solution to this problem.

Previous

Table of Contents

The schedule

The OTA was formed by a small group of airlines, car rental companies, and hotel chains to address the business problem outlined above. Its ad hoc Board of Directors convened its first open Advisory Forum in Atlanta, GA, on May 25, 1999. This was followed by several months during which the bylaws were refined, particularly to allow better representation of travel agencies and other ‘non-suppliers’. The Board was filled out through elections held in August 1999. Also in that month, the Data Interchange Standards Association of Alexandria, VA, was appointed to manage OTA and provide its Standards Manager. Alan Kotok, formerly of the GCA, was appointed to this role on October 1.

At the Advisory Forum the Board announced that Version 1 of OTA’s specification (not ‘standard’ – see below) would be released before the end of 1999. It was implicit that while the scope was yet to be defined, the major part of the work was to develop an XML vocabulary for the broadly-defined travel industry. This combination of loose scope and tight schedule was, after the politics of representation, the first major challenge.

Previous

Table of Contents

Other challenges

Cross-industry needs and relationships

OTA structured itself with a minimum management role for the Board, but a maximum role for the Interoperability Committee that reports to it – see Figure 1. In addition to recommending deliverables and the schedule for them to the Board, a primary role of ‘Interop’ was envisaged as arbitrating on vocabulary issues that were expected to arise as separate Work Groups (Air, Car, Hotel, Non-Supplier and – a recent addition – Leisure) defined the tag vocabularies for their sub-industries – the standard example was ‘Should we talk of Passengers (Air), Customers (Car), or Guests (Hotel)?

Figure 1 . OTA’s structure

In the event, it turned out that much of the work was done through ad hoc Task Teams set up by Interop. These drew members from all Work Groups, with some of the most valuable contributions coming from members who were not from what would have been expected to be the most relevant Work Groups. The ease of such contributions was a consequence of the early change to the original arrangements that opened every Work Group, and Interop, meeting to any member.

The first area of content to be addressed, that of the Customer Profile, was deliberately chosen to stretch across all OTA’s Work Groups, so as to drive evolution of a process that facilitated co-operation across the entire OTA. This led to the formation of an ad hoc Customer Profile Content Task Team, whose delivery included:

There has been continuing growth in OTA membership, which reached 100 in March 2000 (incidentally delivering the membership fees budgeted for the first year). Figure 2 shows the importance of the Non-Supplier members, who made a substantial contribution to all parts of Version 1 of the specification.

Figure 2 . Demographic breakdown

The complexity of the work and the size of some of the meetings (27 Non-Suppliers, including several CEOs and CTOs, attended one face-to-face meeting) strained the resources of DISA’s Standards Manager, who at one stage was running and documenting daily conference calls, typically lasting three hours. This challenge was ably met by the incumbent, but it would be wise for OTA to plan for more resources to be available in the future. Similarly, DISA’s overall support role for the whole OTA, as the only group drawing any fees or expenses, should probably grow to embrace such things as facilitating networking amongst members.

No general-purpose XML infrastructure yet

It was recognized early on that as there was no general-purpose cross-industry XML infrastructure, OTA would have to build one for itself – or at least enough to support the demonstration that the Board had made an explicit objective. This was the most difficult and time-consuming part of the whole process, leading to the following being addressed by the Technical Architecture Task Team for Version 1:

Even in the high-pressure course of the Version 1 work, several OTA staff and members considered the promise of ebXML sufficient to justify attending the first two meetings and playing a significant role. There is however concern that ebXML may not deliver what is needed fast enough to avoid continued unilateral development of infrastructure by OTA and other similar groups. This will consume effort that could better be applied elsewhere, and will lead to unnecessary delay and (probably) rework. Further, if ebXML does not deliver an infrastructure in time for it to be used across all industries it will make it much more difficult for the travel industry to deal directly with its corporate customers, as they come from every imaginable industry.

In the event, continued testing and evolution of the infrastructure and the Customer Profile DTDs made it difficult to keep the two parts of the Specification and the demonstration (all being developed in parallel) coherent – a prime cause of Version 1 being published two months late.

Key players doing their own things

Even in May 1999, it was known that some key players in the travel industry were ‘doing their own things’ with XML – though at that time the trade press was better at highlighting the companies in such announcements than the technology they were using.

OTA has been encouraged by early XML adopters such as RezSolutions that publicly said that it built its own vocabulary etc. because there was nothing else available, but that it was impatient for the development of a generally-available specification that it could use instead. Unlike the single-company and bilateral users of XML, which have generally been able to depend on restricted networks with implicit security arrangements, OTA has had to address privacy issues explicitly in its data structures and messages. While it is hoped that some of the infrastructure products that are being used to front-end GDS and other mainframes will facilitate migration and avoid the need for long-term support of multiple vocabularies etc., it remains to be seen how successful this – and the necessary extension of privacy arrangements to support open use - will be.

Legacy standards organizations

There are several existing organizations that publish standards for the travel industry. HEDNA and IATA are extreme examples in the way they have worked with OTA.

HEDNA was an early supporter. Not only did its then Chair join the OTA Board, but it made available its existing (non-XML) standards work as input to OTA. Recently, it has transferred its association management contract to DISA, which will make future co-operation even easier. IATA (the International Air Transport Association), by contrast, has not co-operated.

In between, there are ongoing discussions between OTA and HITIS committee of the American Hotel and Motel Association. HITIS has had a high-quality standards effort under way for several years, and has recently embraced XML. Its area of work overlaps that of OTA, and there is much hope that a way can be found to combine the efforts.

A major reason why such co-operation is challenging seems to be that some standards organizations have a very different business model to the cross-industry groups that have, in the late 1990s, demonstrated the power of rapid, open, low-cost specification development. If a specification is not only so useful that it gets used by many powerful organizations but is also made available early and widely, it becomes a de facto standard. This is why OTA is publishing a specification.It was pleasing to see the announcement by GetThere.com that it and the several industry-leading e-commerce companies (including Ariba, Captura, Concur Technologies, Extensity and Gelco) involved in the GetThere Application Network are already using the OTA specification – an announcement made only a month after the draft publication of Version 1.

Conflict of speed against scope

The schedule for Version 1 was ambitious. It was unattainable, given the lack of clarity about what had to be developed to provide an infrastructure to support not only the demonstration, but also to provide a foundation for what will need to be developed (or adopted from eg. ebXML) later. This was a major challenge, particularly given the uncompromising nature of some of the participants in the Technical Architecture Task Team and their commendable determination to be associated with a high-quality deliverable.

One of the lessons OTA is trying to apply to its work on Version 2 is to restrict the scope at an early stage, using a Journey and transactions that edit this as a reference model against which to apply use cases.

Distance

While it should be easy for the travel industry to gather face-to-face, progress needed to be faster than (say) monthly gatherings would enable – and everybody but the DISA staff has demanding day jobs, too. So there were many conference calls, some of them memorably challenging.

Conference calls could be much more productive if there were generally-available Internet based tools to support them: even a web site listing participants and showing who was speaking at any time would be a big help. But this would further highlight the major discrepancy between American Internet access and that nearly everywhere else in the world. Because of the distances involved (often, for OTA, across nine time zones), several participants in each call were at home, or on the road at a hotel. Most of the Americans involved now have both a voice line and a fast, permanent Internet connection in their home or hotel, so that during a call they can refer to a document posted to the OTA website. Most Europeans must however choose between a voice connection and a slow Internet connection that is so expensive that they disconnect it when it is not absolutely necessary. This is a major problem not restricted to OTA (and beyond OTA’s ability to solve!) that will continue to impede the development of technology in Europe and elsewhere outside North America.

Previous

Table of Contents

Achievements

Most of the major achievements have been touched on above. In summary, OTA’s open structure has enabled it to make good use of its diverse membership – and the size and activity of this is also no small achievement. Version 1 of the OTA Specification included only the Customer Profile content, but not only is this the subject of a public demonstration (see http://www.OpenTravel.org for both) but it has already been adopted for important real world use. The home-brew technical infrastructure set out in the Specification seems to go well beyond what many other XML groups have developed, and it is hoped that it will be useful to them – better yet, that OTA can get something in return, fast, through ebXML. Perhaps most important, a brisk style and process have been adopted that have allowed OTA to meet its objectives within budget.

Previous

Table of Contents

Plans for the future

The major area of content to address is the multi-component Journey itself. This involves all the Work Groups, and there is a major danger of the scope getting out of control. In parallel, individual Work Groups are likely to tackle ‘internal’ areas. As little infrastructure work will be done as possible – but if ebXML does not deliver what is needed fast enough this will also have to be addressed.

Previous

Table of Contents

Bibliography

[White Paper]

The OpenTravel Alliance White Paper, Version 2.0, by Nick Lanyon and Alan Kotok: February 2000, available at http://www.OpenTravel.org

Previous

Table of Contents