Introduction

In a connected digital environment, organisations interact using interfaces. These interfaces enable the organisation’s information flows and business processes. The evolution into SWIM is the journey towards service orientation by establishing standardized interfaces through information services, forming the foundation of a networked global air transportation system. This knowledge article explains what the evolution into SWIM means for an organisation.

The long term vision is for all ATM information exchanges to be realised through information services provided in the context of SWIM. Organizations involved in ATM will reach an end state, named Native SWIM. Organisations that are Native SWIM interoperate digitally with other organisations using exclusively SWIM enabled applications consuming and/or providing information services. Legacy interfaces are no longer required and have been withdrawn. Native SWIM organisations participate in standardised information flows and collaborate digitally following collaborative business processes. Service orientation practices ensure that future collaborative business processes drive the implementation of information services.

Service providers make available information services into the networked global air navigation system and service consumers use the services made available. Information services are discoverable using SWIM service registries, which provide a design-time capability to publicize and find information about information services. SWIM thus appears as a pool of information services shared between collaborating organisations.  In this pool, the addressable end-points of the information services do not necessarily correspond to the physical locations of the involved organisations. The distinction exists between identification of the organisations and the addressing of the information service interfaces, the latter being handled at the SWIM TI level.

Understanding the nature of the information exchanges.

Information services and messages

At a more fine-grained level, all information exchanges are realized by messages that are transmitted because a corresponding operation of the interfaces has been triggered.

Messages are discrete units of communication that convey required information. Messages have a given purpose (e.g. distribute a dataset, request flight data, subscribe to information service, notify on an event,...) and their content can be of different nature (infrastructure data, flight data, meteorological data, aircraft data,…). 

Information services and their underlying messages are designed to support particular ATM business contexts (e.g. FF-ICE messages). The exchange of these messages is determined by the nature of IP-based network connectivity.

When looking at SWIM from a service perspective, the view of SWIM appears as a pool of information services. When zooming into this view down to level of the message view showing connectivity, information exchanges occur between IP-network addresses. These two viewpoints are shown below:

The SWIM principles of loose coupling and separation between service provider and service consumer foster the re-use of information services. This reduces the custom communication protocol dependencies and the individually managed and maintained interfaces.

Changes in the nature of the information distribution

SWIM introduces message exchange patterns that may imply changes such as:

• Changes in roles and responsibilities: in an environment whereby service consumers manage subscriptions to available information services, it becomes the responsibility of service consumers to ensure they are subscribed to the right information service. Note: SWIM service registries facilitate the discovery of the information services to which service consumers may wish to subscribe to.
  
• Change in the management of the information distribution. The consumption of an information service, which establishes a connection between a service provider and a service consumer, implies the management of addressing is decoupled from the information exchanges. Whereas traditionally, the data provider identified the technical recipients of the information in an offline process, SWIM allows information service consumers to self-manage their data flows by registering for access by online subscription.
  

Understanding the nature of the evolution.

The evolution into SWIM is driven by the evolution of business needs. Technology is a key enabler for the evolution to happen but it is not the driving force. Collaboration between organisations within communities of interest is important. This happens at different levels:

• Management level: agreement building, decision making, policy setting, standards selection and planning are key evolutionary activities that require a cross-organisational collaborative approach (e.g. governance);
  
• Implementation level: bringing together a community of interest involves assuring that key expertise is available, within and across organisations. Indeed, when performing service orientation business experts, operational experts, service architects, data/information architects, technical infrastructure experts, and solution experts collaborate closely.
  

Understanding the nature of the evolution.

When engaging evolutionary activities towards SWIM there is no singular pathway. Preparatory work is essential in terms of identifying the community of interest, the planning, and the set of enablers required to start. Each evolutionary journey into SWIM needs careful management to avoid disruptions. The evolution into SWIM is an iterative process that implies stepwise implementation and refinement of information services and gradual gains of maturity:

SWIM uptake cases.

The introduction of information services is either based on a legacy information exchange requirement or a new information exchange requirement. Therefore, essentially the following SWIM uptake cases can exist:

• Direct introduction of SWIM (“greenfield” approach)
  
• Transition to SWIM (“brownfield” approach)
  
• No uptake of SWIM
  

A direct introduction of SWIM occurs when an information exchange requirement that did not exist before is allocated to an information service (e.g. for unmanned aircraft system traffic management (UTM)). In this case there is no corresponding legacy interface to be replaced by an information service.

A transition to SWIM occurs when some form of mix of legacy interfaces and information services exists. Specific transition management aspects need to be taken into account. When in transition, and an information exchange between a legacy interface and an information service is bridged, the risk of information loss needs to be managed. The transition to SWIM is temporary in nature and legacy messages may coexist with information services only until all information consumers have transited to information services.

Finally, there could be no uptake of SWIM when a legacy interface is simply not covered by any future information service. This can be the case if the information shared through the legacy interfaces is not required by future operations. Then, systems supporting only legacy operations may not be affected by the transition, as it is assumed that the legacy interfaces can eventually be phased out when legacy operations stop. The uptake cases are listed in the following table:

From the perspective of a provider organisation having more than one consumer, multiple uptake types could occur. When an organisation maintains both information service and legacy interfaces the evolution towards SWIM is a mixed-mode state. This implies information management aspects in terms of information distribution over legacy interfaces as well as through information services.

SWIM enablers.

The evolution into SWIM does not start from an empty sheet. SWIM enablers, addressesing various aspects of interoperability, support the evolution. SWIM enablers are based on standards and are used to build information services. Some enablers are common to all evolutions and some are context specific.

Examples of common enablers:

Examples of context specific enablers:

The set of common SWIM enablers is complemented with additional enablers addressing business-specific needs. These complementary enablers may be specified before the actual start of a service implementation or may be gradually defined and enriched based on concrete implementation experience, as appropriate.

When assembling the set of SWIM enablers needed to achieve implementation of a given set of information services (e.g. FF-ICE step1), it is important to understand the interoperability requirements in terms of completeness of the set of SWIM enablers and in terms of concreteness of the specification level of each SWIM enabler. Both aspects contribute to a wider consideration of getting the stringency balance of these requirements such that innovation is fostered. To achieve this balance, the common enablers form a baseline that can be complemented with business requirements and implementation context specific SWIM enablers. Specification stringency can vary in terms of role of each SWIM enabler and in terms of maturity of the service orientation along the evolution to SWIM.

When assembling the set of SWIM enablers needed to achieve implementation of a given set of information services (e.g. FF-ICE step1), it is important to understand the interoperability requirements in terms of completeness of the set of SWIM enablers and in terms of concreteness of the specification level of each SWIM enabler. Both aspects contribute to a wider consideration of getting the stringency balance of these requirements such that innovation is fostered. To achieve this balance, the common enablers form a baseline that can be complemented with business requirements and implementation context specific SWIM enablers. Specification stringency can vary in terms of role of each SWIM enabler and in terms of maturity of the service orientation along the evolution to SWIM.