ACI ACRIS Recommended Practice ACI RP502A10 ACRIS...Service Oriented Architecture1 (SOA) principles and specifications described in this Recommended Practice (RP) should be applied

ACI ACRIS Recommended Practice ACI_RP502A10_ACRIS Version 1.0

April 2011

2

ACI_RP502A10_ACRIS_v1.0, version 1.0 / 21 April 2011 ***version 1.0***

Table of contents

1 Introduction .............................................................................................................................. 4

2 Benefits of service orientation and usage scenarios ................................................................. 5

2.1 Context of ACI ACRIS .................................................................................................... 5

2.2 ACRIS: providing the missing link .................................................................................. 7

2.3 Key principles of service orientation ................................................................................ 8

2.3.1 Reusability ................................................................................................................ 8

2.3.2 Standardization ......................................................................................................... 8

2.3.3 Loose coupling ......................................................................................................... 9

2.4 Business drivers supported by service orientation ........................................................... 9

2.4.1 Cost reduction ......................................................................................................... 10

2.4.2 Reduction of time to market ................................................................................... 11

2.4.3 Increasing business agility ...................................................................................... 11

2.5 Conditions for a successful appliance of service orientation ......................................... 13

2.5.1 The introduction of a semantic model .................................................................... 13

3 ACI ACRIS Specification Summary ...................................................................................... 14

3.1 Annexes .......................................................................................................................... 14

3.2 Supporting documents .................................................................................................... 14

4 Management of the ACI ACRIS Service definitions ............................................................. 15

5 Roles and responsibilities of ACI ACRIS Parties .................................................................. 16

5.1 Service Consumer Responsibility .................................................................................. 16

5.2 Service Provider Responsibility ..................................................................................... 16

5.3 Certification .................................................................................................................... 16

6 Bilateral service contract ........................................................................................................ 17

7 References .............................................................................................................................. 18

7.1 Standards ........................................................................................................................ 18

7.2 Definitions ...................................................................................................................... 18

8 Acknowledgements ................................................................................................................ 19

3


AIRPORT COMMUNITY RECOMMENDED INFORMATION SERVICES (ACRIS)

Recommended Practice

It is RECOMMENDED that, when an airport, airline or associated service provider plans to exchange information between two or more IT solutions, the Service Oriented Architecture

1 (SOA) principles and

specifications described in this Recommended Practice (RP) should be applied.

1 “SOA is an Architectural Information Technology style based on loosely coupled services in order to

support business flexibility in an interoperable and technology independent way. It consists of a group of business-aligned services that support business processes implemented in a flexible and dynamically re-configurable way, using interface based descriptions of the services."

4


1 Introduction

ACI Airport Community Recommended Information Services – ACI ACRIS – is an initiative from the ACI World Airport IT Standing Committee (WAITSC). To establish this, the ACI WAITSC founded a Working Group in 2009.

The vision behind ACI ACRIS is “the consistent adoption of Service Oriented Architecture (SOA) principles across the world‟s Airport Community in a coordinated effort”.

The mission of the ACI ACRIS WG is “to deliver recommendations, requirements and technical specifications that enable airports, airlines, partners and suppliers to exchange and process data in a standardized and service oriented way”.

The main objectives for the ACI ACRIS WG are

- To define service descriptions for the usage scenarios described in Annex 1 (such as Passenger Status; Business to Business - B2B - Airport Status; Airport CDM – Collaborative Decision Making; Common Use Bag Drop)

- To provide supporting documentation regarding o Information Technology Security o Design, Installation and Operation guidelines o Semantic model for the aviation – airport domain

- To complement and use existing IT and process standards, as mentioned in Annex 2.

5


2 Benefits of service orientation and usage scenarios

2.1 Context of ACI ACRIS

The definition and implementation of standardized business processes and interoperable IT solutions is a vital issue for the global aviation industry especially as a way to increase revenues and reduce costs. This is not only valid within one stakeholder group (e.g. airlines), but also between different groups such as airlines and airports. These cross-company processes need a Business-to-Business (B2B) integration of the partners‟ different IT solutions, and this is the exact field that the ACI ACRIS WG is focused on.

Generally, standards for B2B scenarios must be described at different levels: business processes, data exchange and the information services connecting them.

Standard (Business) Process Description: This level describes how the stakeholders work together in one process to achieve an overall goal. Within this description IT solutions are often included generically but not described in detail. The process description shows WHERE within the process a data exchange between IT solutions is needed.

