This section provides a description of the views, viewpoints and most salient (focal) Architecture Building Blocks in the EIRA©. Each architecture view and viewpoint has a visual diagram, a narrative, and a set of focal Architecture Building Blocks:
- The visual diagram depicts the Architecture Building Blocks in the EIRA©. It can be conceived as a part of the EIRA© architecture content metamodel, which extends the ArchiMate® model concepts, as explained in Section 3.2.2. It shows how the EIRA© Architecture Building Blocks are related to each other, and which ArchiMate® concepts are used to depict them.
- The narrative is a textual description of the view providing natural language statements.
- The focal Architecture Building Blocks are building blocks that create the interconnections with Architecture Building Blocks related to other views.
The remainder of this section introduces the Architecture Building Blocks in the EIRA© structured according to the following architectural models:
- The Legal view;
- The Organisational view;
- The Semantic view;
- The Technical view (composed of an application and infrastructure part);
- The European Interoperability Framework underlying principles view;
- Viewpoints:
- Conceptual Model for Integrated Public Service Provisioning viewpoint
- EIRA Ontology viewpoint
- High-level viewpoint
- Interoperability Governance viewpoint
- Interoperability Privacy viewpoint
- Interoperability Security viewpoint
- Key Interoperability Enablers viewpoint
- API viewpoint
- Interoperable European Solution viewpoint
When the direction of an ArchiMate® relation between two entities is unclear (this is the case when using the assignment relation only); the EIRA© uses the following convention: The relation between two entities is always modelled in a top-down, left to right fashion. The top entity refers to the subject of a sentence, the bottom entity refers to the object of a sentence. When the two entities are at the same level, it is the left entity that refers to the subject and the right entity that refers to the object.
Given the size of the models, the images in this section had to be scaled down. However, full width images are available in the annex of this document together with the list of Architecture Building Blocks.
EIRA Views
Legal View

The Legal view models the most salient public policy development enablers and implementation instruments that shall be considered in order to support the End to End design of interoperable digital public services. Narrative: A [Public Policy] aims at addressing the needs of a group of stakeholders, and it associated with a [Public Policy Objective]. The policy is formulated and implemented with the help of [Legal Act] which contain [European Legal act] and [National Legal act] in the form of either [Binding Instrument] or [Non-Binding Instrument]. A key type of legislation for behavioral interoperability is the [Legislation on Data Information and Knowledge Exchange] which together with the [Legislation Catalogue] and [Legal Agreement] aggregate a [Shared Legal Framework]. [Legislation Catalogue] aggregates [Legal Act] which contain [European Legal act] and [National Legal act] and realised the [Public Policy] and [Granularity of Legal Requirements]. Also [Legislation on Data Information and Knowledge Exchange] aggregate [Legal Act]. [Legal Interoperability Agreement] are a specialisation of the [Legal Agreements] focused on formalizing governance rules enabling collaboration between digital public services. These different Architecture Building Blocks define the [Legal Governance content] and the [Legal Functional content] and have their interoperability aspects defined by [Interoperability Specification]. |
Legal view ABBs |
Legal Agreement |
Legal Interoperability Agreement |
Public Policy Cycle |
Shared Legal Framework |
Architecture Principle |
Detail-Level Architecture Requirement |
Solution Specification |
Binding Instrument |
Non-binding Instrument |
Granularity of Legal Requirements |
Legislation on Data Information and Knowledge Exchange |
Public Policy Objective |
Public Policy |
Legal Act |
European Legal Act |
National Legal Act |
Legislation Catalogue |
Organisational View

