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

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

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

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

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].  
[Shared Platform] includes [Discovery Enablers] enables to register the system services in which [Web Service] which is a specialization of [API] realizes [Machine to Machine Interface] and [Human Interface].[API Catalogue Component] realizes [API Discovery and Catalogue Service] which associate with [API Catalogue] which associate with [API]. [Service Registry] is associate with [Web Service] and [Service Discovery and Registry Service] which realized by [Service Registry Component]. [Software Components Catalogue] is associate with [Software Component Discovery and Catalogue Service] which realized by [Software Component Catalogue Component]. [Orchestration Enablers] in which [Orchestration Component] realizes [Orchestration Service].[ Security Enables] in which access control is managed through the services in which Firewall Component realizes [Firewall Service] and [Audit Component] realizes [Audit Service]. [Test Enablers] in which [Conformance Testing Component] accesses [Conformance Test Scenario] and realizes [Conformance Testing Service].Trust between systems is established with Identity management is realised with [Trust Enablers] in which [Trust Service Provisioning Component] realizes [e-Signature Creation Service],[e-signature Verification and Validation Service],[e-signature Preservation Service], [e-Seal Creation Service], [e-Seal Verification and Validation Service], [e-Seal Preservation Service], [e-Timestamp Creation Service], [e-Timestamp Verification and Validation Service], [Registered Electronic Delivery Service] and Integrity Verification Service]. Also [Blockchain Component] realizes [Blockchain Service].In [Identification and Access Enablers] , [Identification Component] realizes [Authentication Service],[Request Validation Service], [Registration Service] which all of three have access to [Directory].Also access here have [Access Management Service] which realized by [Access Management Component]. [ Identity Management Service], [Authorization Service] and [Accounting Service] are specializations of [Access Management Service].In [Data Exchange Enablers] exist [Data Exchange Component] which realizes [Data Exchange Service].In [Data Management Enablers] exist the [Ontological Class Mapping Catalogue Service] which realized by [Ontological Class Mapping Catalogue Component] and associate with [Ontological Class Mapping Catalogue]. Also the [Data Syntax Mapping Catalogue Service] realized by [Data Syntax Mapping Catalogue Component] and associate with [Data Syntax Mapping Catalogue]. [Metadata Management Component realizes [Metadata Management Service]. [e-Archiving Component] realizes [e-Archiving Service]. [Data Management Component] realizes [Data Management Service]. [Forms Management Component] realizes [ Content Management Service] and [Forms Management Service].[Data Publication Component] realizes [Data Publication Service]. [Data Extraction, Transformation, and Loading Component] realizes [ Data ,Extraction, Transformation, and Loading Service]. [Data Quality Component] realizes [Data Quality Service]. In [ Privacy Enablers] exist the [Privacy Component] which realizes the [Privacy Service]. In [Knowledge Discovery Enablers] the [Knowledge Discovery Component] realizes [Knowledge Discovery Component Service] which associate with [Knowledge Triple stone]. In [Analytics Enablers] [Data Analytics Component] realizes [Data Analytics Service] and [Artificial Intelligent Component] realizes [Artificial Intelligent Service] . In [Translation Enablers]enable the possibility to increase the accessibility to public service through [Machine Translation Component] realizes [Machine Translation Service]. In [Users Expierence Management Enablers] the [UX Management Component] in which exist the [MyDigitalPublicServicesDeliveryPreference Component],[MyInfo Component],[MyCalentar Component], [MySingleWindow Component] realizes the [UX Management Service] in which exist  the [MyDigitalPublicServicesDeliveryPreferencesServices],[MyInfoService],[MyCalendar Service] and [MySileWindowService] .In [Digital Workplace Enablers] exist [Digital Workplace Component] which realizes [Digital Workplace Service]. In [Financial Transaction Enablers] enables the use of  [e-Payment Component] which realizes [e-Payment Service]to digitally execute financial transactions. In [Public Procurement Enablers] exist [eProcurement Accessing Component] which realizes [eProcurement Accessing Service] . [eProcurement Contracting Component] which realizes [eProcurement Contacting Service], [eProcurement Evaluating Component] which realizes [eProcurement Evaluating Service], [eProcurement Notifying Component] which realizes [eProcurement Notifying Service], [eProcurement Quoting Service] which realizes [eProcurement Quoting Component],[eProcurement Awarding Component] which realizes [eProcurement Awarding Service], [eProcurement Discovering Component] which realizes [eProcurement Discovering Service], [eProcurement Fulfilling Component], which realizes [eProcurement Fulfilling Service], [eProcurement Ordering Component] which realizes [eProcurement Ordering Service], [eProcurement Submitting Component] which realizes [eProcurement Submitting Service]. In [eProcurement Enablers] exist [eProcurement Invoicing Component] which realized eProcurement Invoicing Service] 

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

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: 
A [Digital  Solution Service] which give access to [Data] is realized by [Digital Solution Component] which is serving by [Computing Hosting, Networking and Data Hosting Infrastructure] and realized by [Outsourcing] which serve [Server].[Computing Hosting, Networking and Data Hosting Infrastructure] providing all the necessary networks through [Application Service], [Data Access Service], [Intranet Service],[Remote Desktop Service],[VPN Service] and [Web Service].[Application Service] is assigned by [Application Interface] and realized by [Host Application] which is a composed of [Application Interface] and with [Application Server Software Environment] its part of [Application Server]. [Application Server] is associating with [Enterprise Service Bus] which flow information  with [Computing Hosting, Networking and Data Hosting Infrastructure].Also [High Performance Server] is a specialization of [Application Server]. [Data Access Service] is assigned with [Data Interface]. Also have access to [Data Space] and realized by [Host Data Management]. [Data Virtualization] is specialization of [Host Data Management] which is serving by [Data Server Software Environment]. [Triplestone], [Data Hub], [Data Lake] and [Data Warehouse] are specialization of [Data Space].[Data Space] and  [Host Data Management] are part of [Data Server] which associate with [Back end Firewall] which associate with [Enterprise Service Bus]. [Intranet Servise] is assigned with [Intranetwork Service] which is composed by [Intranet Application] which serves by [Intranet Server Environment] and realizes [Intranet Service], which have access to [Intranet Website], which have associate with [Intranet Application Database]. Both [Intranet Website] and [Intranet Application] are part of [Intranet Server] which associate with [Enterprise Service Bus].[Remote Desktop Service] is assigned with [Remote Desktop Interface] which is composed by [Remote Desktop Server], which realize [Remote Desktop Service] and associate with [Enterprise Service Bus]. [VPN] Service] assigned with [VPN Interface] which composed by [VPN Application] which served by [VPN Server Environment] which associate with [VPN Path] which realized [VPN Service]. Also [VPN Path] associate with [VPN Client] which is part of [VPN Client Device]. [VPN Application] is part of [Virtual Private Network Server] which associate with [Extranet Firewall] which associate with [Entersprise Service Bus]. [VPN Path] is part of the [Internet] which associate with [Sensors] and [Smart Devices]. [Web Service] are assigned with [Internet Interface] which is composed by [Web Application] which realizes [Web Service] and serving by [Web Server Environment], which have access to [External Website] which have associate with [External Application Database].[ External Website],[External Web Application Database], [Web Application] and [Front-end Firewall] are part of [Web Server] which associate with [Internet].All this [Technology Infrastructure Functional Content] is influenced by [Shared Legal Framework] which influence the [Technical Agreement] which composed by [Specific Agreement] and associate with [Digital Public Service Delivery Provider] and [Digital Public Service Delivery Consumer].

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

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

