Chapter #3 Views, Viewpoints and Architecture Building Blocks

Home page

Previous section

Next section

 

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;
    • Interoperability Specification viewpoint;
    • Key Interoperability Enablers 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

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] 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].

Legal view ABBs
Binding Instrument
Interoperability Specifications
Legal Act
Legal Authority
Legal Interoperability Agreement
Legal Interoperability Specifications
Legislation Catalogue
Non-Binding Instrument
Public Policy Cycle
Shared Legal Framework
Public Policy
Legislation on data information and knowledge exchange
Legal agreements/ International treaties
Architecture Requirement
Interoperability Requirement
Solution specification

Organisational View

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 interoperable digital public services.

Narrative: [Organisations] in the role of [Public Service Providers] supply [Interoperable Digital Public Service] to [Citizens] and [Businesses] and/or [Public Administrations] which have the role of [Public Service Consumer]. [Interoperable Digital Public Service] is a specialisation of [Service], which is delivered according to its [Service Delivery Model]. [Interoperable Digital Public Services] and [Services] enables [Public Administrations] to realise [Digital Business Capabilties] by accessing [Business Information]. [Services] are documented in [Public Service Catalogues] that can be used among others for service portfolio management. The [Public Service Catalogue] is part of a [shared Governance framwork] as the [Organisational Agreement] and the [Service Delivery Model]. [Interoperable Digital Public Services] are designed and implemented following an [Interoperable Digital Public Service Implementation Orientation]. [Public Service Providers] can delegate the delivery of [Public Services] to [Public Service Delivery Agents] who will act on behalf of [Public Service Providers]. [Public Service Providers], [Data Owners] and [Public Service Consumer] can sign an [Organisational Agreement] and [Organisational Interoperability Agreement], which is a specialisation of [Organisational Agreement], to agree on how to deliver a [Public Service] to its users. The [Interoperability Organisational Authority] is responsible for [Interoperability Governance] which influences the [Interoperability Strategy]. The [Interoperability Strategy] implements the [Interoperability Framework].  [Interoperability Skills] are a specific form of [Organisational Skills] that allows the organisation to excel in interoperability. A [Security Framework] is a specific form of a [Security Policy] which is an [Organisational Policy] focussed on security related aspects.

These different Architecture Building Blocks define the [Organisational content] and [Govenrnace Content] and each of these Architecture Building Blocks can have any [Interoperability Specification] associated, of which the [Organisational Interoperability Specification] is a specialisation.

Organisational view ABBs
Business
Business Information
Citizen
Data Owner
Exchange of Business Information
Interoperability Framework
Interoperability Governance
Interoperability Organisational Authority
Interoperability Skill
Interoperability Strategy
Digital Public Service
Interoperable Digital Public Services Implementation Orientation
Interoperability Specification
Organisation
Organisational Interoperability Agreement
Organisational Agreement
Organisational Interoperability Specification
Privacy Framework
Public Administration
Service
Public Service Agent
Public Service Catalogue
Public Service Consumer
Public Service Consumer Agent
Public Service Delivery Agent
Public Service Provider
Security Framework
Service Delivery Model
Shared Governance Framework
Architecture Requirement
Interoperability Requirement
Solution specification

Semantic view

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: [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].

Semantic view ABBs  
Base Registry Data Policy  
Controlled Vocabulary  
Core Data Model  
Data  
Data Entity  
Data Mapping  
Data Mapping Catalogue  
Data Model  
Data Policy  
Data Portability Policy  
Data Set  
Data Set Catalogue  
Data Syntax  
Descriptive Metadata Policy  
Master Data Policy  
Ontology  
Ontologies Catalogue  
Open Data Policy  
Reference Data Policy  
Representation  
Semantic Agreement  
Semantic Interoperability Agreement  
Semantic interoperability Specifications  
Shared Knowledge Base  
Security Policy  
Privacy Policy  
Interoperability Specification  
Architecture Requirement
Interoperability Requirement
Solution specification

