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.
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 New 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 New 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 a 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 a certain kind 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 a certain kind 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 (9), 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 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.
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©.
The EIRA© uses the following ArchiMate® 4.9.2 model concepts
The EIRA© version 5.0.0 uses the following ArchiMate® 4.9.2 relationships:
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.
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 : <<ABB1, ABB2, …, ABBn>>.
The ArchiMate® language has another extension mechanism, which allows defining sets of types attributes (called profiles), which provide a means to express supplementary information. The EIRA© includes a set of attributes that stem from the following sources:
- ADMS Description metadata: The Asset Description Metadata Schema (ADMS) provides a standard way to describe Solution Building Blocks. The ADMS is itself based on metadata standards like the Dublin Core metadata elements. Some attributes include for example:
- Description (dct:description): a description of the Solution Building Block.
- Landing page (dcat:landingPage): A Web page that can be navigated to in a Web browser to gain access to the Solution Building Block.
- Status (adms:status): The status of a Solution Building Block. Suggested values are ‘completed’, ‘deprecated’, ‘underDevelopment’, and ‘withdrawn’.
Describing Solution Building Blocks using the ADMS attributes provides important descriptive metadata that can be used by others to better understand what a Solution Building Block is about. This contributes to the ‘Document interoperability solution’ use case described in Section 2.3.
The full set of attributes are included in the ArchiMate® model file (.xml) of the EIRA© release.
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’ needs 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® 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:
- 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.
- Legal view;
- Organisational view;
- Semantic view;
- Technical view - application;
- Technical view - infrastructure.
- API viewpoint
- Conceptual Model for Integrated Public Service Provisioning viewpoint;
- EIRA Ontology viewpoint;
- High-level viewpoint;
- Interoperability Privacy viewpoint;
- Interoperability Governance viewpoint;
- Interoperable European Solution viewpoint;
- Interoperability Security viewpoint;
- Key Interoperability Enablers viewpoint.
Note: It is possible to work directly within the standard EIRA© views. However, 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.
Cartography tool (CarTool©)
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 enable Architects to directly consult the “TES Cartography” or “National Cartographies” from within the modelling tool, to discover reusable Solution Building Blocks.