Working towards the next version of the SWIM Supporting Material

Page tree

Working towards the next version of the SWIM Supporting Material

Skip to end of metadata
Go to start of metadata

This section 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.

More information

The Get into SWIM presentations show how the service orientation process is used when developing a service. It is presented in conjunction with the Interoperability Architecture.

Service Orientation Process

introduction

 process overview [+]

Service orientation activities are grouped in four generalized process steps: identify, design, implement and deploy. These steps cover the wide range of activities that service orientation may involve when performed "top-down", starting from requirements and ending up in a running service instance available for operational use. It is important to realize that there is no singular standardized overall service orientation process. The right method to follow to achieve service orientation depends on context. In reality approaches may be top-down (architecture driven) or bottom-up (productivity driven). Furthermore, service orientation may be more or less complex. A collaborative engineering approach may define the specific documents used (e.g. Operational Services & Environment Description (OSED), Service Identification Document, etc...). Ultimately service orientation process steps lead to a good member of the services ecosystem. It is good service orientation practice to involve SWIM stakeholders since they constitute an integral part of the buy-in between service providers and consumers when fostering re-use (e.g. service consumer contributing to service design).

the (ID)²steps

 the Identify step [+]

Identify: service identification is the set of activities involved in documenting the operational context of the service in relation to the business need, information exchange requirements (IER), non-functional requirements (NFR), and operational scope.

Examples of activities:

  • Description of an operational environment in which service orientation is envisaged.
  • Determination of operational process (e.g. business process analysis using business process models (BPM)) leading to the identification of information exchanges assigned to information service(s) (e.g. in response to a new business opportunity).
  • Determination of information exchange requirements (IER) and non-functional requirements (NFR) related to information service(s).
  • Investigation of existing information service(s) for possible re-use, as-is or with some modification.
  • Characterization of the identified information service in terms of functionality.

Outcomes:

  • Documentation of operational processes and information flows.
  • Identification of one or more information service(s), with determination of operational context (scope), requirements, and functionality.
  • Service identification information (name, abstract, operational context, IERs, NFRs and functionality).

Experts involved: operational expert, service architect, data/information architect.

Building blocks: Operational Services & Environment Description (OSED), Business Process Modelling and Notation (BPMN), list of existing services

 the Design step [+]

Design: service design is the set of activities involved in expressing what the service does and how it works. Service design practitioners typically use a modelling language notation (e.g. UML) to represent the blueprint of the information service as a service model (e.g. including service interfaces, service operations, and service payload). Service design is typically used when multiple service providers run the same service and collaboratively define it (i.e. service blueprints are are the same but instances are different). Making service design information available before implementing a service instance (e.g. as a standard) is a good SWIM practice that can lead to harmonization of implementation.

Examples of activities:

  • Selection of the message exchange pattern (MEP).
  • Definition of the service (interface, service operations and information service payload).
  • Sharing of service description information (e.g. using a SWIM Service Registry).

Outcome:

  • Chosen MEP.
  • Service model (service interface(s), service operation(s), service behaviour).
  • Service payload (the logical representation of the information exchanged by the service interface operations).
  • Service design information expressing what the service does and how it works (i.e. the blueprint of the service).
  • Service Overview with "prospective status", to announce future availability of a service.

Experts involved: service architect, data/information architect, technical infrastructure expert.

Building blocks: list of MEPs, list of service designs, UML, AIRM, …

 the Implement step [+]

Implement: service implementation is the set of activities where the information service is implemented in a target environment and technology context. Service implementation involves testing and validation. The data format used to implement the information is based on an information exchange model (XM), or a profile thereof, or a new data format is defined. A service interface protocol is chosen from the list of technical infrastructure protocol standards. These protocols are grouped into interface bindings. Both the choice for an XM and technology details may already be available from the design step.

Examples of activities:

  • Selection or definition of the data format.
  • Definition of the message(s) used to interact with the service interface.
  • Selection of the service interface protocols.
  • Implementation of service(s) using technology and based on implementation choices made.
  • Integration of the service(s) into the target environment.
  • Verification and testing of the service(s).
  • Validation of the service(s).