An example of a standard business process description is the IATA RP1701f Fast Travel – Bags Ready to Go – Automated Baggage Drop Off, which will be ready for approval by the ACI World Governing Board in Spring 2011.

Standard Data Exchange Descriptions: A much more technical standard is an agreed description of the data (data types and structure) to be exchanged. This description shows WHAT the data looks like.

An example for this level is the ACI RP 501A07 (IATA RP1797a) Aviation Information Data Exchange AIDX.

The link between the business process description and the data definition is a standardised definition of a (technical) information service that defines HOW to efficiently exchange data between business processes.

As the text explaining the different levels suggests they are closely related. Figure 1 illustrates these relations.

6


Figure 1, relation between Business process, Data exchange and Information service

There is a growing requirement among members of the airport community (airport authorities, airlines, security authorities, concessionaires, etc) to share flight, baggage, and passenger processing information. This is being driven by a rapidly developing new model of airport operations which is based on the rationalization and optimization of:

• Shared facilities

• Self-service

• New technology and automation

• New passenger flows split between generic and exceptional transaction, physical location and processing status of passengers, rather than airline brand.

Figure 1 represents an actual scenario where data exchange from the Common Use Passenger Processing System (CUPPS) IT solution would prove beneficial to many stakeholder groups and potentially, other IT solutions.

Figure 2 Role of data exchange in the airport business

7


The various process functions which need to access shared data include:

• Check-in process (web, mobile kiosk, offsite, traditional counter)

• Baggage sortation

• Security checkpoint

• Baggage drop-off

• Retail concessions

• Boarding

• Passenger tracking

• Transfer passengers and baggage

• Ground transportation

• Intermodal links

The ACI ACRIS recommended practice builds on existing industry protocols to permit the development of data aggregation, applications by different agencies, and the implementation of shared processes. This recommended practice references existing technical standards and data elements.

The recommended practice does not seek to regulate application development or data use policies, which are implemented as required by the airport communities.

2.2 ACRIS: providing the missing link

The link between standardized descriptions of common business processes and data in the aviation community is missing. The ACI ACRIS WG fills this missing link by providing standardised definitions of information services. To accomplish a standardised approach, this Recommended Practice (RP) will provide definitions of Web Services, following the World Wide Web Consortium W3C technology standards2, where standardized messages are used to support an efficient exchange of data between business processes throughout the aviation community. For example one of the services will use the AIDX data description standard to support the stakeholder-wide system integration in a standardised B2B scenario such as the Automated Baggage Drop Off process.

2 see http://www.w3.org/TR/wsdl

http://www.w3.org/TR/wsdl

8


2.3 Key principles of service orientation

The following key principles of service orientation promote business drivers:

Reusability

Standardization

Loose coupling

2.3.1 Reusability

One of the basic principles of service orientation is the reuse of existing functionality that is used throughout different business processes. A smart distinction between what business processes have in common and what makes a business process unique, can reduce the amount of software that must be maintained. For example, a „Validate Passenger‟ information service based on a boarding card is useable at a self-service drop off, at the entrance of a security filter, or during tax free shopping.

2.3.2 Standardization

Most of today‟s IT hardware and operating systems have standardized interfaces, which make it possible to plug-and-play hardware extensions and to install applications from different manufacturers. By applying standardization to information services this principle enables the reuse of IT solutions throughout business processes involving different business partners.

While each airport is slightly different many processes and their supporting IT are similar. Airports usually have some core systems like an Airport Operational Database (AODB), Enterprise Service Bus, Flight Planning, Resource Management, Billing and Reporting.

An ACI standard for a modern Airport IT architecture and information services, driven by user needs and enriched by expertise from non-aviation sectors, will deliver enormous added value to the ACI members and their business partners.

The main advantage of using a standardized ACI ACRIS information service in the field of B2B scenarios (such as an Automated Baggage Drop Off) is the ease of reuse. As soon as an airport provides a standardized ACI ACRIS information service for one partner this can be used by additional partners without further development efforts on behalf of the providing airport.

Please note that standardization on information services does not include definition of transport protocols: the same service can be used over different transport protocols.

9


Figure 3 As many 1-on-1 interface definitions are needed as there are proprietary partner connections

Figure 4 Only 1 Service Definition needed for similar information services between several chain partners

In general Figure 3 and Figure 4 show the advantage of a recommended interface vs. several proprietary solutions. They assume that the airport is the service provider that offers an information service. Similar drawings are possible for the airline or business partner as a service provider.

2.3.3 Loose coupling

