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] is the outcome of a specific [Public Policy Cycle] that aims at addressing the needs of a group of stakeholders. The [Interoperable Digital Public Services Implementaiton Orientations] provides public policy goals. The policy is formulated and implemented with the help of [Legal Act] in the form of either [Binding Instruments] or [Non-Binding Instruments]. A key type of legislation for behavioural interoperability is the [Legislation on Data, Information and Knowledge exchange] which together with the [Legisaltion Catalogue] and [Legal Agreements/International Treaties] form a [Shared Legal Framework]. [Legislation Catalogue] aggregates [Legal Act].
[Legal Authority] signs [Legal Agreements / International Treaties] and triggers the [Public Policy Cycle]. [Legal Interoperability Agreement] are a specialisation of the [Legal Agreements /Interational Treaties] focused on formalizing governance rules enabling collaboration between digital public services. [Legal Interoperability Agreement] mandates [Legal Interoperability Specification]. 

These different Architecture Building Blocks define the [Legal Interoperability content] and have their interoperability aspects defined by [Legal Interoperability Specification] which are a specialisation of [Interoperability Specification].

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: [Business Information] is represented by a [Representation], which is stored as [Data]. [Data] can be grouped in [Data Sets], which can be documented in [Data Set Catalogues] or in [Ontologies] which can be grouped in [Ontologies Catalogues] or in [Data Mappings] which can be grouped in [Data Mapping Catalogues]. A [Legal Act] has also a [Representation] which is stored as [Data] and [Legal Acts] can request the definition or use of specific [Data Sets]. [Data] has a specific [Data Owner] that is responsible of its management, together with [Public Service Consumer] and [Public Service Provider] and all negotiate and reach a [Semantic Agreement] and/or a [Semantic Interoperability Agreement], which is a specialisation of [Semantic Agreements]. [Data] is subject to [Data Policies], which also influence its [Representation]. Specific cases of [Data Policies] are [Master Data Policy], [Data portability Policy], [Open Data Policy], [Descriptive Metadata Policy], [Privacy Policy] and [Security Policy]. [Reference Data Policy] and [Base Registry Data Policy] are specialisations of [Master Data Policy]. 

These different Architecture Building Blocks define the [Semantic content] and [Semantic Governance Content], each of these Architecture Building Blocks can have any [Semantic Interoperability Specification] associated, which are a specialisation of [Interoperability Specification]. The [Semantic Interoperability Specifications] are divided in [Data Models], of which [Core Data Models] and [Data Entities] are specialisations, and which implement the semantic interoperability associated with the data, and [Data Syntaxes], which implement the syntactic interoperability. An [Interoperability Specification] realizes an [Interoperability Principle].

The Technical - 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 Interoperable European Solutions. An Interoperable European Solution can support one or more public policies.

Narrative: An [Interoperable European Solution Service] implements [Public Service] and is supporting a [Public Policy]. An [Interoperable European Solution Service] can be accessed through [Machine to Machine Interfaces] or [Human Interfaces] in the [Application Presentation and Access Enablers] assigned to [Application Services]. [Interoperable European Solution Component] realizes [Interoperable European Solution Service]. The [Interoperable European Solution Component] is tested through the use of [Application Test Enablers]. Data can be exchanged, cross-border and cross-sector, with the support of [Application Mediation Enablers] containing the logic for data transfer and validation. [Interoperable European Solution Component] can execute complex business processes through [Application Workflow Enablers].  Access control is managed through the services offered by [Application Security Enablers].

The Architecture Building Blocks defined in the [Interoperable European Solution] which is mandated by a [Technical Agreement] or by its specialisation, [Technical Interoperability Agreement] and can have [Technical Interoperability Specification] associated, which are specialisation of [Interoperability Specification] and of [Technical Specification].

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 Interoperable European 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.

