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.
Interoperability Architecture Grid
The interoperability architecture is structured along three views (organisational, information and technical) and four levels (contextual, conceptual, logical and physical).
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.
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
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.
Capture an implementable representation of the exchanged information.
Capture an implementable representation of the service including the service payload schema.
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.
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.
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
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
- 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
- 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.
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.
- 1. Session Approach
- 2. Identify Services for A-CDM
- 2.a Define IER wih AIRM
- 2.b Define NFR
- 3. Design TOBT Setting Service
- 3.a Design MEP
- 3b Design Payload
- 3c Interface Binding
- 3d Registration
- 4. Design Flight Publication Service
- 4a Service Design
- 5. Session Conclusion
Last revision: June 26, 2019