Based on a service contract, a service consumer knows what to request from a service provider, and in return, gets an agreed piece of information. The service consumer does not need to know the internal working or implementation details of the provided service. This type of connectivity is called „loose coupling‟.

2.4 Business drivers supported by service orientation

The principles of service orientation, reusability, loose coupling and standardization, support the following business drivers:

Cost reduction

Reduction of time to market

Increasing business agility

10


2.4.1 Cost reduction

Development of individual customer solutions for Airport IT (such as AODB, Flight Planning, Resource Management, Enterprise Service Buses, Baggage Systems, Check-in Equipment, A-CDM, A-SMGCS3) results in a high total cost of ownership, takes a lot of time to implement, and entails enormous risks. This is true whether an Airport‟s IT department develops such solutions or if a supplier delivers them. Developing solutions based on re-use of existing services and standardised components (e.g. based on the ACI ACRIS definitions) will reduce time delays, and avoid higher costs and risks.".

Table 1 and Table 2 below present a global calculation exercise showing the cost differential between the typical „proprietary‟ approach to information sharing, and a standardized, ACRIS approach

Referring to Figure 3 and Figure 4 an outline business case for the usage of standardized interfaces is given by the reusability of an already implemented standard interface. If one assumes that the development, testing and implementation of a new interface cost each partner 100K EUR initially and the maintenance of such an interface cost about 10% of its initial costs per year, then Airport 1 in the situation of Figure 3 has to spend 3 x 100K EUR = 300K EUR initially for three individually developed interfaces and 3 x 10K EUR = 30K EUR annually for the operation of these interfaces. There is no scaling effect at all: a fourth interface, e.g. to Business Partner II, would cost once more 100K EUR initially and 10K EUR yearly.

Table 1 Calculation exercise: TCO of three separate, proprietary information services

Interface from Airport 1 with

Initial Costs Yearly maintenance Total maintenance (4 years)

BP1 100 10 40

Airline A 100 10 40

Airline B 100 10 40

TOTAL 300 120

TCO 420

In the situation of Figure 4, using a standard interface (e.g. an ACRIS Web Service) and assuming that the implementation of a copy of an already existing interface costs 20% of its initial efforts, Airport 1 has to spend 100K EUR + 2 x 20K EUR = 140K EUR initially. The yearly costs will also be reduced to 10% of 140K EUR = 14K EUR. The reason for these results is quite simple: a copy of an already existing interface, following a worldwide standard, reduces the costs of coordination, testing and implementation. This is also relevant for the yearly costs, since the same staff can operate much more identical interfaces then different ones. So this advantage would also exist if Airport 1 would like to connect with Business Partner II: only 20K EUR initially and additional 2K EUR per year should be paid for this fourth connection. The cost saving effect grows with every additional implementation of an existing standardized interface.

3 A-SMGCS means Advanced Surface Movement Guidance & Control System; please refer to

http://www.eurocontrol.int/airports/public/standard_page/APR1_Projects_ASMGCS.html

11


Table 2 Calculation exercise: TCO of reusing a standard information service for different partners

Interface from Airport 1 with

Initial Costs Yearly maintenance Total maintenance (4 years)

Business Partner I 100 10 40

Airline A 20 2 8

Airline B 20 2 8

TOTAL 140 56

TCO 196

For IT solution suppliers the implementation of ACI ACRIS recommended information services within their products will have the advantage that they can offer their product and services at a more competitive price, since an expensive integration project phase at a custom airport or airline can be avoided or at least significantly reduced.

In addition, by adherence to agreed standards the labour costs on data integration analysis can be reduced.

2.4.2 Reduction of time to market

Reusability promotes a reduction of the time to market for new or changed IT services. Development cycles of new functionality can be significantly reduced. Responsiveness of airports and their business partners to new requirements has become essential, for example the adherence to new government regulations or security measures that must be implemented short term. Loose coupling and standardization also lead to shorter time-to-market. The combination of both leads to a greater interchangeability of components. Loose coupling makes it possible to plug and play, exchange a component; standardization of that connection makes it possible for components of different suppliers with the same functionality to be exchanged without changing the interface (other than configuring the connection). Once the service contract is agreed upon, the „plug and play‟ character of service orientation should be a matter of configuration instead of a longer software development project.

2.4.3 Increasing business agility