An [Interoperable European Solution] and its application components make use of cross-sectorial [Digital Service Infrastructures]. It provides access to data through [Infrastructure Data Source Enablers] such as [Forms Management Service], [e-Archiving Service], [Data Warehouse Service], [Content Management Service] or [Metadata Management Service]. The [Data] can be archived using [e-Archiving Services] or [Data Warehouse Services] and published to external data sources with a [Data Publication Service]. [Infrastructure Discovery Enablers] enables to register the system services within a catalogue through the [Service Regulation Service]. [Infrastructure Financial Transaction Enablers] enables the use of [e-Payment Services] to digitally execute financial transactions. [Infrastrucutre Translation Enablers] enable the possibility to increase the accessibility to public service through [Machine Translation Services]. [Infrastructure Privacy Enablers] enables the possibility to store, secure, anonymise, pseudonymise, rectify and erase personal data through [Privacy Services]. Trust between systems is established with [Trust Service Provisioning Components] realised using Signature validation and verification such as [e-Signing Creation Service], [e-Signature Verification and Validation Service], [e-Signature Preservation Service], and through e-Seal services such as [e-Seal Creation Service], [e-Seal Verification and Validation Service], [e-Seal Preservation Service], and e-timestamping services such as [e-Timestamp Creation Service], [etimestamp Verification and Validation Service]. Identity management is realised with [Identity Management Service]/[Identity Management Component]. Evidence of transaction between parties is realised using the [Registered Electronic Delivery Service]. The [Interoperable European Solutions] and the [Digital Service Infrastructures] are deployed and operated through [Hosting and Networking Services Infrastructures], provided by a [Public / Private Hosting Facility], and make use of a [Public / Private Network] to exchange data. 

The Architecture Building Blocks defined in both the [Digital Service Infrastructure]
and the [Hosting and Network Service] can have any [Interoperability Specification]
associated, of which the [Technical Interoperability Specification] is a specialisation.
[Technical Interoperability Specification] is also a specialization of [Technical
Specification].

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 Interoperable European 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.

An [Interoperable European Solution] and its application components make use of cross-sectorial [Digital Service Infrastructures]. It provides access to data through [Infrastructure Data Source Enablers] such as [Forms Management Service], [e-Archiving Service], [Data Warehouse Service], [Content Management Service] or [Metadata Management Service]. The [Data] can be archived using [e-Archiving Services] or [Data Warehouse Services] and published to external data sources with a [Data Publication Service]. [Infrastructure Discovery Enablers] enables to register the system services within a catalogue through the [Service Regulation Service]. [Infrastructure Financial Transaction Enablers] enables the use of [e-Payment Services] to digitally execute financial transactions. [Infrastrucutre Translation Enablers] enable the possibility to increase the accessibility to public service through [Machine Translation Services]. [Infrastructure Privacy Enablers] enables the possibility to store, secure, anonymise, pseudonymise, rectify and erase personal data through [Privacy Services]. Trust between systems is established with [Trust Service Provisioning Components] realised using Signature validation and verification such as [e-Signing Creation Service], [e-Signature Verification and Validation Service], [e-Signature Preservation Service], and through e-Seal services such as [e-Seal Creation Service], [e-Seal Verification and Validation Service], [e-Seal Preservation Service], and e-timestamping services such as [e-Timestamp Creation Service], [etimestamp Verification and Validation Service]. Identity management is realised with [Identity Management Service]/[Identity Management Component]. Evidence of transaction between parties is realised using the [Registered Electronic Delivery Service]. The [Interoperable European Solutions] and the [Digital Service Infrastructures] are deployed and operated through [Hosting and Networking Services Infrastructures], provided by a [Public / Private Hosting Facility], and make use of a [Public / Private Network] to exchange data. 

The Architecture Building Blocks defined in both the [Digital Service Infrastructure]
and the [Hosting and Network Service] can have any [Interoperability Specification]
associated, of which the [Technical Interoperability Specification] is a specialisation.
[Technical Interoperability Specification] is also a specialization of [Technical
Specification].

The Interoperability Governance viewpoint models the most salient Architecture Building Blocks that refer to decisions on interoperability frameworks, institutional arrangements, organisational structures, roles and responsibilities, policies, agreements and other aspects of ensuring and monitoring interoperability at national and EU levels. As such, it does not include operational Architecture Building Blocks like interoperability agreements.

Interoperability governance is the key to a holistic approach on interoperability, as it brings together all the instruments needed to apply it.

Source: The New EIF
https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf

Narrative: The selected Architecture Building Blocks from the five different views highlight the Architecture Building Blocks of the EIRA that are related to Interoperability Governance:
1. The selected Architecture Building Blocks of the legal view show the [Public Policy Cycle] and the [Legal Interoperability Agreement],
2. The selected Architecture Building Blocks of the organisational view show that [Data Owner] signs [Organisational Interoperability Agreement]. The [Interoperability Strategy] implements the [Interoperability Framwork], which influences the [Security Framework], the [Privacy Framework], the [Interoperable skill] and the [Interoperability governance]. The [Interoperability Governance] is under the responsibility of the [Interoperability Organisational Authority]. 
3. The selected Architecture Building Block of the semantic view show that [Data Policy] and its specialisation [Descriptive Metadata Policy], [Data Portability Policy], [Open Data Policy] [Master Data Policy], [Base Registry Data Policy] and Reference Data Policy], together with the [Semantic Interoperability Agreement] are the mainstream of the solution governance at semantic level.
4. The selected Architecture Building Blocks of the technical view show [Technical Interoperability Agreement], which are the mainspring of the solution governance at technical level.
5. The selected Architecture Building Blocks of the EIF Underlying Principle view show that [Interoperability Specifications] realise [Interoperability Principles], the general intended properties used to achieve interoperability. The Interoperability Specifications can be used to define the interoperability aspects for any of the Architecture Building Blocks.