The Organisational view models the most salient Architecture Building Blocks that shall be considered in order to support organisational aspects for the End to End design of Digital Public Services.
Narrative: [Digital Public Service] is delivered according to its [Digital Service Delivery Model] and realizes a [Digital Business Capability] by accessing [Information] given by a [representation] in conjunction with an [ontology] that enables the enactment of [information] in a given digital public service context. [Digital Public Service] is documented in [Digital Public Service Catalogue] that can be used among others for service portfolio management. The [Digital Public Service Catalogue] aggregate the [Shared Governance Framework] as the [Organisational Agreement] and the [Digital Service Delivery Model]. [Digital Public Delivery Model] is composed by [Digital Public Service Delivery Machine Agent] and [Digital Public Service Delivery Human Agent] which both serves a role [Agent]. [Agent] is assigned with a stakeholder [Legal Entity] which is the specialization of other stakeholders such us [Organization] and [Individual]. [Organization] is also a specialization of [Public Administration] and [Business]. An [Agent] can act both like [Digital Public Service Provider] and [Digital Public Service Delivery Consumer]. Both of roles are aggregated with [Digital Public Service Delivery]. [Organisational Agreement], of which [Organisational Interoperability Agreement] is a specialisation. Also [Framework Agreement] is composed with [Organizational Agreement] which also associate with [Data Owner] and [Digital Governance] which is a specilization of [Security Governance]. The [Digital Governance] associate with [Interoperability Framework], [Security Framework], and [Privacy Framework]. Also [Digital Governance] is associate with [Digital Agenda] which is a realization of [Digitalization Roadmap] which realize the [Interoperable Public Service Implementation Orientation].
These different Architecture Building Blocks define the [Organisational Governance content] and [Organisational Functional content] and each of these Architecture Building Blocks can have any [Interoperability Specification] associated, of which the [Solution Specification] is a specialisation. Both the contents are defined by [Architecture Requirement], of which the [Interoperability Requirement] is a specialization.
Organisational view ABBs |
Means for Public Policy Objectives Convergence Assurance and Control |
Specific Agreement |
Framework Agreement |
Organisational Agreement |
Data Owner |
Organisational Interoperability Agreement |
Delegation of Powers Provisioning Digital Public Services |
Interoperable Digital Public Service Implementation Orientation |
Digitalisation Roadmap |
Digital Agenda |
Interoperability Strategy |
Information Risk Management Component |
Digital Governance |
Security Governance |
Interoperability Framework |
Security Framework |
Privacy Framework |
Shared Governance Framework |
Architecture Principle |
Detail-Level Architecture Requirement |
Solution Specification |
Digital Public Service Delivery Model |
Business |
Organisation |
Public Administration |
Legal Entity |
Individual |
Agent |
Digital Public Service Delivery Machine Agent |
Digital Public Service Delivery Human Agent |
Digital Public Service Delivery Consumer |
Digital Public Service Delivery |
Digital Public Service Delivery Provider |
Digital Public Service |
Digital Public Service Catalogue |
Digital Business Capability |
Information |
Semantic view
![]() |
The Semantic view models the most salient Architecture Building Blocks that should be considered in order to support semantic aspects for the End to End design of interoperable Digital Public Services. Narrative: [Data] is stored as [Representation]. [Data] can be grouped in [Data Sets], which can be documented in [Data Set Catalogues] or in [Ontology] which can be grouped in [Ontologies Catalogue] or in [Data Mappings] which can be grouped in [Data Mapping Catalogue].[Virtual Data Set] are composed with [Data Set] and [Base Registry], [Reference Data] and [ Data Policies] are specialization of [Data Set].[Metadata] is a specialization of [Data].[Forms Strictures], [Data Syntax], [Data Model], [Controlled Vocabulary] and [Hash Code] are specialization of [Metadata] . [Open Data] are specialization of [Data], and [Legal Act Representation] is specialization of Representation]. [Data] has a specific [Data Owner] that is responsible of its management, together with [Digital Public Service Delivery Consumer] and [Digital Public Service Delivery Provider Provider] and all negotiate and reach a [Semantic Agreement] and/or a [Semantic Interoperability Agreement], which is a specialisation of [Semantic Agreement].Also [Specific Agreement] is composed with [Semantic Agreement]. [Data] is subject to [Data Policy], which also influence its [Representation]. Specific cases of [Data Policy] are [Master Data Policy], [Data portability Policy], [Open Data Policy], [Privacy Policy] and [Security Policy]. [Data], [Data Policy] and [Semantic Agreement] are aggregated with [Shared Knowledge Base] These different Architecture Building Blocks define the [Semantic Functional content] and [Semantic Governance Content], each of these Architecture Building Blocks can have any [Architecture Requirement] associated, of which [Solution Specification] is a realisation. The [Interoperability Specification], which is a specialisation of [Solution Specification], is divided in [Data Model], of which [Core Data Model] and [Data Entities] are specialisations, [Controlled Vocabulary] and [Data Syntax]. |
Semantic view ABBs | |
Semantic Interoperability Agreement | |
Master Data Policy | |
Open Data Policy | |
Data Portability Policy | |
Security Policy | |
Privacy Policy | |
Data Policy | |
Semantic Agreement | |
Shared Knowledge Base | |
Architecture Principle | |
Detail-Level Architecture Requirement | |
Solution Specification | |
Data Mapping Catalogue | |
Data Mapping | |
Distributed Ledger | |
Ontologies Catalogue | |
Ontology | |
Data Set Catalogue | |
Data Set | |
Base Registry | |
Reference Data | |
Data Policies | |
Virtual DataSet | |
Legal Act Representation | |
Representation | |
Data | |
Open Data | |
Metadata | |
Hash Code | |
Controlled Vocabulary | |
Data Model | |
Data Syntax | |
Forms Structure |
Technical view - Application
![]()
|
The Technical - Application Domain specific view contains the most salient application Architecture Building Blocks that need to be considered in order to support technical aspects for the End to End design of Digital Solutions. A Digital Solution can support one or more public policies. Narrative: [Interoperable Digital Solution] is composed with [Shared Platform], where it provides access to data .The [Interoperable Digital Solution] includes [Machine to Machine Interface] with [Human Interface] which both realize [Digital Public Service Delivery] which assign [Digital Public Service] which realize [Digital Business Capability]. Also [Machine to Machine Interface] and [Human Interface] assign [Digital Solution Service] which realized by[Outsourcing Strategy Solution] and [Digital Solution Component] which serving by [Computing Hosting Networking, and Data Hosting In fracture] and realized by [Outsourcing Strategy Solution]. [Interoperable Digital Solution] influenced by [Technical Agreement].[Technical Agreement] is composed with [Specific Agreement] and associate with [Digital Public Service Delivery Consumer] and [Digital Public Service Delivery Provider]. The Architecture Building Blocks defined in the [Digital Solution] can have [Interoperability Specification] associated, which is a specialisation of [Solution Specification] and also realises [Interoperability Requirement]. |
Technical view - Application ABBs |
Technical Agreement |
Technical Interoperability Agreement |
Saas |
PaaS |
IaaS |
Architecture Principle |
Detail-Level Architecture Requirement |
Solution Specification |
Interoperable Digital Solution |
Machine to Machine Interface |
Human Interface |
Digital Solution Service |
Digital Solution Component |
Shared Platform |
API Discovery and Catalogue Service |
API Catalogue |
API |
Service Registry |
Service Discovery and Registry Service |
Software Component Discovery and Catalogue Service |
Software Components Catalogue |
API Catalogue Component |
Web Service |
Service Registry Component |
Software Component Catalogue Component |
Orchestration Service |
Orchestration Component |
Firewall Service |
Firewall Component |
Audit Service |
Audit Component |
Conformance Testing Service |
Conformance Testing Component |
Conformance Test Scenario |
e-Signature Creation Service |
e-Seal Creation Service |
e-Timestamp Creation Service |
Integrity Verification Service |
Blockchain Service |
e-Signature Verification and Validation Service |
e-Seal Verification and Validation Service |
e-Timestamp Verification and Validation Service |
Blockchain Component |
e-Signature Preservation Service |
e-Seal Preservation Service |
Registered Electronic Delivery Service |
Trust Service Provisioning Component |
Authentication Service |
Request Validation Service |
Registration Service |
Directory |
Access Management Service |
Identity management Service |
Authorisation Service |
Accounting Service |
Identification Component |
Access Management Component |
Data Exchange Service |
Data Exchange Component |
Ontological Class Mapping Catalogue Service |
Ontological Class Mapping Catalogue |
Data Syntax Mapping Catalogue Service |
Metadata Management Service |
e-Archiving Service |
Data Management Service |
Content Management Service |
Forms Management Service |
Data Publication Service |
Data Extraction, Transformation, and Loading Service |
Data Quality Service |
Ontological Class Mapping Catalogue Component |
Data Syntax Mapping Catalogue |
Data Syntax Mapping Catalogue Component |
Metadata Management Component |
e-Archiving Component |
Data Management Component |
Forms Management Component |
Data Publication Component |
Data Extraction, Transformation, and Loading Component |
Data Quality Component |
Privacy Service |
Privacy Component |
Knowledge Discovery Component Service |
Knowledge Triplestore |
Knowledge Discovery Component |
Data Analytics Service |
Artificial Intelligence Service |
Data Analytics Component |
Artificial Intelligence Component |
Machine Translation Service |
Machine Translation Component |
UX Management Service |
MyDigitalPublicServicesDeliveryPreferences Service |
MyInfo Service |
MyCalendar Service |
MySingleWindow Service |
UX Management Component |
MyDigitalPublicServicesDeliveryPreferences Component |
MyInfo Component |
MyCalendar Component |
MySingleWindow Component |
Digital Workplace Service |
Digital Workplace Component |
e-Payment Service |
e-Payment Component |
eProcurement Accessing Service |
eProcurement Contracting Service |
eProcurement Evaluating Service |
eProcurement Notifying Service |
eProcurement Quoting Service |
eProcurement Accessing Component |
eProcurement Contracting Component |
eProcurement Evaluating Component |
eProcurement Notifying Component |
eProcurement Quoting Component |
eProcurement Awarding Service |
eProcurement Discovering Service |
eProcurement Fulfilling Service |
eProcurement Ordering Service |
eProcurement Submitting Service |
eProcurement Awarding Component |
eProcurement Discovering Component |
eProcurement Fulfilling Component |
eProcurement Ordering Component |
eProcurement Submitting Component |
eProcurement Invoicing Service |
eProcurement Invoicing Component |
Technical view - Infrastructure
![]()
|
The Technical - Infrastructure view provides an architecture content metamodel for the most salient cross-sectorial infrastructure services, along with the supporting hosting and networking facilities, which shall be considered in order to support technical aspects for the End to End design of Digital Solutions. The difference with the application part of the Technical view is that the Architecture Building Blocks in the infrastructure view are considered to be relevant for solutions in any sector of government. Narrative: The Architecture Building Blocks defined in both the [Digital Service Infrastructure] and the [Computing Hosting, Networking, and Data Hosting Infrastructure] can have any [Interoperability Specification] associated, of which the [Solution Specification] is a specialization. |
Technical view - Infrastructure ABBs |
Technical Agreement |
Technical Interoperability Agreement |
Architecture Principle |
Detail-Level Architecture Requirement |
Solution Specification |
Outsourcing |
Saas |
PaaS |
IaaS |
Computing Hosting, Networking, and Data Hosting Infrastructure |
Application Service |
Data Access Service |
Intranet Service |
Remote Desktop Service |
VPN Service |
Web Service |
On Premise Facility |
Application Interface |
Data Interface |
Intranetwork Service |
Remote Desktop Interface |
Terminal Interface |
VPN Interface |
Internet Interface |
Application Server |
Host Application |
Application Server Software Environment |
High Performance Server |
Data Server |
Data Space |
Host Data Management |
Data Virtualization |
Data Warehouse |
Data Server Software Environment |
Data Lake |
Data Hub |
Triplestore |
Knowledge |
Intranet Server |
Internal Website |
Internal Web Application Database |
Intranet Application |
Intranet Server Environment |
Remote Desktop Services Server |
Virtual Private Network Server |
VPN Application |
VPN Server Environment |
Web Server |
External Website |
Front-end Firewall |
External Web Application Database |
Web Application |
Web Server Environment |
Internet |
VPN Path |
VPN Client Device |
VPN Client |
Sensor |
Smart Device |
Extranet Firewall |
User Terminal |
Back-end Firewall |
Enterprise Service Bus |
EIRA Viewpoints
Conceptual model for Integrated Public Service Provisioning viewpoint