Because airports are so complex, optimization of business processes is not a choice, it is vital for economic feasibility. Adaptation is a key factor in airport management and this is facilitated by Service Oriented Architecture. A service oriented approach makes it possible to make slight variations in a business process, because only the variation has to be developed or orchestrated. What should stay the same stays untouched. The same applies to enabling innovation: new business services, built on an existing IT base, may increase revenues.

12


Loose coupling and standardization make it easier to do business with new partners, even if the internal working of that service is slightly different per partner. For example, based on standardized services, an airline should be able to quickly arrange information exchange with the airport IT systems of a new destination.

Loose coupling and standardization also enable switching between vendors business partners and therefore reduce the risks of a vendor lock in.

Standardization would also allow the supply industry to structure their investments in new products supporting this standard, allowing them to broaden their product portfolio. For Airports, this market openness means that they will benefit from even greater freedom of choice.

13


2.5 Conditions for a successful appliance of service orientation

2.5.1 The introduction of a semantic model

It must be taken into account that a successful collection of services should be consistent with one another and should be based on a common understanding of the airport business. Also the prioritization in the planning of service definitions that will be developed will benefit from this common understanding. Therefore, a semantic model4 is needed. The use of a community semantic model also serves as the basis for data standards which is a requirement for service data quality. The primary purpose of the model is to capture, represent and specify Airport domain knowledge to enable re-use in the specification of business services. Taking into account the constraints of the existing IT infrastructure, and the need for a common understanding, the ACI ACRIS WG will strive for a „middle-out‟ strategy. The ACI ACRIS WG will gradually develop a semantic model for the airport domain that serves as a base for the planning and development of ACRIS services definitions.

For more information on the concept and for the best practice on how to develop a semantic model, please refer to the supporting document ACI_RP502A10_ACRIS_SU07 ACRIS Semantic Model for SOA

4 A semantic model for airports is the representation of the vocabulary used in the airport domain. This kind of model

has been given the many names by different IT communities including Domain Model, Semantic Model, Ontology,

Conceptual Data Model, Fact Model

14


3 ACI ACRIS Specification Summary This Recommended Practice is accompanied by 2 different sets of documentation: 1) Annexes: an annex is a document that is part the Recommended Practice, which

are likely to grow over time. Additions to these annexes shall be approved by the ACI WAITSC.

2) Supporting documents: a supporting document is a document that is not part of the Recommended Practice itself, but will guide and help service developers in designing and implementing ACRIS compliant information services.

3.1 Annexes

ACI_RP502A10_ACRIS_AN01 usage scenarios

ACI_RP502A10_ACRIS_AN02 supported IT Standards

ACI_RP502A10_ACRIS_AN03_<<serial.nr.>> Service definitions - A growing set of service definitions, based on the service definition template.

3.2 Supporting documents

The supporting documents to the Recommended Practice will be the following:

ACI_RP502A10_ACRIS_SU01 Service definition template - The ACI ACRIS Services will be described in a common format, based on best practices and containing the elements as presented to the ACI IT standing committee in April, 2010

ACI_RP502A10_ACRIS_SU02 Service definition template guideline

ACI_RP502A10_ACRIS_SU03_<<serial.nr.>> Reference implementations – A service definition may be accompanied by a reference implementation (software) and / or implementation examples (description) for demonstrating purposes.

ACI_RP502A10_ACRIS_SU04_<<serial.nr.>> Test Cases – A set of test cases to prove compliant service implementation

ACI_RP502A10_ACRIS_SU05 Security Policy for Third Part Services – A guideline to implement appropriate security measures according to the trust level of the service consumer and the business risk involved.

ACI_RP502A10_ACRIS_SU06 Governance for the ACRIS initative – Terms of Reference for the ACI ACRIS WG itself

ACI_RP502A10_ACRIS_SU07 ACRIS Semantic Model for SOA

15


4 Management of the ACI ACRIS Service definitions

Management of the ACI ACRIS Service definitions is done by the ACI ACRIS WG.

The ACI ACRIS WG reports to the ACI WAITSC. The WAITSC will provide direction and guidance to the WG and approve documents and initiatives, including submission to the ACI World Governing Board or other approval bodies as required.

The ACI ACRIS WG will consist of IT managers and/or IT architects who are representatives for

ACI airport members and World Business Partners in good standing, and

Other organizations whose application has been approved by the ACI ACRIS WG Chair and Secretary and who remain active at the meetings

The WG will be responsible for overseeing the ACI ACRIS RP as well as any documentation required.

The Chair of the ACI ACRIS WG is appointed by the ACI IT Standing Committee and is the Official Representative, spokesperson of the WG.