Technical view - Application

Technical view - Application

 

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].

Technical view - Application ABBs
Access Management Component
Access Management Service
Audit Component
Audit Service
Data Transformation Component
Data Transformation Service
Data Validation Component
Data Validation Service
Human Interface
Interoperable European Solution
Interoperable European Solution Component
Interoperable European Solution Service
Machine to Machine Interface
Orchestration Component
Orchestration Service
Service Discovery Component
Service Discovery Service
Technical Interoperability Agreement
Technical Agreement
Architecture Requirement
Interoperability Requirement
Solution specification

Technical view - Infrastructure

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 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].

Technical view - Infrastructure ABBs
Conformance Test Report
Conformance Test Scenario
Conformance Testing Component
Conformance Testing Service
Data Exchange Component
Data Exchange Service
Data Publication Component
Data Publication Service
Data Warehouse Service
Data Warehouse Component
Content Management Service
e-Archiving Component
e-Archiving Service
e-Payment Component
e-Payment Service
e-Seal Creation Service
e-Seal Preservation Service
e-Seal Verification and Validation Service
e-Signature Creation Service
e-Signature Preservation Service
e-Signature Verification and Validation Service
e-Timestamp Creation Service
e-Timestamp Verification and Validation Service
Forms Management Component
Forms Management Service
Hosting Facility
Hosting Service
Identity Management Component
Identity Management Service
Machine Translation Component
Machine Translation Service
Metadata Management Component
Metadata Management Service
Network
Networking Service
Privacy Component
Privacy Service
Private Hosting Facility
Private Network
Public Hosting Facility
Public Network
Shared Platform
Registered Electronic Delivery Service
Service Registration Service
Service Registry Component
Interoperability Specification
Technical Interoperability Specification
Technical Specification
Trust Registry Component
Trust Registry Service
Trust Service Provisioning Component
Data Repository
Data Analytics Service
Data Analytics Component
Artificial Intelligence Service
Artificial Intelligence Component
Technological Devices
High Performance Infrastructure
Data Infrastructure
Data Hub
Data Lake
Data Repository Service
Data Repository Component
Architecture Requirement
Interoperability Requirement
Solution specification

EIRA Viewpoints

Conceptual model for Integrated Public Service Provisioning viewpoint

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 [Public Service Consumer] consumes a [Public Service] which is provided by a [Public Service Provider] via a [Service Delivery Model]. This [Public Service] can use other [Public Services] to realise a [Digital Business Capability] and are coordinated via [Orchestration Services]. These services use Internal or external information source and services ([Data], [Interoperable European Solution Services]). [Security and Privacy] principles apply to the entire conceptual model.

Conceptual model for Integrated Public Service Provisioning viewpoint ABBs
Key Interoperability Enablers
Public Service Consumer
Public Service Provider
Service Delivery Model
Digital Public Service
Digital Business Capability
Orchestration Service
Data
Interoperable European Solution Service

EIRA Ontology Viewpoint

EIRA Onotology viewpoint
  • 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 Public Service Agent is an EIRA Architecture Building Block that represents a participant involved in the delivery or consumption of a public service. Public Service Agents are citizens, businesses, organisations, or systems.
  • A Public Service Component is a structural EIRA© Architecture Building Block, i.e. an entity which can perform behaviour (active structure) or on which behaviour is performed (passive structure)
  • 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
     
EIRA Ontology Viewpoint ABBs
Digital Public Service
EIRA Viewpoint
EIRA View
EIF Interoperability Level
EIRA Architecture Building Block
Key Interoperability Enabler
Architecture Building Block
Architecture Principle
EIF Principle
Interoperability Aspect
Interoperability Requirement
Architecture Requirement
Legal Interoperability Requirement
Organisational Interoperability Requirement
Semantic Interoperability Requirement
Technical Interoperability Requirement
Solution Building Block
EIRA Solution Building Block
Interoperability Specification
Solution Specification
Solution

 

