Interoperability Architecture

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


Business activities


Business terms


Technology standards

 

 

 

 


Business processes


Operational language


Service eco-system

 

 

 

 


IER, NFR and Use Cases


Exchanged information


Service behaviour and Service payload

 

 

 

 


Actors


Implementable representation of information


Implementable representation of service

 

 

 

 

Interoperability Architecture Grid

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.

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