Chapter #2 Key Concepts and Archimate® Notation

This section elaborates on the key concepts behind EIRA©. It also explains how the ArchiMate® language is used by the EIRA© and how ArchiMate® modelling tools can be used to design solution architectures and document solutions.

Key concepts in EIRA©

Figure 4 illustrates the key concepts of the EIRA© and their relationships. The terminology is based on TOGAF®.

The following list explains the different relationships depicted in Figure 4:

The EIRA© has EIRA© Views, each EIRA© view aligns with one or more EIF Interoperability Levels
Each EIRA© view has EIRA© Architecture Building Blocks
The EIRA© has EIRA© Viewpoints that conform to EIRA© Views
An EIRA© Architecture Building Block is modelled as a specialisation of a TOGAF® Architecture Building Block
A Key Interoperability Enabler is an EIRA© Architecture Building Block, which is necessary to enable the efficient and effective delivery of public services across administrations;
An EIRA© Architecture Building Block has interoperability requirements. An Interoperability Requirement is a statement of an interoperable need that must be realised by a system. Interoperability Requirements can be formulated for all the EIF interoperability levels: Legal Interoperability Requirements, Organisational Interoperability Requirements, Semantic Interoperability Requirements, and Technical Interoperability Requirements.
Interoperability requirements are grouped in Interoperability Aspects. An Interoperability Aspect is an externally observable characteristic or a set of characteristics to be provided/supported by the solution that fulfils partially or internally a stakeholder interoperability need.
An Interoperability Specification is a document containing agreed normative statements for solution building blocks used in an information exchange context. It can refer to existing standards or specifications. An Interoperability Specification realises an Interoperability Requirement.
An EIRA© Solution Building Block is a realisation of an EIRA© Architecture Building Block and a specialization of a TOGAF® Solution Building Block
A Solution consists of EIRA© Solution Building Blocks and TOGAF® Solution Building Blocks

The key concepts of the EIRA© are defined as follows:

EIF interoperability level: The European Interoperability Framework (EIF) is a set of guidelines for developing public services. Figure 4 depicts the interoperability levels of the EIF. They cover legal, organisational, semantic, and technical interoperability. Each level deserves special attention when a new European public service is established.
EIF principle: The European Interoperability Framework outlines 12 underlying principles of European public services. These general principles of good administration are relevant to the process of establishing European public services. They describe the context in which European public services are decided and implemented. They complement one another regardless of their different natures, e.g. legal or technical. More information on the EIF interoperability levels and principles can be found in the European Interoperability Framework (EIF).
EIRA© view: The EIRA© consists of several views, including one view for each of the EIF interoperability levels. The EIRA© views contain a graphical notation of the EIRA© ontology.
EIRA© viewpoint: The EIRA© provides several viewpoints that conform to EIRA© views, the viewpoints provide a perspective with specific stakeholders' concern in mind.
Architecture Building Block: Based on the TOGAF® definition, an Architecture Building Block is an abstract component that captures architecture requirements and that directs and guides the development of Solution Building Blocks. An ABB represents a (potentially re-usable) component of legal, organisational, semantic, or technical capability that can be combined with other Architecture Building Blocks. An Architecture Building Block describes generic characteristics and functionalities. Architecture Building Blocks are used to describe reference architectures, solution architecture templates or solution architectures of specific solutions.
Solution Building Block: Based on the TOGAF® definition, a Solution Building Block is a concrete element that defines the implementation and fulfils the required business requirements of one or more Architecture Building Blocks. On the technical view, a Solution Building Block is a specific product or software component and may be either procured or developed.
Solution Architecture Template (SAT): A solution architecture template (SAT) is a specification containing including a sub-set of Architecture Building Blocks of the EIRA© and some optional Solution Building Blocks. It focuses on the most salient building blocks needed to build an interoperable solution addressing a particular business capability involving business information exchange.
A solution architecture template can include additional interoperability specifications. It is usually applied within a community. Acting as a template for solutions (and their specific architectures), it guides the development of certain kinds of solutions (and their specific architectures). A solution architecture template can exist on different levels of details. For example, it can be used to describe a template for national portals offering e-services to its citizens. It can also be used to describe a template on how to securely exchange files among public administrations.
Reference Architecture: Architecture is the structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time. A reference architecture is a generalized architecture of a solution, based on best-practices, domain neutral and, occasionally, with a focus on a particular aspect. The goal of a reference architecture is reusability; it reduces the amount of work, reduces errors and accelerates the development of solutions. A reference architecture should be based in a [reference] model and in a style. The model covers the ontology of the components and their interrelationships and in the case of EIRA© it is ArchiMate®. The architecture style covers the architecture design principles and patterns and in the case of the EIRA© it is “Service Oriented Architecture” (SOA). The focus of the EIRA© is interoperability in public administrations. This definition of “reference architecture” needs to be complemented with the notion of Enterprise Architecture, which is an end-to-end generic domain neutral approach to design the architecture of an enterprise or a solution. The goal of an enterprise architecture is to align IT-related activities with the overall goal of the enterprise.
Solution Architecture: Based on TOGAF®, a solution architecture is “a description of a discrete and focused business operation or activity and how information systems / technical infrastructure supports that operation. A Solution Architecture typically applies to a single project or project release, assisting in the translation of requirements into a solution vision, high-level business and/or IT system specifications, and a portfolio of implementation tasks”. Within the context of the EIRA©, the solution architecture describes the specific architecture of a solution. It can be derived from a solution architecture template.
Solution. A solution consists of one or more Solution Building Blocks to meet a certain stakeholder need. Within the context of the EIRA©, a solution is usually an Interoperable European Solution developed by public administrations that facilitate the delivery of electronic Public Services and cross-border exchange of information between public administrations or Citizens in support to the implementation and advancement of EU, national or local public policies.

