Basic Steps to SWIM Implementation

This article describes three scenarios as "basic steps to implement SWIM". These are indicative and simplified to avoid overload.

Introduction

SWIM stakeholders may ask the question: "What do I have to do to implement SWIM?" It is important to note that the answer to this question depends on context.

Indeed, ATM stakeholder role, information domain, service provider and/or service consumer, single service provider or multiple service providers, etc. are aspects that determine context possibly leading to differences in the steps to follow.

A service provider or consumer that implements SWIM may complement the scenarios described with organisation specific service management practice based on ISO/IEC 20000-1.

The following scenarios are described:

Scenario

Perspective

Purpose

Scenario 1: Using an existing digital on-line service.

Service Provider.

Qualify my existing digital on-line service as an information service.

Scenario 2: Providing a new digital on-line information service.

Service Provider.

Provide a new information service that is re-usable and fulfils an information need.

Scenario 3: Becoming an information service consumer.

Service Consumer.

Consume an information service that meets my information need.

Each scenario described below begins with a description of the starting point, followed by the question to be answered, the summary of the steps to take with a flowchart, and a table with further descriptions, notes and resources.

Each scenario is depicted showing the steps in relation to the: information, information service and technical infrastructure.

Scenario 1: Using an Existing Digital On-line Service

Starting point: the use of Internet technologies and World Wide Web standards is current practice and digital on-line services are already provided. The "top-down" service identification using service orientation practices is not necessary since the service already exists. The organisation of the service provider may already perform service management activities.

The question: can the existing service qualify as an information service, and if not, what is required in order to achieve this goal?

Scenario summary:

Step #

Activity

1

Collect information about the service.

2

Collect applicable SWIM requirements.

3

Check the interface protocols used to perform the service.

4 Check the information provided by the service.
5 Complete the service description.
6 Make the service known to SWIM stakeholders.

Flowchart:

Description of the indicative steps to follow:

Activity

Guidance

Notes/Resources

1. Collect information about the service.

The purpose is to collect the information that will be needed for performing service description activities in step 5. The information may be available from existing technical documentation, e.g. interface control document (ICD), or documentation accompanying an API.

-

2. Collect applicable SWIM requirements.

ICAO requirements may be complemented by regional and local SWIM requirements. Consider any policies that may apply.

See the SWIM reference for information, information service, technical infrastructure, and SWIM service registry.

3. Check the interface protocols used to perform the service.

To perform this check, answer the following question:

  1. Are the service interface protocols matching the applicable technical infrastructure requirements for the implementation of SWIM (i.e. the technology standards of the technical infrastructure interface bindings)? To accomplish the analysis:
    1. Compare available interface specification documentation (e.g. ICDs) to the applicable technical infrastructure requirements.
    2. Consider documenting the result of the inspection for convenient re-use at any later stage.
  2. If the answer to question 3 a) is yes, continue to step 4.
  3. If the answer to question 3 a) is no, decide to make the information available over interface protocols prescribed by SWIM. At this step it could be decided to end the scenario (e.g. due to feasibility considerations). It could also be decided to wait until step 4 below is performed before proceeding. When working this step consider the following:
    1. If no interface protocols are specified and applicable to you, consider adapting to those specified in another SWIM region. This implies testing.
    2. Make implementation choices together with the service stakeholders in order to reach common design decisions.
    3. Implement interface protocols applicable at global, regional and local levels.

Cf. the EUROCONTROL specification for SWIM Technical Infrastrucuture Yellow Profile and related resources.

4. Check the information provided by the service.

To perform this check, answer the following question:

  1. Is the information aligned with the AIRM? Using an information exchange model which is already aligned with the AIRM will satisfy this requirement and result in a positive answer.
  2. If the answer to question 4 a) is yes, continue to step 5 assuming that step 3 is achieved.
  3. If the answer to question 4 a) is no, align the information with the AIRM.

At this step it could be decided to end the scenario or continue since the alignment with the AIRM could be on-going in parallel for later achievement.

Alignment with the AIRM is achieved through the estbalishment of semantic correspendences between the information service payload and the AIRM.

Cf. the EUROCONTROL specification for SWIM Information Definition and related resources.

5. Complete the service description.

Whereas service description information is also required at the global level (i.e. Service Overview), additional regional/local service description requirements may apply.

The ICAO IMP is defining the Service Overview which contains the service description information to be made available at the global level.

Cf. the EUROCONTROL specification for SWIM Service Description and related resources.

6. Make the service known to SWIM stakeholders.

 The use of a SWIM service registry is preferred.

  1. Check applicable service registration policy.
  2. Provide service description information.

When providing service description information as structured metadata, consider harmonizing with metadata types already used in other contexts.

Cf. European SWIM service registry.

Scenario 2: Providing a New Digital On-line Information Service

Starting point: The potential for providing information services exist. Various technologies are used which create data. However, data exchange is not yet based on information services. Engaging into SWIM involves considering collaborative service orientation practices which have not been started up yet.

The question: which steps should be taken to provide an information service that is re-usable, fulfils an information exchange requirement and is a member of the pool of services?

Scenario summary:

Step #

Activity

1

Build a team with service orientation skills

2

Collect the applicable SWIM requirements.

3

Document the overall service orientation process steps deemed viable to you.