EIRA Onotology 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

Highlevel Viewpoints

 

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 ABBs included in the high-level viewpoint represent the points that link the EIRA©’s views enabling traceability between their different Architecture Building Blocks. They are not necessarily mandatory but should always be considered by a user of the EIRA© when executing one of its use cases.

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.
In the high-level are represented the ABBs that link the EIRA©’s views enabling navigation between the different views. As such they should be considered as critical components of any interoperable public service. They are not necessarily mandatory but should always be considered by a user of the EIRA© when executing one of its use cases.
Narrative: This viewpoint selects Architecture Building Blocks from the five different views highlighting the focal building blocks of the EIRA©: 

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

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
[Data Extraction,Transformation and Loading Service], [Data Quality Service], [e-Archiving Service], [Data Publication Service], [Data Exchange Service] and [Data Management Service]; all the services reported are realised by their specific Application Component. Additionally, a [Privacy Service], realised by a [Privacy Component] implementing GDPR principle can be used to ensure compliance.

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

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
[Data Extraction,Transformation and Loading Service], [Data Quality Service], [e-Archiving Service], [Data Publication Service], [Data Exchange Service] and [Data Management Service]; all the services reported are realised by their specific Application Component. Additionally, a [Privacy Service], realised by a [Privacy Component] implementing GDPR principle can be used to ensure compliance.

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

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

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'.
 
(*)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 [Achieve 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);
behavioral interoperability by legal resources supporting exchanging capabilities of data, information or knowledge with internal/external peers (i.e. [Legislation on Data Information and Knowledge Exchange] enabling data/information/knowledge to 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 Agreement] 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. [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

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

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

Shared Governance Framework
Shared Legal Framework
Shared Knowledge Base
Interoperable Digital Solution
Machine to Machine Interface
Human Interface
Digital Solution Service
Digital Solution Component
Shared Platform