A solution architecture template can include additional interoperability specifications. It is usually applied within a community. Acting as a template for solutions (and their specific architectures), it guides the development of certain kinds of solutions (and their specific architectures). A solution architecture template can exist on different levels of details. For example, it can be used to describe a template for national portals offering e-services to its citizens. It can also be used to describe a template on how to securely exchange files among public administrations.

A solution architecture template consists of the following:

A goal and a description of the particular supported business capabilities and the involved business information exchanges;
A sub-set of EIRA© core Architecture Building Blocks covering all EIRA© views;
A set of specific Architecture Building Blocks extending EIRA©'s views enabling specific functionalities to be provided by implementations derived from the SAT;
A set of interoperability specifications for Architecture Building Blocks in the SAT;
A narrative for each EIRA© view.

In several countries inside and outside Europe (Germany, Canada, Denmark, USA, Norway), large-scale Enterprise Architecture projects have in the past successfully been executed, and national or sectorial reference architectures are in place notably in the Netherlands (NORA (10)) and in Denmark (eHealth Reference Architectures (11)).

The particular context of the EIRA© and its mission is interoperability, and architectural patterns are typically captured in the form of solution architecture templates (see above).

Similar to how the EIF serves as a blueprint and inspiration for the National Interoperability Frameworks, the EIRA© can serve as the basis for reference architectures at other levels (European national, regional, local or even inside an organisation), taking the specificities of the respective level into account (e.g. national law) while remaining compatible.

Where the EIRA© itself is domain-neutral, it can be extended to create domain-specific architectures.

Viewed as an architecture content metamodel, the EIRA© provides for coordination and alignment between derived reference architectures.

The EIRA© consists of the following components:

A set of EIRA© architecture core Architecture Building Blocks to meet interoperability needs;
A set of interoperability specifications;
A narrative for each view.

ArchiMate® notation

The EIRA© uses the ArchiMate® language as a notation. In fact, the EIRA© can be considered as an extension of the ArchiMate® language, using two of the extension mechanisms foreseen by ArchiMate® (1): specialisation (stereotyping) and attributes. This section first provides an overview of the ArchiMate® model concepts that are used by the EIRA©. It then elaborates on how EIRA© ABBs can be seen as a specialisation of ArchiMate® model concepts. Finally, it elaborates on the attributes on model concepts that are predefined by the EIRA©.

ArchiMate® model concepts

The EIRA© uses ArchiMate® 3.2 model concepts

The EIRA© version 6.1.0 uses the following ArchiMate® 3.2 relationships:

Specialisation and stereotyping

The EIRA© ABBs can be seen as a specialisation of ArchiMate® model concepts. Specialisation is an extension mechanism for the ArchiMate® language that is foreseen by the ArchiMate® specification (1). For example, Figure 5 models that the ABB ‘Service’ in EIRA© is a specialisation of the ArchiMate® model concept ‘Business Service’.

The EIRA© does not introduce a new graphical notation for a specialised ArchiMate® model concept.

Linking Solution Building Blocks (SBBs) to Architecture Building Blocks (ABBs)