4 Perform service orientation.
5 Complete the service description.
6 Make the service known to SWIM Stakeholders.

Flowchart:

Description of the indicative steps to follow:

Activity

Guidance

Notes/Resources

1. Build a team with service orientation skills.

The team is a multi-disciplinary collaboration group combining operational, service orientation, information and technical infrastructure skills together. Build the team by allocating operational expert, service architect, information architect, technical infrastructure expert and solution expert roles to people of the team. It is possible that more than one skill is available from one person. Service orientation involves operational experts for defining the operational context, contributing to the business process analysis, analysing the information exchange requirements, and validating the resulting services.

-

2. Collect applicable SWIM requirements.

ICAO requirements may be complemented by regional and local SWIM requirements. Consider any policies that may apply.

See the SWIM reference for information, information service, technical infrastructure, and SWIM service registry.

3. Document the overall service orientation process steps deemed viable to you.

Service orientation process steps can be more or less complex depending on your regional/local needs and reality. When defining service orientation process steps involve the experts that will have to execute it. Not all steps are necessarily required depending on the approach followed.

See the service orientation process.

Understanding concepts related to the notion of information service.

4. Perform service orientation.

Service orientation is a collaborative process involving stakeholders. One essential information service identification activity is business process analysis to determine information exchange requirements of the "to-be" situation. This analysis may lead to early identification and attribution of QoS characteristics that need to be met by the service. The choice of using particular standards is important for both the service provider and the service consumer (e.g. choice of interface bindings). For the purpose of this scenario it is assumed that this step results in information services that satisfy SWIM requirements collected in step 2 of this scenario.

Cf. the EUROCONTROL specification for SWIM Information Definition and related resources.

Cf. the EUROCONTROL specification for SWIM Technical Infrastrucuture Yellow Profile and related resources.

5. Complete the service description.

Whereas service description information is also required at the global level (i.e. Service Overview), additional regional/local service description requirements may apply.

Cf. the EUROCONTROL specification for SWIM Service Description and related resources.

6. Make the service known to SWIM stakeholders.

 The use of a SWIM service registry is preferred.

  1. Check applicable service registration policy.
  2. Provide service description information.

When providing service description information as structured metadata, consider harmonizing with metadata types already used in other contexts.

Cf. European SWIM service registry.

Scenario 3: Becoming an Information Service Consumer

Starting point: Information services exist, and service overviews are available. A service consumer has an information need and is interested to use an information service that will satisfy this need. Information services made available in principle resulted from service orientation activities, hence this aspect is considered out of scope of the scenario.

The question: are information services available that I can consume and that meet my application requirements and information needs?

Scenario summary:

Step #

Activity

1

Define the application requirements and information needs.

2

Find information services.

3

Assess the feasibility to consume the information service.

4 Make implementation choices.
5 Adapt business processes.
6 Participate in the SWIM stakeholder community.

Flowchart:

Description of the indicative steps to follow:

Activity

Guidance

Notes/Resources

1. Define the application requirements and information needs.

Before analysing available information services, it is important to have a clear view on what is needed. Finding the right information service depends on matching available information services to the SWIM enabled application information needs (i.e. IER), intended function (i.e. service function), and performance requirements (i.e. QoS parameters). These requirements may stem from an existing or newly envisaged application and the operational environment, including its processes, in which it will be used.

Understanding concepts related to the notion of information service.

2. Find information services.

Use SWIM service registry functionality (e.g. search) to find information services and consult shared service description information. Possibly obtain more detailed service description information from the service provider using the point of contact information. Obtaining more detailed service description information may include signing an agreement with the service provider.

The ICAO IMP is defining the Service Overview which contains the service description information to be made available at the global level. When available, use service overviews as a first indication, to identify information services that could match the defined application requirements and information needs.

Cf. European SWIM service registry.

3. Assess the feasibility to consume the information service.

Investigate the feasibility to setup a service consumer application. Conclude whether the information service matches the need in terms of information, functionality, performance, and implementation feasibility. When the outcome is positive, this step may include signing an agreement with the service provider to access and consume the service.

-

4. Make implementation choices.

To implement the service consumer interface, a decision is made whether to adapt an existing application or create a new application. At this stage further technical decisions in relation to the interface bindings used by the information service are also made. Establish the connection to the information service interface and integrate the service into the consumer application. Perform validation of the application.

-

5. Adapt business processes.

At this stage of the scenario, configuring an information service into the service consumer environment creates a dependency that needs to be managed (e.g. to cater for eventualities such as a service outage or malfunctioning). As a consequence, the business processes are adapted in order to manage dependencies that result from the integration of the information service.

-
6. Participate in the SWIM stakeholder community.

Service consumers should keep themselves informed about service evolutions. Potentially disruptive evolutions that may occur need to be known well in advance. Typically, this is where governance functions play a key role. Service consumers may consider contributing to the evolution of the consumed services.

-

RESOURCES

Presentations about the workshop that took place on 22nd May 2019. 

Please find below the presentations of this workshop on SWIM using a simplified service development process on example services, focusing on service identification and service design, bringing education on AIRM, XMs, and TI.

 

RElated knowledge

This article introduces a service orientation process. It is an indicative reference for an architectural approach starting from requirements and ending in a running service instance available for operational use.

  Access


Last revision: June 26, 2019