Businesses are moving beyond traditional industry silos and coalescing into networked ecosystems, creating new opportunities for innovation alongside new challenges for many enterprises. Ecosystems typically bring together multiple players of different types and sizes in order to create, scale, and serve markets in ways that are beyond the capacity of any single organization—or even any traditional industry. Their diversity—and their collective ability to learn, adapt, and, crucially, innovate together—are key determinants of their longer-term success. In Eutravel, apart for the travel end users (travellers and businesses that buy travel services) several other key ecosystem stakeholders are considered (Table 1).
|
Transport Infrastructure
Providers
|
Transport Service Providers
|
Travel Service Providers
|
Authorities
|
|
Rail Infrastructure Providers/ Managers
|
Rail Operators
|
Global Distribution System Service Providers (GDSs)
|
Mobility Management Authorities
|
|
Airport Operators
|
Air Carriers, Airline Operator
|
Travel Agents (Retailers),
Travel Management Companies (TMCs)
|
PT Administration Authorities
|
|
Fleet Owners,
Port/Terminal Operators
|
Ferry Operators
|
Online Travel Agents (OTAs) (Retailers)
|
Environmental Authorities
|
|
Infrastructure Maintenance Service Providers
|
Urban/Public Transport Operators (PT)
|
Car Rental Service Providers
|
Cross Border Managing Authorities
|
|
Toll Operators
|
Coach Operators
|
Hotels/ Hospitality Providers
|
Customs
|
|
ITS Solution Providers
|
Ticket Vendors - Retailers (third parties, apart from operators)
|
Travel Insurance Service Providers
|
|
Table 1: EuTravel Ecosystem Participants
Ecosystems formulation are facilitated by the growth of APIs. With the proliferation of Application Programming interfaces (APIs) available both privately and publicly, it becomes very difficult to monitor the latest developments in this area. This is partially alleviated by recently established public registries of APIs where their developers/owners are encouraged to register information about them.
The API registry used in this research was the Programmable Web [1] that claims to be the world’s largest repository (registry) for APIs, containing in excess of 14,000 API entries at the time of writing this report. To retrieve travel related APIs the category ‘travel’ was used to retrieve relevant APIs from the Programmable Web repository. This approach however is not guaranteed to return the whole list of travel related APIs, nor only APIs that are relevant to travel, as some travel APIs could possibly have been classified incorrectly. The number of results however, (in excess of 300) indicates that (a) the Programmable Web is a useful source of API information and (b) the proliferation of travel related APIs. Also, although the search opted to exclude deprecated APIs, there is no absolute certainty that the APIs found are still actively used/supported by users and their developers.
The next step in the process involved the filtering out of APIs that were deemed to have a narrow geographical coverage, i.e. covering travel information within a city or region- but not country or continent level, as EuTravel has a pan-European scope.
The number of travel APIs in the filtered list obtained in this manner was still too high and therefore not useful to provide patterns, trends and insides into the current travel related API market. As the purpose of EuTravel is to develop an ‘API of APIs’ it was considered important to define the breadth of coverage and scope of such API. This would require some classification of existing travel APIs however. As such classification did not currently exist, we decided to propose one that is empirically derived by analysing the descriptions of the discovered APIs and identifying common themes that appear across them. Thus, this is not a strict classification as APIs may straddle several themes and some APIs may appear to not belong to any of the proposed themes. Instead this classification was proposed in an attempt to scope the planned ‘API of APIs’.
The classification proposes the following five themes:
APIs oriented towards developers that want to integrated/aggregate existing travel services (e.g. to create portals. Mashups, for travel aggregators). These also cover multiple travel modes (sea, land, air) and facilities (e.g. car and hotel hire). These APIs have transactional capability (e.g. create bookings).
APIs oriented towards one type of service/travel mode (e.g. air travel) and/or one provider (e.g. one particular airline only). These APIs also may have transactional capability.
APIs that provide travel related but static information (e.g. about locations such as places to visit or airports) but they do not (normally) support itinerary planning as timetabling and dynamic travel information is not included
APIs that provide timetable-like information such as bus or flight arrival information, flight tracking, for single or multi-mode but (normally) no booking functionality.
APIs that allow the sharing of information or resources between travellers, such as recommendations about visiting places, travel routes and trails etc.
[1] View at http://www.programmableweb.com