When using EIRA© in combination with ArchiMate® to represent Solution Building Blocks, it is recommended to use stereotypes, as indicated by <<stereotype>>. The word stereotype is replaced by the name of the Architecture Building Blocks. For example, Figure 6 illustrates how a public service ‘Declaration of birth’ is represented as an EIRA© ‘Public Service’ using stereotyping. In Section 4 an overview is given of the focal Architecture Building Blocks in the EIRA©. A Solution Building Block can relate to multiple Architecture Building Blocks by delimiting the list as such: <<LegalActRequirement, EuropeanLegalActRequirement, …>>.

Attributes

The ArchiMate® language has another extension mechanism, which allows defining sets of types of attributes (called profiles), which provide a means to express supplementary information. The EIRA© includes a set of attributes that stem from the following sources:

Dublin Core Metadata Terms (DCMT): is a standardized set of metadata elements that provides a basic vocabulary for describing resources. It provides a flexible and widely adopted framework for describing digital resources, enabling better discovery, access, and management of information in a variety of contexts.
- ABB name (dct:type): Used to specify the name of the ABB. (e.g. dct:type eira:LegalAct).
- Modification date (dct:modified): the date when the ABB or its metadata was modified.
Simple Knowledge Organization System Reference (SKOS): SKOS is designed to provide a simple and flexible framework for expressing the relationships and concepts found within these KOS, with the goal of enabling better discovery, navigation, and retrieval of information.
- Example (skos:example): provides an example of the ABB being implemented, and SBB that can be specific or possible options to realise an ABB.
- Definition (skos:definition): the definition of an ABB or SBB.

Describing Architecture Building Blocks and Solution Building Blocks using the DCMT and SKOS attributes provides important descriptive metadata that can be used by others to better understand what an ABB and a SBB are about.

Additionally, EIRA has defined specific properties under the EIRA domain and name space that provide detailed information about the elements described:

- eira:PURI: provides the identifier of the element under the EIRA name space.
- eira:definitionSource: specifies the source for the definition of the ABB.
- eira:definitionSourceReference: specifies the URL for the definition source, allowing to track where the information comes from.
- eira:synonym: refers to examples of synonyms to the ABB.
- eira:concept: identifies if the element being described is an ABB, a SBB or an EIRA Ontology element.
- eira:view: indicates in which view (LOST views) the element is included.
- eira:iopSaliency: includes a description of the reason why the ABB or SBB are relevant and salient to achieve interoperability.
- eira:iopPrimaryDimension: includes the main interoperability dimension for the element (Structural, Behavioural, or Governance)
- eira:iopSecundaryDimension: includes additional dimensions where the element can act (Structural, Behavioural, or Governance)

This contributes to the ‘Document interoperability solution’ use case described in Section 2.3.

Use of colours

The default views of the EIRA© leverage the standard colours of ArchiMate® to depict the corresponding Architecture Building Blocks: business (yellow), application (blue) and infrastructure (green). However, the EIRA© recognises the architects’ need to leverage colour codes for communication purposes. It, therefore, does not impose any colouring rules.

Tools and support

This section illustrates how architects can use ArchiMate® modelling tools like Archi®[1] to model solution architectures or to document solutions.

The EIRA© release contains an XML file which contains the ArchiMate® model of the EIRA©. This file which follows the “Open Group ArchiMate® Exchange File Format” can be opened with Archi®, a free and open-source modelling tool to create ArchiMate® models as well as other tools that support this format.

The ArchiMate® file groups the different building blocks, relations and views into the following folders:

Relations
- This folder contains all relations shown on the EIRA© views;
- Relations only in the model: relations between concepts that are needed in the model but not in the view. For example, all application services are specialisations of the Application Service building block.
Views
- Legal view;
- Organisational view;
- Semantic view;
- Technical view - application;
- Technical view - infrastructure.
Viewpoints:
- Enterprise Architecture Framework alignment guidelines viewpoint;
- High-level viewpoint;
- Interoperability Governance viewpoint;
- Interoperability Privacy viewpoint;
- Interoperability Security viewpoint;
- Interoperable European Solution viewpoint;
- Key Interoperability Enablers viewpoint;
- Ontology viewpoint;
- REST API viewpoint;

Note: It is possible to work directly within the standard EIRA© views. However, the best practice is to create new views or viewpoints to keep the integrity of the standard EIRA© views. The standard EIRA© views can then still be consulted for reference purposes.

The Cartography tool (CarTool©) is released as a separate tool in the form of an open-source Archi® plugin. This tool serves a twofold purpose:

on the one hand, it facilitates the stereotyping (see section 3.2.3 above) and description of attributes when documenting solutions based on EIRA©, and
on the other hand, it also enables Architects to directly consult the “European Interoperability Cartography Solutions” from within the modelling tool, to discover reusable Solution Building Blocks.

Report abusive content Share