The Conceptual Model for Integrated Public Service Provisioning promotes reusability as a driver for interoperability, recognising that the European public services should reuse information and services that already exist and may be available from various sources inside or beyond the organisational boundaries of public administrations. Information and services should be retrievable and be made available in interoperable formats. Security and privacy requirements should be considered and measures for the provision of each public service according to risk management plans should be identified. Trust services should be used according to the Regulation on eID and Trust Services as mechanisms that ensure secure and protected data exchange in public services.
Narrative:
A [Digital Public Service] is provided via a [Service Delivery Mode]. This [Public Service] can use other [Public Service] to realise a [Digital Business Capability] and are coordinated via [Orchestration Service]. This service use internal or external ([Data], [Digital Solution Services]). Information source and services . [Key Interoperability Enablers] principles apply to the entire conceptual model.
Conceptual model for Integrated Public Service Provisioning viewpoint ABBs |
Key Interoperability Enablers |
Digital Public Service Delivery |
Digital Public Service |
Digital Business Capability |
Orchestration Service |
Data |
Digital Solution Service |
Security and Privacy |
EIRA Ontology Viewpoint

- DESCRIPTION: [Analysis of a target digital public solution] groups the following ABBs: [Interoperability Dimension] which is associated with the [EIRA Architecture Building Blocks] requirement. the [EIRA Architecture Building Blocks] composes the [EIRA View], which is associated with the [EIF Interoperability Level], aggregates the [EIRA Viewpoint] and is a specialization of the [Key Interoperability Enabler] and [Architecture Building Block] which in turn adds granularity to the [Detail - level Architecture Requirement]. The [Detail - level Architecture Requirement] is a specialist ion of the [Interoperability Requirement] which aggregates all the [Interoperability Aspects]. [Analysis of a target digital public solution] is influenced by [Architecture Principle] which is a specialization of the [EIF Principle] and aggregates the [European Library of Architecture Principle]. [Architecture Principle] influences also the [Solution design of a target digital public service / Documentation of an existing digital public service] which is composed by the [EIRA Solution Building Block] that realizes the [Interoperability Specification] and specializes the [Solution Building Block] that, in turn, is composed by the [Digital Solution] which realizes the [Interoperable Digital Solution]. The [Solution Building Block] realizes the [Solution Specification] that is a specialization of the [Interoperability Specification] which aggregates the [EIRA Library of Interoperability Specifications].
EIRA Ontology Viewpoint ABBs |
Interoperability Dimension |
EIF Interoperability Level |
EIRA View |
EIRA Viewpoint |
Key Interoperability Enabler |
EIRA Architecture Building Block |
Architecture Building Block |
Detail-Level Architecture Requirement |
Interoperability Requirement |
Interoperability Aspect |
EIF Principle |
Architecture Principle |
European Library of Architecture Principles |
EIRA Solution Building Block |
Solution Building Block |
Digital Solution |
Interoperable Digital Solution |
Solution Specification |
Interoperability Specification |
EIRA Library of Interoperability Specifications |
Highlevel viewpoint
![]()
|
The EIRA© Highlevel viewpoint models an introductory overview of the focal Architecture Building Blocks of each view. It aligns the EIRA© with the service delivery model described within the Interoperability Maturity Model (IMM), and the New European Interoperability Framework (EIF) conceptual model for public services. The EIRA© with its views provides a set of Architecture Building Blocks, important to facilitate interoperability. Each view, one for each interoperability level, is represented with the Focal Architecture Building Blocks needed to deliver an interoperable solution. These focal Architecture Building Blocks are indicated with an accented colour. 1. The selected Architecture Building Block of the legal view shows the [Public Policy] realized by the [Legal Act] and [Shared Legal framework] which are the mainspring of the solution. 2. The selected Architecture Building Blocks of the organizational view show a [Shared Governance Framework] that aggregates the [Organizational Functional Content] which considers a [Digital Public Service] which can be an aggregation of other [Digital Public Service]. The [Digital Public Service] realises [Digital Business Capability]. A [Digital Business Capability] describes key functions supporting the [Digital Public Service]. A [Digital Public Service] accesses [Information], which can be an aggregation of other [Information]. At the same time a [Digital Public Service] is assigned by a [Digital Public Service Delivery] which is connected through a serving relation with the [Digital Public Service Delivery Model]. 3. The selected Architecture Building Blocks of the semantic view shows the [Shared Knowledge Base] and that the [Semantic Functional Content] is composed of a [Representation], stored as [Data] and the [Ontology]. 4. The selected Architecture Building Blocks of the technical views - application shows that a [Interoperable Digital Solution Service] is composed of a [Digital Solution Service] realized by a [Digital Solution Component] and lets consumers access it via [Machine to Machine Interface] and/or [Human Interface], which are part of a [Application Presentation and Access Enablers]. A [Digital Solution] exposes one or more [Digital Solution Service] via its [Machine to Machine Interface] and/or [Human Interface]. The [Digital Solution] uses [Digital Service Infrastructure] which uses a [Computing Hosting, Networking, and Data Hosting Infrastructure]. 5. The selected Architecture Building Blocks of the technical views - infrastructure considers the [Computing Hosting, Networking and Data Hosting Infrastructure]. |
Highlevel viewpoint ABBs |
Digital Business Capability |
Data |
Computing Hosting, Networking, and Data Hosting Infrastructure |
Human Interface |
Digital Solution Component |
Digital Solution Service |
Digital Public Service |
Machine to Machine Interface |
Public Policy |
Representation |
Shared Governance Framework |
Shared Knowledge Base |
Shared Legal Framework |
Shared Platform |
Legal Act |
Digital Public Service Delivery Model |
Digital Public Service Delivery |
Information |
Ontology |
Interoperable Digital Solution |
Interoperability Governance viewpoint
![]()
|
The Interoperability Privacy viewpoint highlights the EIRA building blocks that are relevant when implementing the EU General Data Protection Regulation (GDPR) or assessing an existing architecture against the GDPR principles. Public administrations must indeed guarantee the citizens’ privacy, and the confidentiality, authenticity, integrity and non-repudiation of information provided by citizens and businesses. Narrative: The selected Architecture Building Blocks from the five different views highlight the Architecture Building Blocks of the EIRA that are that are relevant with respect to GDPR: 1. The selected Architecture Building Blocks of the legal view show that privacy requirements are coming from a [Public Policy] realised by a [Binding instrument]. 2. The selected Architecture Building Blocks of the organisational view show that the [Privacy Framework] applies to the [Digital Public Service] which is assigned by the [Data Owner] and provided by the [Digital Public Service Provider]. The [Digital Public Service] serves the [Digital Public Service Delivery Consumer], assigned to an [Individual] that is associated to the [Information] accessible though the [Organisation] which is a specialissed by [Public Administration] and [Business]. 3. The selected Architecture Building Blocks of the semantic view show that [Data] aggregates [Data Set], [Ontology] and [Data Mapping] and that it is subject to the [Data Policy]. 4. The selected Architecture Building Blocks of the Technical View shows many service involving data impacted by the privacy regulation, such as 5. The selected Architecture Building Block of the EIF Underlying Principles view show the [EIF Principle], the general intended properties used to achieve interoperability, of which the [Security and Privacy] is a specialisation. The interoperability Specifications can be used to define the interoperability aspects for any of the Architecture Building Blocks. |
Interoperability Governance viewpoint ABBs |
Public Policy Cycle | |
Legal Agreement | |
Legal Interoperability Agreement | |
Means for Public Policy Objectives Convergence Assurance and Control | |
Specific Agreement | |
Framework Agreement | |
Organisational Agreement | |
Data Owner | |
Organisational Interoperability Agreement | |
Delegation of Powers Provisioning Digital Public Services | |
Interoperable Digital Public Service Implementation Orientation | |
Digitalisation Roadmap | |
Digital Agenda | |
Interoperability Strategy | |
Digital Governance | |
Interoperability Framework | |
Security Framework | |
Privacy Framework | |
Semantic Agreement | |
Semantic Interoperability Agreement | |
Master Data Policy | |
Open Data Policy | |
Data Portability Policy | |
Security Policy | |
Privacy Policy | |
Data Policy | |
Technical Agreement | |
Technical Interoperability Agreement |
Interoperability Privacy viewpoint
![]()
|
The Interoperability Privacy viewpoint highlights the EIRA building blocks that are relevant when implementing the EU General Data Protection Regulation (GDPR) or assessing an existing architecture against the GDPR principles. Public administrations must indeed guarantee the citizens’ privacy, and the confidentiality, authenticity, integrity and non-repudiation of information provided by citizens and businesses. Narrative: The selected Architecture Building Blocks from the five different views highlight the Architecture Building Blocks of the EIRA that are that are relevant with respect to GDPR: 1. The selected Architecture Building Blocks of the legal view show that privacy requirements are coming from a [Public Policy] realised by a [Binding instrument]. 2. The selected Architecture Building Blocks of the organisational view show that the [Privacy Framework] applies to the [Digital Public Service] which is assigned by the [Data Owner] and provided by the [Digital Public Service Provider]. The [Digital Public Service] serves the [Digital Public Service Delivery Consumer], assigned to an [Individual] that is associated to the [Information] accessible though the [Organisation] which is a specialissed by [Public Administration] and [Business]. 3. The selected Architecture Building Blocks of the semantic view show that [Data] aggregates [Data Set], [Ontology] and [Data Mapping] and that it is subject to the [Data Policy]. 4. The selected Architecture Building Blocks of the Technical View shows many service involving data impacted by the privacy regulation, such as 5. The selected Architecture Building Block of the EIF Underlying Principles view show the [EIF Principle], the general intended properties used to achieve interoperability, of which the [Security and Privacy] is a specialisation. The interoperability Specifications can be used to define the interoperability aspects for any of the Architecture Building Blocks. |
Interoperability Privacy viewpoint ABBs |
Public Policy |
Binding Instrument |
Organisation |
Information |
Individual |
Digital Public Service Delivery Consumer |
Public Administration |
Business |
Digital Public Service |
Digital Public Service Delivery Provider |
Data Owner |
Privacy Framework |
Virtual DataSet |
Data Set |
Ontology |
Data Mapping |
Data |
Data Policy |
Data Extraction, Transformation, and Loading Service |
Data Quality Service |
Data Publication Service |
e-Archiving Service |
Metadata Management Service |
Data Exchange Service |
Data Management Service |
Data Management Component |
Data Exchange Component |
Metadata Management Component |
e-Archiving Component |
Data Publication Component |
Data Quality Component |
Data Extraction, Transformation, and Loading Component |
EIF Principle |
Security and privacy |
Interoperability Security viewpoint
![]()
|
The Interoperability Security and Privacy viewpoint models the most salient Architecture Building Blocks related to both security and privacy in the domain of interoperability. Citizens and businesses must be confident that when they interact with public authorities they are doing so in a secure and trustworthy environment and in full compliance with relevant regulations, e.g. the Regulation and Directive on data protection, and the Regulation on electronic identification and trust services. Public administrations must guarantee the citizens’ privacy, and the confidentiality, authenticity, integrity and non-repudiation of information provided by citizens and businesses. Security and privacy are primary concerns in the provision of public services. When public administrations and other entities exchange official information, the information should be transferred, depending on security requirements, via a secure, harmonised, managed and controlled network. Transfer mechanisms should facilitate information exchanges between administrations, businesses and citizens. Appropriate mechanisms should allow secure exchange of electronically verified messages, records, forms and other kinds of information between the different systems; should handle specific security requirements and electronic identification and trust services such as electronic signatures/seals creation and verification; and should monitor traffic to detect intrusions, changes of data and other type of attacks. Source: The New EIF Narrative: This viewpoint selects Architecture Building Blocks from the five different view highlighting the Security and Privacy aspects of the EIRA©: 1. The selected Architecture Building Block of the legal view shows the [Public Policy], which is that mainspring of the solution 2. The selected Architecture Building Block of the organisational view shows the [Security Framework], associated with the [Security Governance] which is that mainspring of the solution. 3. The selected Architecture Building Block of the semantic view shows the [Security Policy], which is that mainspring of the solution. 4. The selected Architecture Building Blocks of the technical view Application shows that a [Interoperable Digital Solution], which considers [Human Interface] and [Machine to Machine Interface] is supported by a [Shared platform] which uses [Trust Enablers], [Application Security Enablers], [Identification and Access Enablers] and [Data Exchange Enablers]. [Trust Enablers] such as [Integrity Verification Service], [e-Signature Creation Service], [e-Seal Creation Service], [e-Timestamp Creation Service], [e-Signature Verification and Validation Service], [e-Seal Verification and Validation Service], [e-Timestamp Verification and Validation Service], [e-Signature Preservation Service], [e-Seal Preservation Service] and [Registered Electronic Delivery Service], are all realised by a [Trust Service Provisioning Component]. [Identification and Access Enablers] is composed of [Authentication Service], [Request Validation Service] and [Registration Service] which are realised by [Identification Component] and that provides access to the [Directory], accessed also by the [Access Management Service], realised by the [Access Management Component]. [Application Security Enablers] is realised of [Firewall Service], composed of [Firewall Component] and [Audit Service], which is realised by an [Audit Component]. [Data Exchange Enablers] composed of Data Exchange Service] realised by the [Data Exchange Component]. 5. The selected Architecture Building Blocks of the technical view Infrastructure shows an [Outsourcing Facility] and [On - Premise Facility] composed of [Back End Firewall] and [Extranet Firewall]. 5. The selected Architecture Building Blocks of the EIF Underlying Principles view show that [Interoperability Specifications] realises [EIF Principles], the general intended properties used to achieve interoperability, of which the [Security and Privacy] is a specialisation. The interoperability Specifications can be used to define the interoperability aspects for any of the Architecture Building Blocks. |
Interoperability Security viewpoint ABBs |
Public Policy |
Security Governance |
Security Framework |
Security Policy |
Interoperability Specification |
EIF Principle |
Security and privacy |
Interoperable Digital Solution |
Human Interface |
Machine to Machine Interface |
Shared Platform |
e-Signature Creation Service |
e-Seal Creation Service |
e-Timestamp Creation Service |
Integrity Verification Service |
e-Signature Verification and Validation Service |
e-Seal Verification and Validation Service |
e-Timestamp Verification and Validation Service |
Registered Electronic Delivery Service |
e-Seal Preservation Service |
e-Signature Preservation Service |
Trust Service Provisioning Component |
Firewall Service |
Audit Service |
Firewall Component |
Audit Component |
Authentication Service |
Request Validation Service |
Registration Service |
Identification Component |
Directory |
Access Management Service |
Access Management Component |
Data Exchange Service |
Data Exchange Component |
On-premises Facility |
Extranet Firewall |
Back-end Firewall |
Outsourcing Facility |
Key Interoperability Enablers viewpoint
![]()
|
The Key Interoperability Enablers viewpoint models the most salient key interoperability enablers(*). The viewpoint uses the ArchiMate© motivation extension to assess the structural interoperability readiness, the behavioral interoperability readiness and the governance interoperability readiness of solutions that are necessary to enable the efficient and effective delivery of public services across administrations. European public service provision often requires different public administrations to work together to meet end users’ needs and provide public services in an integrated way. When multiple organizations are involved there is a need for coordination and governance by the authorities with a mandate for planning, implementing and operating European public services. Services should be governed to ensure: collaboration, seamless execution, reuse of services and data, and development of new services and ‘building blocks'. Narrative: This viewpoint selects Architecture Building Blocks of the EIRA© that are key enablers for the interoperability of public services: 1. EIF [Interoperability Principles] are used to realise the overall goal of achieving interoperability. 2. Particularly, the goal of [Achieve Legal Interoperability] is realised by a [Shared Legal Framework] of [re]usable legal resources that enables: 3. Particularly, the goal of [Achieving Organisational Interoperability] is realised by a [Shared Governance Framework] of [re]usable organisational resources that enables: structural interoperability by organisational resources supporting reusing and/or sharing of digital public services (i.e. [Digital Public Service Catalogue] enabling provisioning/consuming public services cross public administrations and cross borders); behavioural interoperability by organisational resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. [Digital Public Service Delivery Model], served by [Digital Public Service Delivery] enabling data/information/knowledge to be provisioned/consumed cross public administrations and cross borders); and governance interoperability by governance resources supporting the collaboration with internal/external peers exchanging data, information or knowledge (i.e. [Organisational Interoperability Agreement] on organisational terms/conditions enabling sharing, reuse and exchange of data/information/knowledge cross public administrations and cross borders). 4. Particularly, the goal of [Achieving Semantic Interoperability] is realized by a [Shared Knowledge Base] of usable data, information and knowledge resources that enables: structural interoperability by semantic resources supporting reusing and/or sharing of data, information and knowledge (i.e. [Data Set Catalogue], [Ontologies Catalogue] and [Data Mapping Catalogue] enabling provisioning/consuming data, information and knowledge cross public administrations and cross borders); behavioral interoperability by semantic resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. [Open Data], [Distributed Ledger] and [Virtual Data Set]; and governance interoperability by semantic resources supporting the collaboration with internal/external peers exchanging data, information or knowledge (i.e. [Semantic Interoperability Agreement] on interpretations enabling sharing, reuse and exchange of data/information/knowledge cross public administrations and cross borders). 5. Particularly, the goal of [Achieving Technical Interoperability] is realised by a [Shared Platform] of [re]usable ICT resources (i.e. the platform) that enables structural interoperability by ICT resources supporting reusing and/or sharing of data, and that realises [Software component Discovery and catalogue Service], [API Discovery and Catalogue Service], [Service Discovery and Registry Service]; at the same time [Shared Platform] realises also [Machine to Machine], [Human Interface], [Data Exchange Service], [UX Management Service] and [Digital Workplace Service]. [Shared Platform] governance interoperability by ICT resources supports also the collaboration with internal/external peers exchanging data, information or knowledge (i.e. [Technical Interoperability Agreements] on technical terms/conditions enabling provisioning/consuming back-office services cross public administrations and cross borders). |
Key Interoperability Enablers viewpoint ABBs |
EIF Principle |
Achieve Legal Interoperability |
Achieve Organisational Interoperability |
Achieve Semantic Interoperability |
Achieve Technical Interoperability |
Shared Legal Framework |
Shared Governance Framework |
Shared Knowledge Base |
Shared Platform |
Legislation Catalogue |
Digital Public Service Catalogue |
Data Mapping Catalogue |
Ontologies Catalogue |
Data Set Catalogue |
Software Component Discovery and Catalogue Service |
API Discovery and Catalogue Service |
Service Discovery and Registry Service |
Key Structural IoP Enablers |
Key Behavioural IoP Enablers |
Legislation on Data Information and Knowledge Exchange |
Digital Public Service Delivery Model |
Digital Public Service Delivery |
Virtual DataSet |
Distributed Ledger |
Open Data |
Machine to Machine Interface |
Human Interface |
Data Exchange Service |
UX Management Service |
Digital Workplace Service |
Key Governance IoP Enablers |
Legal Interoperability Agreement |
Organisational Interoperability Agreement |
Semantic Interoperability Agreement |
Technical Interoperability Agreement |
API viewpoint