Outcome:

  • Chosen XM or other data format.
  • Chosen service interface protocol.
  • Message definition.
  • Implemented service(s) (interfaces and operations).
  • Machine readable service definition.
  • Verification report, validation report.
  • Service Overview (update).
  • Verification report.
  • Validation report.
  • Service implementation information (e.g. service interface protocols and QoS characteristics).

Experts involved: solution expert, technical infrastructure expert, service architect, data/information architect, operational expert.

Building blocks: lists of standards (e.g., formats, technical infrastructure protocols/bindings),...

 the Deploy step [+]

Deploy: service deployment is the set of activities where the information service instance is made available for use in operation.

Examples of activities:

  • Deployment of the information service instance with an addressable end-point used in operations.
  • Completion of the description of the service for service consumers.
  • Registration of the information service instance to enable discovery of the service (e.g. using a SWIM Service Registry to publicize the service overview).

Outcome:

  • A configured information service running and available for operational use by service consumers.
  • Completed Service Overview, publicized with "operational status", to announce operational availability of the service.

Experts involved: solution expert, service architect.

Building blocks: no examples provided since the building assumed completed at this stage.

and more

 expert roles involved [+]

The following section describes the expert roles involved in service orientation. These roles are separated but combinations of them could reside in the same person.

Business Expert: defines the business function, mission statements and value chain. Essentially the business expert sets the business needs in accordance with the directions of the organisation as defined by its stakeholders.

Operational Expert: key contributor to operational concept descriptions and performs the role of operational subject matter expert. In order to capture collaborative processes, the operational expert contributes to the documentation of processes under the form of for example BPMs. Operational experts also contribute to the documentation of information exchange requirements (IER) and non-functional requirements (NFR) in relation to the information exchanges. To accomplish their tasks in the context of service orientation, it is good practice to assist operational experts with service and data/information architects with the necessary skills to re-express the topic under work into (collaborative) services that will meet the requirements, promote re-use, and are feasible in terms of implementation.

Service Architect: responsible for service orientation. The service architect uses an operational concept, BPMs, IERs, and NFRs to drive the service orientation process steps. Typically, a service architect collaborates with an operational expert to identify information services that establish an information exchange fostering re-use. Service architects support operational experts with business process analysis and modelling skills. Service architects work closely together with data/information architects on the information service payload aspects. Service architects may also be active at the implementation level and collaborate with technical infrastructure experts and solution implementers.

Data/Information Architect: overall the data/information architects are responsible for the definition and representation of required data and information in the context of the information service payload. Data/information architects use the IERs to assemble the information service payload based on defined information and structure the information service payload for implementation purposes. Data/information architects may be specialised in one of the ATM information domains and provide the corresponding subject matter expertise. Data/information architects work closely together with service architects.

Technical Infrastructure Expert: overall the technical infrastructure experts are responsible for the standardisation of the technical infrastructure used to execute information services and to perform the actual information exchange. The technical infrastructure expert provides the expertise needed to ensure that the information exchange is performed in a trusted, reliable and overall secure way. Technical infrastructure experts collaborate with service architects to ensure that the technical infrastructure meets the NFR of the information services.

Solution expert: responsible for the implementation of SWIM services and SWIM-enabled applications. For example, a solution expert integrates a consuming client into an application to create a SWIM enabled application, which consumes an information service, or implements a running instance of an information service (service provider side). The solution expert builds applications based on the applicable service designs and standards.

 using a service [+]

Making good use of a service – fitness for purpose

Doc 10039 Volume II introduces the notion of Service Overview to capture the scope of the service description information required by ICAO. A potential service consumer uses the Service Overview to discover information about a service and make an initial evaluation of the applicability of a service.

Following a positive initial assessment using the Service Overview, service consumer experts will need to continue the analysis. Using additional service description information made available by the service provider they will target further understanding of the service (what it does, how the service works, how to access it, and the feasibility to implement a consuming client) as covered by the requirements expressed by the EUROCONTROL Specification for SWIM Service Description.