Any ACI Member may have access to the ACI ACRIS documentation to develop compliant services that will be used at airports. ACI will also distribute the documents to other qualified organizations (such as IATA, third party vendors, airlines) after approval by the ACI ACRIS WG. ACI will act as the communication channel for gathering feedback on ACRIS services as well.

ACI World will act as the Secretariat for the ACI ACRIS WG.

Figure 5 - stakeholders in the ACI ACRIS initiative

16


5 Roles and responsibilities of ACI ACRIS Parties

This section addresses the roles and responsibilities of the various ACI ACRIS parties, as they pertain to overall service provisioning and maintenance during live operation.

5.1 Service Consumer Responsibility

The Service Consumer will ensure that:

Transmitted service requests conform to the ACI ACRIS methods and schema as defined in the specific service definition.

It will use the service according to a fair use policy

5.2 Service Provider Responsibility

The Service Provider will ensure that:

Transmitted service responses conform to the ACI ACRIS methods and schema as defined in the specific service definition.

The conditions as stated in the Service Level Agreement / Bilateral service contract will be met.

5.3 Certification

There is no certification required. An organization that implements services according to the ACRIS Recommended Practice is responsible for demonstration of compliance by providing results of its execution of the ACRIS test cases. Because it is not feasible to establish a separate body to certify ACRIS services, the initiative has to rely on the organizations that implement the Recommended Practice for demonstration of compliance. To ensure the scope of the testing is sufficient, the ACRIS WG will create a standardized set of test cases. If certification or encryption of data has to take place, this will also be part of the bilateral agreement between sender and receiver.

17


6 Bilateral service contract The service provider and service consumer should create a bilateral service contract which records various technical and commercial factors which are necessary for a satisfactory implementation. The parties should agree on the following minimum items list:

Guaranteed availability.

Payment conditions, if any.

Average and maximum service response times.

Average and maximum calls of the service, per time unit.

Average and maximum size of the messages, per time unit.

Security measures to be implemented.

Network communications, transport protocols and related factors.

Agreement of any features defined as optional in the service description.

Service level and contacts in case of disruptions and incidents.

Version control and chang management.

Any other information which needs to be agreed for the unambiguous implementation and operation of the service usage.

18


7 References

7.1 Standards

IT Standards that the ACI ACRIS Initiative adheres to are to be found in Annex 2, Supported IT Standards for the ACI ACRIS Initiative

7.2 Definitions

Abbreviation Meaning

A-CDM Airport Collaborative Decision Making

A-SMGCS Advanced Surface Movement Guidance & Control System

ACI Airports Council International

ACRIS Airport Community Recommended Information Services

AIDX Aviation Information Data eXchange

AODB Airport Operational DataBase

B2B Business to Business

ESB Enterprise Service Bus

IATA International Air Transport Association

RP Recommended Practice

SOA Service Oriented Architecture

TCO Total costs of ownership

W3C World Wide Web Consortium

WAITSC World ACI IT Standing Committee

WG Working group

WGB World Governing Board

19


8 Acknowledgements

The following have actively contributed to the ACI ACRIS RP Draft and its supporting documents (in alphabetical order):

- Mr Segun ALAYANDE (BAA Airports Ltd) - Mr Frank BARICH (Barich Inc.) - Mr Robert COY (Deerns Consulting Engineers) - Mr José Luis CUENA (AENA) - Dr Thorsten EPPELMANN (Fraport) - Dr Rolf FELKEL (Fraport) - Mr Arturo GARCÍA (ACI World) - Mr Ron HISCOX (Aéroports de Montréal) - Mr Kees JANS (Schiphol Group) - Mr George KARRER (Zurich Airport) - Dr Roland KRIEG (Fraport) - Mr Thomas LEONHARDT (Fraport) - Ms Catherine MAYER (SITA) - Mr James MCELHANNON (SITA) - Mr Christoph MEIER (Siemens) - Mr Benjamin MORENO (INDRA) - Ms Isabelle OUELLET (Aéroports de Montréal) - Mr Joost PEETOOM (Schiphol Group) - Mr Damien ROUX (IER) - Dr Martin SMITH (Manchester Airports Group) - Mr Arie van der VEEK (Schiphol Group) - Mr Konrad ZOESCHG (Zurich Airport)

ACI would like to thank them for their contribution, effort and continuous support.

Documents

ACI ACRIS Recommended Practice ACI RP502A10 ACRIS...Service Oriented Architecture1 (SOA) principles and specifications described in this Recommended Practice (RP) should be applied