The EIRA© API viewpoint models an introductory overview of the focal Architecture Building Blocks required when modelling an API Interface.
The ABBs included in the API viewpoint represent all the required Busilding Block necessary to design an API Interface accessible thoruh a web interface.
Narrative:
A [Client request for service] is made trough [Internet] and it triggers the [Authentication Service] which serves the [Request Validation Service]that triggers the [HTTP(s) Load Balancer] whichin turn triggers all the [Endpoints] related. Each [Endpoint] serves the [Application Service] which triggers the [App Component] that, in turn, triggers the [Data Access Service]. The [Data Access Service] provides access to the [Data Space] which is composed by the [SQL Data Space], [Read - Replica], [NoSQL Data Space] and [Virtual Data Space]. In the moment in which the [Endpoint] is triggered data flows to the [API Response] which is composed by [Data] and [Represenation] accessed by a [Request Validation Service]. The [API Response] triggers the response that is provided to the user who requetd the data in the first instance.
API viewpoint ABBs
Internet |
Client request for service |
Authentication Middleware |
Authentication |
Authentication Service |
Input Validation |
Request Validation Service |
HTTP(S) Load Balancer |
API Response |
Representation |
Data |
Output Validation |
Request Validation Service |
HTTP(S) Load Balancer |
API |
Autoscaling Group |
Application Instance |
API Layer 1 |
Endpoint #1 |
Application Service #1 |
Endpoint #N |
Application Service #N |
Application Component 1 |
App Component #1 |
App Component #N |
Data Access Service |
Data Space |
SQL Data Space |
Read-Replica |
NoSQL Data Space |
Virtual Data Space |
Interoperable European Solution viewpoint

The Interoperable European Solution viewpoint models the most salient Architecture Building Blocks related to the modelling of interoperable solutions across europe. Public administrations must consider all the aspects reported within the viewpoint when creating solution that should consider all the aspects specific to interoperability.
Narrative:
[Interoperable Digital Solution] is composed by a [Shared Platform][Machine to Machine Interface] and [Human Interface]. [Machine to Machine Interface] and [Human Interface] are assigned to the [Digital Solution Component] relised by the [Digital Solution component] and associated with the [Shared Knowledge Base]. [Interoperable Digital Solution] is regulated by a [Shared Legal Framework] and associated with [Shared Governance Framework] which is also associated with [Shared Legal Framework] and [Shared Platform]. The [Shared Legal Framework] regulates also the [Shared Platform].
Interoperable European Solution viewpoint ABBs