Service Orientation Process

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.

Introduction

Process overview

Service orientation activities are grouped in four generalized process steps:

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

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

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).

Outcomes:

  • 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, …

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).

Outcomes:

  • 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),...

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).

Outcomes:

  • 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.

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 the interoperability architecture. It is provided as an example on how to organise the building blocks used in SWIM.

  Access


Last revision: June 26, 2019