Highlevel viewpoint

Highlevel Viewpoints

 

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].

Highlevel viewpoint ABBs
Digital Business Capability
Business Information
Data
Digital Service Infrastructure
EIF Principle
Hosting and Networking Infrastructure
Human Interface
Interoperability Specification
Interoperable European Solution Component
Interoperable European Solution Service
Digital Public Service
Machine to Machine Interface
Public Policy
Public Service Consumer
Public Service Provider
Representation
Shared Governance Framework
Shared Knowledge Base
Shared Legal Framework
Shared Platform
Architecture principle
Solution specification

Interoperability governance viewpoint

Interoperability Governance viewpoint

 

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

Base Registry Data Policy
Data Owner
Data Policy
Security Policy
Privacy Policy
Data Portability Policy
Descriptive Metadata Policy
EIF Principle
Interoperability Framework
Interoperability Governance
Interoperability Organisational Authority
Interoperability Skill
Interoperability Specification
Interoperability Strategy
Interoperable Digital Public Services Implementation Orientation
Legal Interoperability Agreement
Legal Agreement / International Treaties
Master Data Policy
Open Data Policy
Organisational Agreement
Organisational Interoperability Agreement
Privacy Framework
Public Policy Cycle
Reference Data Policy
Security Framework
Semantic Agreement
Semantic Interoperability Agreement
Technical Agreement
Technical Interoperability Agreement

Interoperability Privacy viewpoint

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] (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.
 

Interoperability Privacy viewpoint ABBs
Binding Instrument
Business
Citizen
Data
Data Exchange Component
Data Exchange Service
Data Owner
Data Policy
Data Publication Component
Data Publication Service
Data Set
Data Mapping
Data Transformation Component
Data Transformation Service
Data Validation Service
Data Validation Component
Data Warehouse Service
Data Warehouse Component
e-Archiving Component
e-Archiving Service
Ontology
Organisation
Privacy Component
Privacy Framework
Privacy Service
Public Administration
Public Policy
Public Service
Public Service Consumer
Public Service Provider
Interoperable Digital Public Service
EIF Principle

Interoperability Security viewpoint

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

Interoperability Security viewpoint ABBs
Access Management Component
Access Management Service
Audit Component
Audit Service
Data Exchange Component
Data Exchange Service
EIF Principle
e-Seal Creation Service
e-Seal Preservation Service
e-Seal Verification and Validation Service
e-Signature Creation Service
e-Signature Preservation Service
e-Signature Verification and Validation Service
e-Timestamp Creation Service
e-Timestamp Verification and Validation Service
Human Interface
Identity Management Component
Identity Management Service
Interoperability Specification
Machine to Machine Interface
Public Policy
Registered Electronic Delivery Service
Security Framework
Security Policy
Trust Registry Component
Trust Registry Service
Trust Service Provisioning Component

 

Interoperability Specification viewpoint

Interoperability Specification viewpoint

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.

Interoperability Specification viewpoint ABBs
Digital Service Infrastructure
EIF Principle
Interoperability Specification
Interoperable European Solution
Legal Interoperability Specification
Organisational Interoperability Specification
Semantic Interoperability Specification
Technical Interoperability Specification

 

Key Interoperability Enablers viewpoint

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 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).

Key Interoperability Enablers viewpoint ABBs
Data Mapping Catalogue
Data Set Catalogue
EIF Principle
Human Interface
Legal Interoperability Agreement
Legislation Catalogue
Legislation On Data Information And Knowledge Exchange
Machine to Machine Interface
Ontologies Catalogue
Organisational Interoperability Agreement
Public Service Catalogue
Semantic Interoperability Agreement
Service Delivery Model
Service Registration Service
Shared Governance Framework
Shared Knowledge Base
Shared Legal Framework
Shared Platform
Technical Interoperability Agreement
Achieve Legal Interoperability
Achieve Organisational Interoperability
Achieve Semantic Interoperability
Achieve Technical Interoperability
Represenation