Interoperability Architecture

This article introduces the interoperability architecture. It is provided as an example on how to organise the building blocks used in SWIM.

Introduction

The interoperability architecture is provided as an example on how to organise the building blocks used in SWIM.

It is not intended to replace specific architectures that organisations may already have in place. Instead, it is a utility to be used, when nothing else exists, by experts to work together in a structured way when developing SWIM and working towards agreements on interoperability.

The interoperability architecture does not rely on any particular service development process (such as the Service Orientation Process). Furthermore, it is not tied to any one enterprise architecture framework. By adopting the gridded approach, detailed later, different frameworks can be mapped to the cells.

When to use the interoperability architecture

Typical usages include using the architecture as a way to ensure that different organisations can have a shared view of the building blocks when working together.

More Information

The Get into SWIM presentations show how the interoperability architecture is used when developing a service. It is presented in conjunction with the Service Orientation Process.

Interoperability Architecture Grid

The interoperability architecture is structured along three views (organisational, information and technical) and four levels (contextual, conceptual, logical and physical).

Organisational

Information

Technical

Contextual

Capture the business activities to be considered from an organisational interoperability point of view.

Capture the scope of the ATM business terms for which a common and consistent representation is required.

Capture the standards and technology choices that constrain the service implementation.

Conceptual

Capture the business processes in support of the business activities.

These can be used to identify services.

Capture the operational language.

Capture semantics of metadata in the service eco-system – e.g. based on ISO 19115.

Capture the service eco-system

Logical

Capture uses cases and use case scenarios to help understand the service’s functionality (a grouping of business processes).

Capture the information exchange requirements.

Capture the non-functional requirements.

Capture the exchanged information.

Capture the behaviour of the service, its operations and interfaces.

Capture the service payload.

Physical

-

Capture an implementable representation of the exchanged information.

Capture an implementable representation of the service including the service payload schema.

Views

Organisational View

The Organisational View captures the organisational interoperability related building blocks necessary to drive the development of the needed information services.

The architecture building blocks (ABB) within the Organisational View enable the identification of loosely coupled services as a sequence of steps aligned with business goals.

The Organisational View support the following SOA needs:

  • Ability to visualise information exchange flows between participants.
  • Ability to visualise processes where the exchanged information is suitable for service development.
  • Ability to agree the needs for services based on business rules, policies, information exchange requirements and other business requirements.
Information View

The Information View captures the information interoperability related building blocks necessary to perform meaningful information exchange using information services. The architecture building blocks within the Information View enable the development of a unified representation of the information assets of ATM.

The Information View supports the following SOA needs:

  • Ability to support information services with a shared, common and consistent expression of information/data.
  • Ability to integrate information across diverse actors and organisations to communicate effectively across the different organisational domains.
  • Ability to define the metadata used across the ATM network.
  • Ability to support business process modelling.
Technical View

The Technical View captures the technical interoperability related building blocks necessary to drive the implementation of compatible solutions. The architecture building blocks within the Technical View enable the development of the infrastructure needed to support the SOA solution throughout the SOA lifecycle.

The Technical View support the following SOA needs:

  • Ability to restrict the technologies used in a solution in order to facilitate a greater degree of interoperability.
  • Ability to agree a set of common components of the infrastructure to run the SOA e.g. PKI

Levels

The Views are divided into levels. This is done to highlight the fact that the building blocks can be at different levels of abstraction.

  • Contextual. The Contextual Level contains general elements such as terms and lists of standards which provide the scope for the view.
  • Conceptual. The Conceptual Level contains descriptions on a level that are generally understandable to a business expert e.g. it adds the relationships between the elements within the context.
  • Logical. The Logical Level contains detailed and highly structured elements needed to develop technical building blocks. For example, this level adds more details such as adding typing information.
  • Physical. The Physical Level usually contains the same level of detail as the logical layer but adds information to facilitate the actual use of the elements in the view.

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