Interoperability Governance viewpoint ABBs

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] (the GDPR itself).
2. The selected Architecture Building Blocks of the organisational view show that the roles of [Public Service Consumer] and [Public Service Provider] in the delivery of a [Public Service] are impacted by GDPR. Specific privacy roles are indeed associated to these roles by GDPR. All [Exchanges of Business Information] are impacted if the associated [Business Information] involve personal data of a [Citizen]. A [Privacy Framework], aligned with GDPR, needs then to be associated to the [Business Capability] implemented by the [Exchange of Business Information].
3. The selected Architecture Building Blocks of the semantic view show that
[Data] and [Data Sets], if involving personal data, are impacted by GDPR, as
a relevant [Data Policy], respecting the [Privacy Framework], needs to be
applied.
4. The selected Architecture Building Blocks of the Technical View show that
many service involving data are impacted by the privacy regulation, such as
[Data Transformation Service], [Data Validation Service], [e-Archiving Service], [Data Publication Service], [Data Exchange Service]. Additionally, a [Privacy Service] implementing GDPR principle can be used to ensure compliance.
 

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
https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf

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 show that a [Security and Privacy Framework] is a specialisation of a [Security and Privacy Policy] which on its turn is a specialisation of an [Organisational Policy]. The [Organisational Policy] is influenced by the [Publicinfluences [Data Policy].
3.    The selected Architecture Building Block of the semantic view shows the [Data Policy] which is a specialisation of aninfluenced by [Organisational PolicySecurity Framework].
4.    The selected Architecture Building Blocks of the technical views show that a [Public Policy] is supported by an [Interoperable European Solution] which uses a [Digital Service Infrastructure]. An [Interoperable European Solution] is associated with a [Machine to Machine Interface] and a [Human Interface]. An [Access Management Service], which is realised by an [Access Management Component], and an [Audit Service], which is realised by an [Audit Component] are defined as [Application Security Enablers]. [Data Policies] and a [Security and Privacy Framework], which is a specialisation of a [Security and Privacy Policy], are [Organisational Policies] that are influenced by the [Public Policy]. [Infrastructure Security Enablers] such as [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], which are all realised by a [Trust Service Provisioning Component] are modelled as [Infrastructure Security Enablers], as well as the [Data Exchange Service] realised by the [Data Exchange Component], the [Identity Management Service] realised by the [Identity Management Component] and the [Trust Registry Service] realised by the [Trust Registry Component]. 
5.    The selected Architecture Building Block of the EIF Underlying Principles view show that [Interoperability Specifications] realise [Interoperability Principles], the general intended properties used to achieve interoperability, of which the [Security and Privacy Principle] is a specialisation. The interoperability Specifications can be used to define the interoperability aspects for any of the Architecture Building Blocks.

The Interoperability specification viewpoint models the most salient Architecture Building Blocks that shall be considered when providing interoperability specifications. It provides an overview of Architecture Building Blocks from the different views, and depicts them as a taxonomy of interoperability specifications. Each EIRA© view has Architecture Building Blocks that support interoperability.

Each view’s interoperability specifications serve to define the interoperability aspects of catalogues and registries, addressing both their contents and the respective catalogue or registry as a whole. Given the linked nature of the EIRA©’s views, the interoperability specifications from all views can be considered to affect each individual catalogue or registry. However, the focus in each case is kept within the specific view to best capture the level of detail that each view’s specifications deal with.
Narrative: An [Interoperability Specification] is a [Specification] and can be composed of other [Interoperability Specifications]. It exists at the four levels of interoperability defined in the European Interoperability Framework. 
This viewpoint selects Architecture Building Blocks from the five different views highlighting the interoperability specification related Architecture Building Blocks of the EIRA©:

Narrative:
1.    The selected Architecture Building Blocks of the legal view shows that a [Legal Interoperability Specification] defines the interoperability aspects for is associated to a [Public Policy Formulation and Implementation Instrument], of which a [Binding Instrument] is a specialisation, and defines the interoperability aspects for a [Legislation Catalogue]. [Legal Interoperability Content]
2.    The selected Architecture Building Blocks of the Organisational view shows that an [Organisational Interoperability Specification] describes defines the interoperability aspects for [Governance Content] and [Operational Content]an [Interoperability Agreement], a [Public Service Catalogue] and/or the [Exchange of Business Information]. 
3.    The selected Architecture Building Blocks of the semantic view shows that a [Semantic Interoperability Specification] defines the interoperability aspects for [Data Set Catalogues] as well as the interoperability aspects for [Representations]. [Semantic Content]
4.    The selected Architecture Building Blocks of the Technical view shows that a [Technical Interoperability Specification] is a [Technical Specification], it defines the interoperability aspects for [Interoperable European Solution] and [Digital Service Infrastructure]of a [Machine to Machine Interface], a [Human Interface], a [Network] and/or a [Service Registry Component]. The [Service Registry Component] provides a mechanism to register technical services within a catalogue to be discovered by others. 
5.    The selected building block of the EIF Underlying Principle view show that [Interoperability Specifications] realise [Interoperability Principles], the general intended properties used to achieve interoperability. The interoperability Specifications can be used to define the interoperability aspects for any of the Architecture Building Blocks.

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 behavioural 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 organisations 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: colaboration, seamless execution, reuse of services and data, and development of new services and ‘building blocks'.
 
(*)DECISION (EU) 2015/2240 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 establishing a programme on interoperability solutions and common frameworks for European public administrations, businesses and citizens (ISA2 programme) as a means for modernising the public sector.
 
The Key Interoperability Enablers viewpoint covers all EIF interoperability aspects: legal, organisational, semantic and technical. Ensuring interoperability when preparing legal instruments, organisation business processes, data/information/knowledge exchange, services and components that  support European interoperable digital public services is a continuous task, as interoperability is regularly disrupted by changes to the environment, i.e. in legislation, the needs of businesses or citizens, the organisational structure of public administrations, the business processes, and by the emergence of new technologies.
 
Source: The New EIF
https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf

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 [Achieving Legal Interoperability] is realised by a shared legal framework of [re]usable legal resources that enables:
structural interoperability by legal resources supporting reusing and/or sharing legislation (i.e. legislation catalogue  enabling provisioning/consuming legal texts cross public administrations and cross borders);
behavioural interoperability by legal resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. Legislation on knowledge, information and data exchange enabling that data/information/knowledge be provisioned/consumed cross public administrations and cross borders ); and
governance interoperability by legislation supporting the collaboration with internal/external peers exchanging data, information or knowledge (i.e. Legal Interoperability Agreements on legal terms assuring juridical certainty enabling agreed legal terms/conditions for sharing, reuse and exchange of data/information/knowledge cross public administrations and cross borders). 
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. public services 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. service delivery model enabling that data/information/knowledge 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 Agreements 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 Technical Interoperability] is realised 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 enabling provisioning/consuming data, information and knowledge cross public administrations and cross borders); 
behavioural interoperability by semantic resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. Metadata mappings enabling that data/information/knowledge be provisioned/consumed cross public administrations and cross borders); and governance interoperability by semantic resources supporting the collaboration with internal/external peers exchanging data, information or knowledge (i.e. Sematic Interoperability Agreements on interpretations enabling sharing, reuse and exchange of data/information/knowledge cross public administrations and cross borders).  
5.    Particularly, the goal of [Achieving Semantic Interoperability] is realised by a shared platform of [re]usable ICT resources (i.e. the platform) that enables:
i) Structural interoperability by ICT resources  supporting reusing and/or sharing of data, information and knowledge (i.e. service registry service enabling provisioning/consuming [back-office] services cross public administrations and cross borders); ii) Behavioural interoperability by ICT resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. technical interfaces enabling that data/information/knowledge be provisioned/consumed cross public administrations and cross borders); an iii) Governance interoperability by ICT resources supporting the collaboration with internal/external peers exchanging data, information or knowledge (i.e. Technical Interoperability Agreements on technical terms/conditions enabling sharing, reuse and exchange of data/information/knowledge cross public administrations and cross borders).