Reference

Architectures: the
case of EIRA
PID_00288926

Raul-Mario Abril
José Ramon Rodríguez

Recommended minimum reading time: 4 hours

© FUOC • PID_00288926 Reference Architectures: the case of EIRA

Raul-Mario Abril José Ramon Rodríguez

Raul M. Abril is an officer of the Eu- José Ramón Rodríguez is a profes-

ropean Commission since 2013 and sor of Management Information
a lecture fellow at UOC, Estudios de Systems and Business Intelligence
Informática, Multimedia y Teleco- at Universitat Oberta de Catalunya
municación. He is responsible for a (UOC). He also acts as an advisor to
portfolio of European programs, as the bodies of Operations and Tech-
chief architect, including the Euro- nology Management of the Univer-
pean Interoperability Reference Ar- sity and as a consultant for private
chitecture, EIRA, and the eGovERA and public organizations. He has
suite of solutions including Portfolio more than 30 years of IT manage-
Decision Making and the eGovERA ment experience, as executive, con-
Digital Transformation Roadmap up- sultant, lecturer, researcher and au-
scale solutions. He has more than thor. His knowledge domains are
35y of IT professional services ex- in Strategic Planning and Manage-
perience, most of them in the pri- ment of Information Systems. He
vate sector and holding several se- has been CIO of the Barcelona City
nior positions including R&D Port- Council and of the Basque Country
folio manager in a major USA IT Health Authority. He has been part-
vendor. His knowledge domains ner of IT consultancy firms, as Ernst
are Research Methods (Quantita- & Young (currently Capgemini) and
tive & Qualitative Analysis), Mar- PricewaterhouseCoopers (currently
keting Research, IT R&D (Portfolio IBM). José Ramón holds a degree in
Mgmt, Product Mgmt, and Project Humanities and a master’s degree in
Mgmt), and MIS & IT (Knowledge ITC Research. He is a member of the
Management, DSS, BI, Data Ware- PhD program in ITC of the UOC. He
housing, DBMS, Enterprise Archi- holds postgraduate studies at Har-
tecture). Raul has been a profes- vard Business School and IESE. Jose
sor in several universities and he Ramon has published books and pa-
has been actively publishing his re- pers on Strategic Management of
search. Raul holds a doctoral de- Information Systems, Business In-
gree (Henley Management College, telligence and Program and Project
Brunel University, UK), a European Management.
PhD Certification (European Doctor-
al School on Knowledge Manage-
ment, Denmark), an Engineer Supe-
rior in Informatics (UAB, Spain), and
a Master degree in Project Mgmt
(The George Washington University,
USA).

The assignment and creation of this UOC Learning Resource have been coordinated
by the lecturer: José Ramon Rodríguez

First edition: September 2022

© of this edition, Fundació Universitat Oberta de Catalunya (FUOC)
Av. Tibidabo, 39-43, 08035 Barcelona
Authorship: Raul-Mario Abril, José Ramón Rodríguez
Production: FUOC
All rights reserved

Reproduction, copying, distribution or public communication of all

or part of the contents of this work are strictly prohibited without prior authorization
from the owners of the intellectual property rights.
© FUOC • PID_00288926 Reference Architectures: the case of EIRA

Contents

Introduction............................................................................................... 5

Objectives..................................................................................................... 9

1. Background.......................................................................................... 11

2. Key concepts in a reference architecture.................................... 13

3. Ontology architecture...................................................................... 16
3.1. ArchiMate® ontology .................................................................. 16
3.2. Example of ArchiMate®. Explaining the EIRA© ontology ......... 18

4. Architecture principles.................................................................... 20
4.1. The European interoperability framework example ................... 20
4.2. The architecture style principle The SOA style ........................... 21
4.3. Principles of cloud native digital solution architecture .............. 23
4.3.1. Portability ....................................................................... 24

5. Target users and use cases of a reference architecture............ 26

6. Expected benefits of a reference architecture........................... 28

7. EIRA©..................................................................................................... 34
7.1. EIRA© high-level viewpoint ........................................................ 34
7.2. Legal view .................................................................................... 35
7.3. Organizational view .................................................................... 37
7.4. Semantic view ............................................................................. 39
7.5. Key interoperability enablers viewpoint ..................................... 41
7.6. Technical - application view ....................................................... 43
7.7. Technical - infrastructure view ................................................... 45

8. Other architecture styles................................................................. 47

8.1. Modular monolith architecture style .......................................... 47
8.2. Client-server architecture style ................................................... 49
8.3. Peer-to-peer architecture style ..................................................... 50
8.4. Microservices architecture style .................................................. 51

Bibliography............................................................................................... 57
© FUOC • PID_00288926 5 Reference Architectures: the case of EIRA

Introduction

Architecture is a set of fundamental concepts or properties of a system in its

context, embodied in its elements, relationships, and in the principles of its
implementation and evolution.

An enterprise� architecture (EA) is an analytical discipline that provides

methods to comprehensively define, organize, standardize, and document an
organization’s structure and interrelationships in terms of certain critical busi-
ness domains (physical, organizational, technical, etc.) which characterize the
entity under analysis. The goal of EA is to create an effective representation of
the business enterprise that may be used at all levels to guide, optimize, and
transform the business. EA serves to capture the relationships and interactions
between domain elements as described by their processes, functions, applica-
tions, events, data, and employed technologies, i.e., from business strategy to
detailed systems of implementation.

The missing link

EA is a formal way to represent and secure the strategic alignment between the strategic
management of any business and its information systems, thus it is a central part of the
strategic management of information systems.

See UOC, PID 00275293. "Dirección estratégica de la infraestructura y las operaciones".

Chapter 5.

We could say that EA is the missing link that connects business and technology.

See "Arquitectura: el eslabón perdido (I)" - Tecnología++ (uoc.edu) (https://blogs.uoc.edu/

informatica/arquitectura-el-eslabon-perdido-i/) and "Arquitectura: el eslabón perdi-
do (II)" - Tecnología++ (uoc.edu) (https://blogs.uoc.edu/informatica/arquitectura-el-es-
labon-perdido-ii/)

An enterprise�architecture�framework�(EAF) is a methodology for develop-

ing and using architecture to guide the transformation of a business from a
baseline state to a target state, sometimes through several transition states. A
framework provides a structured collection of processes, techniques, artefact
descriptions, reference models, and guidance for the production and use of an
enterprise-specific architecture description.

Connected disciplines

According to FEAPO, “an enterprise architecture practice collaborates with many inter-
connected disciplines, including performance engineering and management, process en-
gineering and management, IT and enterprise portfolio management, governance and
compliance, IT strategic planning, risk analysis, information management, metadata
management, and a wide variety of technical disciplines, as well as organizational disci-
plines such as organizational development, transformation, innovation, and learning.
Increasingly, many practitioners have stressed the important relationship of an enter-
prise architecture with emerging holistic design practices, such as design thinking, sys-
tems thinking, and user experience design.”
© FUOC • PID_00288926 6 Reference Architectures: the case of EIRA

FEAPO: Federation of enterprise architecture professional organiza-

tions. http://feapo.org/wp-content/uploads/2013/11/Common-Perspectives-on-Enter-
prise-Architecture-v15.pdf

The most salient enterprise architecture frameworks are those of Zachman Recommended readings
(IBM) and the Open Group architecture framework or TOGAF (open source).
Zachman (1987). http://
www.research.ibm.com /
To implement an enterprise architecture, we need a set of design principles, journal/50th/applications /
zachman.html
an ontology (a well-ordered collection of components and rules) and a nota- TOGAF. The Open
tion (a formal way to represent an ontology). An example of an ontology is Group website. https://
www.opengroup.org/togaf
EIRA (enterprise information reference architecture) of the European union.
For EIRA, see the European
Although EIRA and TOGAF are formally independent, EIRA is based on many interoperability reference
architecture (EIRA). Join-
of the principles and rules of TOGAF and they share the same notation model. up (europa.eu). https://
joinup.ec.europa.eu/collec-
tion/european-interoper-
EIRA is the reference architecture of the European institutions and it is de- ability-reference- architec-
ture-eira/about
ployed to ensure the interchange of information (interoperability) among the
For the relationship between
member states, regions and municipalities, and their main stakeholders. EIRA and TOGAF, see https://
blog.opengroup.org/2016/10/
20/european-interoperabil-
The notation model for TOGAF and EIRA is ArchiMate, an open source code ity-reference-architecture-
with-raul-abril/
tool.

“The ArchiMate® modelling language is an open and independent enterprise architec-

Bibliographic reference
ture standard that supports the description, analysis and visualization of the architecture
within and across business domains. ArchiMate is one of the open standards hosted by
the Open Group® and is fully aligned with TOGAF®.” See Archi – Open
Source ArchiMate
modelling. https://
To close the circle, a robust reference architecture needs to be grounded in www.archimatetool.com

a software design style. EIRA is compatible with a service-oriented software

architecture (or SOA).

Service oriented architecture

In software engineering, service-oriented architecture (SOA) is an architectural style that

supports service orientation. Consequently, it is also applied in the field of software de-
sign where services are provided to the other components by application components,
through a communication protocol over a network. A service is a discrete unit of func-
tionality that can be accessed remotely and acted upon and updated independently, such
as retrieving a credit card statement online. SOA is also intended to be independent of
vendors, products and technologies.

See, for instance, chapter 1: service oriented architecture (SOA). https://web.archive.org/

web/20170707052149/https:/msdn.microsoft.com/en-us/library/bb833022.aspx

This teaching material addresses the digital solution architecture domain in Interoperability
a multicentric public institution, i.e., the European Union. Thus, its focus is
The new European interoper-
on interoperability (technical, syntactic, semantic, organizational and legal ability framework, EIF (Euro-
interoperability), in order to facilitate the interchange of data and processes pean Commission, 2017) de-
fines interoperability as “the
among European institutions and member states. ability of organizations to in-
teract towards mutually bene-
ficial goals, involving the shar-
ing of information and knowl-
Therefore, to place and summarize these concepts: edge between these organi-
zations, through the business
processes they support, by
means of the exchange of data
between their ICT systems”.
© FUOC • PID_00288926 7 Reference Architectures: the case of EIRA

• TOGAF is an enterprise architecture framework. Its focus is any or-

ganization, either private or public. It may be considered a theory
or a high level methodology to align the objectives of the organiza-
tion with the projects, resources and capabilities of IT.
• EIRA is a reference architecture which is applicable to public in-
stitutions. It comprehends an ontology and a modelling language,
which are those of ArchiMate. Its focus is on interoperability. The
unit of analysis is the design of a public digital solution.

The main prerequisite for this module is to have a prior understanding of basic
software development and hardware components.

Since this is material for the courses on Strategic Management of Information

Systems, it is out of our scope to enter into details related to specificities for
coding software. The aim of this module is at the level of the awareness of the
components and their functionalities.

Structure�of�the�document

In section 1 (Background), we situate EIRA, along with its origins and main
objectives, as the reference architecture for the interoperability of the Euro-
pean Commission.

A reference architecture is an ontology, an explanatory framework for de-

scribing the different components of the information system of any organi-
zation. In section 2 (Key concepts in a reference architecture), we introduce
the main concepts of any reference architecture, its sections, nomenclature,
and acronyms.

An ontology requires a certain vocabulary, a formal specification of concepts

and signals. EIRA uses ArchiMate, which is a notation structure proposed by
TOGAF. This vocabulary and its application to the context of EIRA are pre-
sented in section 3 (Ontology architecture).

As mentioned before, the architecture is the link between the enterprise strat-
egy and the information system strategy. Therefore, it requires “principles” or
high-level guidelines for its design and implementation. These are presented
in section 4 (Architecture principles).

Any reference architecture, as the one of EIRA, is aimed to support users in the
design, assessment, communication, sharing and reusing of solutions. These
users are architects of different levels, business analysts and portfolio man-
agers. Section 5 (Target users and use cases of a reference architecture) depicts
a taxonomy of users and use cases.
© FUOC • PID_00288926 8 Reference Architectures: the case of EIRA

Section 6 presents the major strategic and technical benefits that can be ex-
pected from deploying a reference architecture.

In Section 7, we provide a structured presentation of EIRA, its building blocks

and the different focus areas or “views” (legal, organizational, semantic, and
technical).

Although we advocate a SOA style architecture, in section 8 we introduce other

architectural styles in order to present a full picture of the state of the art.

Please remember that the intention of this material is to familiarize students

with enterprise architecture and provide them with an introduction to it. We
also include some tips and thoughts extracted from our experience as man-
agers, consultants, and teachers.

We encourage the reader to delve into the main reference frameworks we re-
fer to, that are fully available in the web: TOGAF. The Open Group website
(https://www.opengroup.org/togaf) as an open-source general purpose archi-
tecture framework and EIRA. Joinup (europa.eu) (https://joinup.ec.europa.eu/
collection/european-interoperability-reference-architecture-eira/about) as the
interoperability reference architecture of the European Commission.
© FUOC • PID_00288926 9 Reference Architectures: the case of EIRA

Objectives

The main objectives in this module are:

1. To understand the key concepts in a digital solution architecture.

2. To successfully position several overlapping domains, like enterprise ar-

chitecture framework and reference architecture.

3. To be aware of the role of architecture principles.

4. To understand the main architecture styles and how to select the most
appropriate one.

5. To identify the main use cases and benefits of a reference architecture.

6. To absorb the relevance of holistic requirements, differentiating between

the requirements and the specifications of a digital solution.

7. To understand the basics of loose coupling enablers, like APIs.

8. To understand the case of EIRA (European Interoperability Reference Ar-

chitecture), which is used throughout the material as a salient example
of a reference architecture, and in this case, one primarily aimed at inter-
operability.
© FUOC • PID_00288926 11 Reference Architectures: the case of EIRA

1. Background

In Europe, the digital single market (DSM) strategy, meant to ensure the free Bibliographic reference
movement of goods, persons, services and capital, is built on three pillars:
Digital single market (DSM)
(1) improved access for consumers and businesses to digital goods and ser- strategy. http://ec.europa.eu/
vices across Europe; (2) creating the right conditions and a level playing field priorities/digital-sin-
gle-market_en
for digital networks and innovative services to flourish; (3) maximizing the
growth potential of the digital economy.

Interoperability is, without doubt, one of the means to achieve this,

improving the cooperation between organizations and removing barri-
ers for administrations, businesses, and citizens.

Given the rapidly growing amount of information exchanges, driven by

the modernization of organizations, the need for interoperability is greater
than ever. Solution developers in all domains recognize interoperability and
reusability as being essential to a solution design.

The new European interoperability framework, the EIF (European Commis- Bibliographic reference
sion, 2017) defines interoperability as follows:
European Commission
(2017). Communication
on The European Inter-
operability Framework-
“The ability of organizations to interact towards mutually beneficial
Implementation Strategy
goals, involving the sharing of information and knowledge between COM (2017). 134 Annex 2.
https://eurlex. europa.eu/
these organizations, through the business processes they support, by legal-content/en/TXT/?
means of the exchange of data between their ICT systems”. uri=CELEX:52017DC0134

Attaining interoperability calls for coordination across borders and sectors

when developing digital solutions; key players in this process experience the
following requirements:

• A� common� terminology for designing, assessing, and communicating

about digital solutions: organizations can benefit greatly from a common
terminology for communicating efficiently and unambiguously – across
language barriers and domain-specific jargon – when designing, assess-
ing, documenting and discovering solution building blocks (frameworks,
tools, services) used for delivering interoperable digital public services;

• Stable�and�standardized�interfaces for digital public services: IT archi-

tects and developers have the task of defining stable interfaces between
digital public services, according to open standards and interoperability
© FUOC • PID_00288926 12 Reference Architectures: the case of EIRA

specifications, so that partners can rely on them to build new, aggregated

digital public services and avoid vendor lock-in;

• An�overview�of�already�existing�solution�building�blocks (SBBs): deci-

sion makers, public procurers and architects benefit from finding already
existing (reusable) solution building blocks that have been developed on-
premises or by others, to unlock the potential of a shared development
effort and finding the best reusable components and services.
© FUOC • PID_00288926 13 Reference Architectures: the case of EIRA

2. Key concepts in a reference architecture

An architecture is a set of fundamental concepts or properties of a sys-

tem in its context, embodied in its elements, relationships, and in the
principles of its implementation and evolution (Lankhorst, 2013).

Building on Lankhorst, 2013; Glusko, 2013; Greefhorst & Proper, 2013, an

enterprise�architecture, EA, can be defined as “the ex-ante implementation
or post hoc implementation organizing system of an enterprise/organization
in conformance with an (architecture) ontology and a set of (architecture)
principles (Greefhorst & Proper, 2013) to meet the enterprise’s objectives in
the most efficient possible way”.

The ontology� (architecture) is related to the notation and rules for

describing the components of an EA (i.e., building blocks, processes,
etc.) and their relationships, with their meanings. A building� block
(BB) is a package of functionality defined to meet the business needs
across an organization (the Open Group, 2018).

If we consider the implementation cycle as a continuum, we will refer to the

EA architecture before the implementation is finished as an ex-ante EA archi-
tecture implementation. Likewise, we will refer to the EA architecture after the
implementation is finished as a post-hoc EA architecture implementation.

In an ex-ante EA architecture implementation, a BB is referred as an architec-

ture BB, or ABB. An ABB is an abstract component that captures the ABB’s
requirements.

A requirement is an agreed descriptive normative statement of an at-

tribute of operational, functional, or implementation characteristics or
constraint terms, which is unambiguous, testable or measurable, and
necessary for user acceptance (Dick et al., 2017).

Particularly, the� ex-ante� architecture� implementation� of� a� digital

public�solution is the To-Be organizing system of a digital public solu-
tion in conformance with an ontology (architecture) and a set of (ar-
chitecture) principles to meet the enterprise/organization strategy goals
in the most efficient possible way.
© FUOC • PID_00288926 14 Reference Architectures: the case of EIRA

In essence, the ex-ante architecture implementation of a digital public solu-

tion includes the requirements of the To-Be solution. Depending on the im-
plementation paradigm, there might be successive ex-ante architecture imple-
mentations, each one with different levels of granularity and/or scope, until
reaching the post-hoc architecture implementation (Engelsman et al., 2009;
Evans, 2003; Fouad et al., 2011; Geraldo et al., 2018).

In a post-hoc architecture implementation, a BB is referred as a solution BB or

SBB (European Commission, 2019c).

An SBB is an asset (i.e., a concrete element) that realizes one or more

ABBs and captures the SBB’s specifications, with a specification being
a partially/fully met/implemented requirement.

A SBB can be of either legal nature (e.g., a legal text), organizational nature
(e.g., a public service), semantic nature (e.g., an ontological class), or technical
nature (e.g., a software component). The post-hoc architecture implementa-
tion of a digital public service is the As-Is organizing system of an operational
digital public service in conformance with an ontology (architecture) and a
set of (architecture) principles that meet the concerned public policy’s goals.

To summarize, the�post-hoc�architecture�implementation�of�a�digi-
tal�public�solution is the As-Is organizing system of the solution once
implemented in terms of its specifications (Fouad et al., 2011).

A reference�architecture�(RA) is a blueprint for an ex-ante EA imple-

mentation, or for a digital public solution, with a focus.

The focus includes the most salient ABBs of relevance for fitting the focus. For
example: a security RA will focus on the most salient ABBs that support secu-
rity in an EA/digital solution. A business intelligence and data warehousing
RA will focus on the most salient ABBs that support business intelligence and
data warehousing in an EA.

EIRA

An interoperability RA, like EIRA© (Baheer et al., 2020; Bovalis, et al., 2014; European
Commission, 2017; 2019c), focuses on the most salient ABBs supporting interoperability
for implementing or provisioning an interoperable digital public solution. EIRA© has
ArchiMate © (the Open Group, 2017) as its ontology architecture and the European in-
teroperability framework (European Commission, 2017) and the service oriented archi-
tecture (the Open Group, 2014) as its architecture principles.

In a RA we should not expect to find a description of how to design an ex-

ante and/or post-hoc architecture, nor on how to move from the former to the
latter. This is precisely the domain of an enterprise architecture framework.
© FUOC • PID_00288926 15 Reference Architectures: the case of EIRA

Zachman and TOGAF

An EA� framework, EAF, transposing the framework definition in
(Glushko, 2013), is an explanatory theory that provides a vocabulary Zachman’s work (Zachman,
1982) is the seminal paper for
for a normative implementation process of an EA. Enterprise architec- setting the pillars of EA, later
materialized and referenced in
ture frameworks identify the EA resources that should be taken into his paper in (Zachman, 1987).
consideration. Among them are information, technology, governance This view has been the domi-
nant paradigm for almost 30
and requirements (e.g., the Open Group, 2018). years. Key concepts in this par-
adigm were the concepts of
a layered architecture, top-
down implementation, align-
ment, end-to-end implemen-
We could say that the unit of analysis of an EAF is an organization, and the tation of the whole enterprise,
aim is to align the ICT resources to the strategy/objectives of such organiza- and model driven implemen-
tation/isomorphism between
tion. This scope, in the past, has been characterized by a focus on processes layers.
(i.e., business process modelling) and on the status-quo. This inevitably led However, modern paradigms
like TOGAF (the Open Group,
to efforts in effectiveness in detriment of innovation/efficacy. Arguably, it has 2018) have moved from lay-
ers to views, from top-down
also been the main factor in many long projects with a low success ratio, and to cycles and agile orienta-
tions, from end-to-end to ref-
a questionable reputation of the value provided. erence [focused] architectures
like EIRA and from model dri-
ven to ontologies and archi-
tecture-driven engineering re-
quirements.
© FUOC • PID_00288926 16 Reference Architectures: the case of EIRA

3. Ontology architecture

3.1. ArchiMate® ontology

The ArchiMate® is an ontology specification proposed by the Open

Group©.

First, this section provides an overview of the ArchiMate® ontology concepts

that are used in this module.
© FUOC • PID_00288926 17 Reference Architectures: the case of EIRA

Table 1. ArchiMate© ontology concepts used in this module

The following ArchiMate® 3.0.1 relationships are used in this module:

© FUOC • PID_00288926 18 Reference Architectures: the case of EIRA

Table 2. ArchiMate® 3.0.1 relationships used in this module

3.2. Example of ArchiMate®. Explaining the EIRA© ontology

This section has a dual role: to provide an example of ArchiMate® for the
student and to introduce the European interoperability reference architecture,
EIRA©, to the student.

The following figure illustrates the ontology (i.e., key concepts and relation-
ships) of the EIRA© using ArchiMate©.

Figure 1. EIRA© ontology

EIRA ontology

The following narrative explains figure 1:

• A digital public service has its high-level requirements defined by the high-level
analysis of a target digital public service, while its detail-level requirements are de-
fined by the detail-level design of a digital public service/documentation of an exist-
ing digital public service.
© FUOC • PID_00288926 19 Reference Architectures: the case of EIRA

• 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 specialization of an architec-

ture building block

• A key interoperability enabler is a specialization of an EIRA© architecture building

block, which is necessary for enabling the efficient and effective delivery of public
services across administrations;

• An EIRA© architecture building block has one or more architecture requirements.

An interoperability requirement is a specialization of an architecture requirement
and can be formulated for all the EIF interoperability levels: legal interoperability
requirement, organizational interoperability requirement, semantic interoperability
requirement, and technical interoperability requirement.

• Interoperability requirements are grouped in interoperability aspects. An interoper-

ability aspect is an externally observable characteristic or a set of characteristics to be
provided/supported by the solution that fulfills partially or internally a stakeholder
interoperability need.

• An interoperability specification is a document containing agreed normative state-

ments for solution building blocks used in an information exchange context. It can
refer to existing standards or specifications. An interoperability specification realizes
an interoperability requirement.

• An EIRA© solution building block is a specialization of an EIRA© architecture build-

ing block and a solution building block is a specialization of an architecture building
block

• A solution consists of EIRA© solution building blocks and solution building blocks
© FUOC • PID_00288926 20 Reference Architectures: the case of EIRA

4. Architecture principles

4.1. The European interoperability framework example

An architecture�principle is, in essence, a requirement of the highest

possible granularity. They are considered at the strategic level, and they
should have a low volatility.

The European interoperability framework, EIF, outlines 12 underlying princi-

ples for European public services. These general principles of good adminis-
tration are relevant to the process of establishing European public services.
They describe the context in which European public services are decided and
implemented. They complement one another, regardless of their different na-
tures, e.g., legal or technical.

The twelve underlying principles of the EIF are grouped into four categories:

• Principles setting the context for EU actions on interoperability (subsidiarity and

proportionality).
• Core interoperability principles (openness, transparency, reusability, technolog-
ical neutrality and data portability).
• Principles related to generic user needs and expectations (user-centricity, inclu-
sion and accessibility, security and privacy, multilingualism).
• Foundation principles for cooperation among organizations (administrative sim-
plification, preservation of information, assessment of effectiveness and efficien-
cy).

Figure 2. EIF underlying principles

© FUOC • PID_00288926 21 Reference Architectures: the case of EIRA

4.2. The architecture style principle The SOA style

Any RA should have one architecture principle stating the engineering orien-
tation to be used for designing and implementing digital solutions.

Examples of architecture styles are monolith, client-server, SOA, microser-

vices, cloud, etc.

EIRA© adheres to the service oriented architecture, SOA, architecture style.

SOA is a network distributed architecture where the functionalities of a digital
solution are realized by an integration mechanism, called orchestration, of a
set of services.

A service is a self-contained functionality that is exposed by a software

component (so it can be found and invoked) and it is realized by a
runtime of this software component. Therefore, a software component
might expose several services and the environment of the implemen-
tations is transparent for the consumer of a service. Consequently, a
digital solution is the result of the integration of loosely coupled com-
ponents (see figure 3).

The services are operationally independent�and�reusable. Some key design

recommendations for services are:

• Organize each service around a cohesive and manageable unit of func-

tionality
• Separate the different aspects of a system that change at different rates or
for different purposes
• Map all external dependencies to understand the impact of change

The "service-oriented architecture manifesto" puts forward six core values:

• Business value is given more importance than technical strategy

• Strategic goals are given more importance than project-specific benefits
• Intrinsic interoperability is given more importance than custom integra-
tion
• Shared services are given more importance than specific-purpose imple-
mentations
• Flexibility is given more importance than optimization
• Evolutionary refinement is given more importance than the pursuit of
initial perfection
© FUOC • PID_00288926 22 Reference Architectures: the case of EIRA

A service oriented architecture enables an agile development. The tech-

nologies used are mainly the usual ones associated to network resources,
like representation (e.g., XML) and protocols (e.g., HTTP).

Compared to microservices, the services in the SOA style have a coarser gran- See also
ularity and a larger functional scope. The client code calling the services is
Other architectural styles are
simpler than its microservices counterpart, as the SOA style relies on a more presented in section 11.
complex infrastructure (ESB, JMS) offering higher guarantees. Scalability can
be achieved at the level of the services but is more limited than with microser-
vices.

The overall solution is made of only a small number of services, but a paral-
lelization of the development by independent development teams can still be
achieved, providing good agility.

Figure 3. Technical - application view of the EIRA©

In EIRA©, a digital solution (e.g., an interoperable European solution service)

can be accessed through machine to machine interfaces or human interfaces.
A digital solution component (e.g., a software code like an interoperable Euro-
pean solution component) realizes a digital service (e.g., an interoperable Eu-
ropean solution service). Data can be exchanged, cross-border and cross-sec-
tor, with the support of application mediation enablers containing the logic
for data transfer and validation. An interoperable European solution compo-
nent can execute complex business processes through application workflow
enablers. Access control is managed through the services offered by applica-
tion security enablers.
© FUOC • PID_00288926 23 Reference Architectures: the case of EIRA

Bibliographic reference
An orchestration�service shares the functionality of defining the se-
quence and conditions in which one service invokes other services to Based on W3C. https://
www.w3.org/
realize some useful function.

4.3. Principles of cloud native digital solution architecture

Cloud-native digital solution architecture has specific architecture principles

that enable digital solutions to fully utilize the agility, scalability, resiliency,
elasticity, on-demand and economies of scale benefits provided by cloud com-
puting.

Bibliographic reference
According to the LIFESPAR paradigm, cloud-native applications are
architected to be latency-aware, instrumented, failure-aware, event- LIFESPAR. https://
press20.blogspot.com
driven, secure, parallelizable, automated and resource-consump- /2019/07/lifespar-cloud-ar-
chitecture -principles.html
tion-aware.

These LIFESPAR principles are further developed below.

LIFESPAR

• Latency-aware: digital solutions remain operational despite variable and ex-

tended latency for services accessed across public networks, and between cloud
provider data centres.
• Instrumented: sufficient telemetry data is available from digital solutions to de-
termine health and other operational and performance characteristics. For a long
time, the approach to monitoring the health and performance of infrastructure
and applications has been based on monitoring tools and notifications with re-
sponse actions carried out in case of problems. With the speed and complexi-
ty associated with modern cloud and cloud native solutions, this is no longer
enough to consistently meet service-level objectives. Observability is a measure
of how well the internal states of a system can be deduced from knowledge of
the external outputs, partly based on control technology. Software observability
requires the presence of sufficiently rich instrumentation to enable developers
and operators to ask questions about how the software works and query internal
states in a process that is more like debugging than operations.
• Failure-aware: digital solutions are resilient to occasional or extended failures of
underlying infrastructure components or dependent services.
• Event-driven: software components are structured as a set of handlers, waiting
for events and responding in a choreographed way, rather than with sequential,
determined and synchronous orchestrations.
• Secure: the digital solution protects the information and systems, guarding
against data loss or SLA violations caused by malicious or accidental events.
• Parallelizable: data processing can be scaled out to multiple simultaneous or
redundant instances of system components, as required by a SLA.
• Automated: applications are packaged, deployed and executed without manual
steps or complex dependencies.
• Resource-consumption-aware: digital solutions can be adapted to different al-
gorithms, data structures and system architectures in response to resource cost
changes.

An alternative/complementary paradigm is the so called 12-factor paradigm

and the amended version, beyond the twelve-factor, presented below:
© FUOC • PID_00288926 24 Reference Architectures: the case of EIRA

Beyond the twelve-factor

1) One codebase, one application

2) API first

3) Dependency management

4) Design, build, release, and run

5) Configuration, credentials, and code

6) Logs

7) Disposability

8) Backing services

9) Environment parity

10) Administrative processes

11) Port binding

12) Stateless processes

13) Concurrency

14) Telemetry

15) Authentication and authorization

4.3.1. Portability

Surprisingly, the portability�principle is not covered in the two paradigms

above. The portability principle refers to the ability to move applications and
data from one cloud computing environment to another with minimal dis-
ruption/costs.

This principle is assessed by solution architects on a case-by-case basis, and

addresses whether to prioritize portability during the design phase of an ap-
plication, taking into account the trade-off of the benefits linked to the use of
the cloud provider’s built-in functions (such as tool integration).

When portability is a priority, architectural disciplines that promote portabili-

ty allow applications to move between providers without substantial re-archi-
tecting or refactoring. Examples of such disciplines include designing cloud
applications to be contextually independent. As a final state, contextual in-
dependence is difficult to achieve. The three characteristics of contextual in-
dependence are:

• Few� dependencies: contextually independent systems can be deployed

almost anywhere because they are relatively independent/self-contained.
• Well-defined�interfaces: the means of communicating with contextually
independent systems are very well-defined.
© FUOC • PID_00288926 25 Reference Architectures: the case of EIRA

• Easily�fulfilled�dependencies: it is also easy to fulfill the few dependen-

cies that the contextually independent systems have.
© FUOC • PID_00288926 26 Reference Architectures: the case of EIRA

5. Target users and use cases of a reference

architecture

In general, a RA has the objective of supporting users in the following scenar-

ios:

• Designing: accelerating the design of eGovernment solutions that support

the delivery of interoperable digital public services (across borders and
sectors).
• Assessing: providing a reference model for comparing existing architec-
tures in different policy domains and thematic areas, to identify focal
points for convergence and reuse.
• Communicating�and�sharing: helping to document the most salient in-
teroperability elements of complex solutions and facilitating the sharing
of (re)usable solutions.
• Discovering�and�reusing: facilitating the discovery and reuse of interop-
erability solutions.

More specifically, a reference architecture targets the following users:

• Architects,�enterprise�architects,�as�well�as�solution�architects, that are

responsible for the design of solution architectures.
• Business� analysts responsible for assessing and studying the impact of
changes in the (external) environment on IT systems.
• Portfolio� managers responsible for maintaining the catalogue of assets
related to the design and implementation of solutions and for making
investment decisions about these assets.

Figure 4. Target users and their RA use cases

© FUOC • PID_00288926 27 Reference Architectures: the case of EIRA

Figure 4 above depicts the target users and use cases. Each use case has the
following motivation and outcome.

Table 3. Use cases

Design�and�document�solution�architecture�use�case • Motivation: the user needs to design the solution architecture

of a new solution that must support interoperability with Mem-
ber States and/or EU institutions and document existing solu-
tion building blocks.
• Outcome: a solution architecture is created, as a collection of
interoperable SBBs (optionally) mapped to a solution architec-
ture template.

Compare�solution�architectures�use�case • Motivation: the user already has a solution architecture in place

(SBBs of the architecture are already operational in his/her or-
ganization) and needs to assess and increase the interoperabil-
ity maturity level.
• Outcome: the interoperability maturity of the solution architec-
ture is assessed (per SBB). The solution architecture is updated
by including new solutions discovered by accessing the cartog-
raphy of the legacy solutions or by upgrading the existing solu-
tions to be compliant with the interoperability requirements.

Create�portfolio�of�solutions�use�case • Motivation: the user wants to create a portfolio of the applica-

tions/solutions of his/her organization and needs a structured
model that can facilitate the sharing and reuse of these solutions
with other European partners.
• Outcome:
– A new portfolio of solutions is created and mapped to the
EIRA© ABBs.
– “Interoperable” solutions are identified, and (optionally)
shared with other partners.

Manage�portfolio�of�solutions�use�case • Motivation: due to new circumstances (e.g., budget con-

straints, new interoperability needs, etc.), the existing IT portfo-
lio of the user’s organization needs to be managed by adding,
updating, or phasing out solutions.
• Outcome:
– The existing IT portfolio is mapped to the EIRA©.
– New re-usable interoperability solutions are added to the
portfolio.
– The solutions in the existing portfolio to be updated,
merged or phased out are identified.

Rationalize�portfolio�of�solutions�use�case • Motivation: Multiple SBBs in the portfolio of the organization

are mapped to the same ABB of the EIRA©. The user wants to
reduce the number of solutions in the portfolio while increasing
the average interoperability maturity level of the portfolio.
• Outcome:
– The IT portfolio in the organization is rationalized; “super-
fluous” and “to be merged” solutions are identified in the
portfolio.
– The most interoperable solutions are kept in the IT portfolio.

Structure�impact�assessment�on�ICT�use�case • Motivation: the user wants to describe the architecture and in-
teroperability implications of a new or existing policy or themat-
ic domain.
• Outcome: the architecture and interoperability implications of
a policy or thematic domain are structured according to the
EIRA©. The ABBs and relationships that are impacted whenever
a change occurs are identified.
© FUOC • PID_00288926 28 Reference Architectures: the case of EIRA

6. Expected benefits of a reference architecture

A common use of the EIRA© when developing, assessing, and commu-

nicating about eGovernment solutions will result in network�effects,
enhancing the coordination between organizations.

The EIRA© contributes to an increased awareness and usage of EIF principles

and recommendations.

Note that interoperability implies reusability, but is not limited to it (according

to the EIF, reusability is just one of the aspects of interoperability). Therefore,
the scope of EIRA© is much broader than just facilitating reuse.

Interoperability applies at different organizational and geographical levels:

where inside�an�organization, the main benefit may lie in the composition of
generic building blocks which are interoperable with others, interoperability
across�organizations is indispensable for the efficient execution of business
processes.

For customer- (or citizen-) facing components, user-centric�interoperability

aspects enable the transition from traditional channels to digital service de-
livery. When it comes to cross-border�interoperability, organizational and
legal aspects are of special importance and become crucial to maximize the
potential of the digital single market.

A common use of the EIRA© will provide the following high-level benefits:

1)�Providing�a�controlled�vocabulary

Having a controlled vocabulary, the EIRA© provides a common language of

architecture building blocks for the design and comparison of the solution
architectures of eGovernment solutions. Architects are thus enabled to easily
understand the functionality of other using solutions that are based on the
EIRA© as well as the interfaces to other solutions where those are documented
in the same language.

2)�Decoupling�functionalities�in�architectural�building�blocks

Each architecture building block in the EIRA© provides a decoupled function-

ality, meaning that the ABBs are autonomous and unaware of the other ar-
chitecture building blocks within the same context. The autonomous nature
of the ABBs is an absolute necessity for reusability, provided that the inter-
© FUOC • PID_00288926 29 Reference Architectures: the case of EIRA

faces are clearly defined. The decoupling also helps in rationalization exercises
where one solution building block can be exchanged with another solution
building block, provided that they both “realize” the same architecture build-
ing block.

3)�Facilitating�the�identification�of�interoperability�specifications

The EIRA© allows stakeholders to effectively communicate with their peers

when systems across organizational and national borders have to interoperate.
The EIRA© facilitates the identification of interoperability specifications and
promotes the use of common interoperability specifications based on open
standards referenced in the European�interoperability�cartography.

Architects and system owners can then rely on these interoperability specifi-
cations to ensure stable interfaces between their systems/services and others
inside and outside their own organizations, and interfaces towards users that
take into account non-technical interoperability aspects like usability, inclu-
siveness and multilingualism.

Public�procurers benefit from an easy way to discover relevant specifications

for specific types of solutions, and avoid vendor lock-in.

4)� Providing� the� key� interoperability� enabler� architectural� building

blocks

(1)
Decision (EU) 2015/2240 of the European Parliament1 clearly mentions that Decision (EU) 2015/2240 of The
European Parliament and of The
interoperable solutions and standards in ICT are key enablers for the partner- Council of 25 November 2015 es-
ing of industries at Union level. tablishing a programme on inter-
operability solutions and common
frameworks for European public
administrations, businesses and
citizens (ISA2 programme) as a
‘Key�interoperability�enablers’ means interoperability solutions that means for modernizing the public
are necessary to enable the efficient and effective delivery of public ser- sector.

vices across administrations.

The EIRA© identifies key interoperability enablers in the following areas.

Key sharing and reuse enablers ABBS

• Legislation�catalogue: an inventory of legal documents. This ABB is a key inter-

operability enabler for sharing/provisioning and reusing/consuming legal docu-
ments.
• Public� service� catalogue: a collection of descriptions of active public services
that are provided by organizations at any administrative level (e.g., local, region-
al, national or pan-European). All public service descriptions published in a cata-
logue of public services conform to a common data model for representing public
services. This ABB is a key interoperability enabler for sharing/provisioning and
reusing/consuming of front-office public services.
• Data�set�catalogue: a curated collection of datasets. This ABB is a key interoper-
ability enabler for sharing/provisioning and reusing/consuming data.
© FUOC • PID_00288926 30 Reference Architectures: the case of EIRA

• Service�registry�component: it implements the functionality of registering the

system service within a catalogue to be discovered by other services. This ABB is
a key interoperability enabler for sharing/provisioning and reusing/consuming
back-office services.
• Key�information�exchange�enablers�architecture�building�blocks: these ABBs
are key interoperability enablers for assessing compatibility. The EIRA© identifies
the following key information exchange enablers ABBs
• Public�policy�implementation�approach: the specific rules and processes final-
ized at implementing a policy through organizations, persons, objects or events.
A public policy implementation approach is influenced by a regulatory state and
a delegation of powers, which determine the role of the organizations, persons,
objects or events involved in the implementation of the policy. This ABB is a key
interoperability enabler for assessing compatibility across legal/juridical certain-
ties
• Service�delivery�model: the way of delivering to public service consumers, or
otherwise interacting with them, for the purpose of supplying specific public ser-
vices. This involves a number of management practices to ensure that the pub-
lic services are provided as agreed between the public service provider and the
consumer. This ABB is a key interoperability enabler for assessing compatibility
between business interfaces
• Representation: the description of the perceptible configuration of business in-
formation or a legal act. Representations can be classified in various ways; for
example, in terms of medium (e.g., electronic or paper documents, audio, etc.) or
format (HTML, ASCII, PDF, RTF, etc.). This ABB is a key interoperability enabler
for assessing compatibility between interpretations of business information.
• Machine�to�machine�interface: a boundary set of means enabling the exchange
of data between a service and other services. This ABB is a key interoperability
enabler for assessing compatibility between technical interfaces.
• Human�interface: a boundary set of means enabling the exchange of data be-
tween an individual and a service. This ABB is a key interoperability enabler for
assessing compatibility between technical interfaces.
• Key�interoperability�agreement�enablers�ABBs: these ABBs are key interoper-
ability enablers for assessing agreements. The EIRA© identifies the following key
interoperability agreement enablers ABBs:
• Legal�interoperability�agreement: concrete and binding documents which set
out the precise legal obligations of two legal authorities cooperating across an
‘interface’ to achieve interoperability. This ABB is a key interoperability enabler
for assessing the legal terms/conditions for ‘sharing & reusing’ and exchanging
information.
• Organizational�interoperability�agreement: concrete and binding documents
which set out the precise obligations of two parties cooperating across an ‘in-
terface’ to achieve interoperability. An interoperability agreement is the means
through which organizations (public administrations, or businesses) formalize
the cooperation with one another. These agreements aim at the development
of interoperability solutions, which meets the functional and technical require-
ments and needs of one another (European interoperability framework). This ABB
is a key interoperability enabler for assessing the organizational terms and con-
ditions for sharing and reusing and exchanging information.
• Semantic�interoperability�agreement: the semantic interoperability agreement
is the consensus among a group of co-operation partners on the model and da-
ta entities that support common services. Apart from the typology of the data
entities, the consensus also covers the characteristics of the data entities as ex-
pressed in metadata and the use of common controlled vocabularies. This ABB
is a key interoperability enabler for assessing the semantic terms and conditions
for sharing and reusing and exchanging information.
• Technical�interoperability�agreement: the technical interoperability agreement
is the means through which technical authorities order specific technical interop-
erability specifications, ensuring organizations (operating under different tech-
nical frameworks, policies and strategies) are able to work together. This ABB is a
key interoperability enabler for assessing the technical terms and conditions for
sharing & reusing and exchanging information.

5)�Accelerating�the�development�cycle
© FUOC • PID_00288926 31 Reference Architectures: the case of EIRA

The development cycle is accelerated by the increased application of the prin-

ciples of service-oriented architecture (SOA). Architects are guided naturally
towards service-oriented architecture when using EIRA©. This then enables
the consumption of the system’s services by other systems and vice versa with-
out additional investments.

The development time of new services is often much higher than the integra-
tion costs of existing services. In addition, reuse at service level helps avoiding
costs typically associated with the reuse of applications or components and it
accelerates the development cycle of new solutions.

6)�Enabling�cartographies

A cartography is a mapping between the digital solutions in production and

a taxonomy of functionalities. A simple form to represent a cartography is an
Excel where the rows are the digital solutions in production and the columns
are the ABBs of EIRA©. In each cell we report attributes, such as included vs.
not included.

Figure 5. Example of a cartography

The EIRA© and CarTool© help enabling cartographies by providing a way of

assembling modelled solutions in a cartography where reusability and inter-
operability attributes of solution building blocks can be queried by using com-
plex queries.

By using queries, an architect can query the existing solutions in the cartog-
raphy for discovery and reusability of existing solutions.
© FUOC • PID_00288926 32 Reference Architectures: the case of EIRA

The cartography can help portfolio managers by providing a query function-

ality that results in different solutions, providing a similar functionality. This
list can be used for decisions on rationalization of solutions.

Using the query functionality of the CarTool©, the cartography can be used for
impact assessment and, as such, supports public policy formulation decisions.

7)�Promoting�discovery�and�reusability�of�existing�solutions

The EIRA© and the embedded cartography provide a consistent way to docu-
ment and classify reusable solution building blocks, allowing reusable and in-
teroperable solution building blocks to be found and understood more easily.

By creating a cartography, the different solutions in this cartography become

searchable and identifiable for reuse. The EIRA© and CarTool© can be used
to promote discovery and reusability. Architects and public procurers are thus
supported in making decisions for which functionalities there are already ex-
isting solution building blocks available and which need to be developed or
procured.

Reuse of existing solution building blocks is a key point in achieving the cost
savings. To assess when it is reused is really the most cost-efficient option.
Therefore, a detailed analysis of the reusability of the solution building block
in question is required.

8)�Supporting�portfolio�management�decision�making

The EIRA© supports portfolio management decisions by realizing cost-savings

related to the rationalization of the portfolio of solutions and solution build-
ing blocks.

Portfolio managers are, through the common language, provided with a clas-
sification schema that allows discovery of systems with identical or overlap-
ping functionalities inside the organization which might be phased out and
identification of solution building blocks that could be made more generic

Architects can learn how making solution building blocks more generic can
be achieved: firstly, EIRA© identifies the ones with high interoperability rel-
evance, that should be implemented as modular services, and by respecting
the corresponding interoperability specifications, the solution building blocks
realizing them are enabled to interface with other SBBs and thus become
reusable in different contexts. This in turn ensures that the central functional-
ities need to be developed and maintained only once and competing solutions
providing the same functionalities can be replaced by more generic ones.

9)�Supporting�public�policy�formulation
© FUOC • PID_00288926 33 Reference Architectures: the case of EIRA

The EIRA© supports public policy formulation in the form of impact assess- Recommended link
ments where possible impacts to available solutions are examined during the
About impact assessments:
public policy preparation phase. This is done before the Commission final- https://ec.europa.eu/info/
izes a proposal for a new law. Impact assessment can be performed by using law-making-process/plan-
ning-and-proposing-law/im-
the CarTool©, examining solutions that are linked to specific public policies. pact-assessments_en
The assessments are carried out on initiatives expected to have significant eco-
nomic, social, or environmental impacts. These can be:

• Legislative proposals
• Non-legislative proposals, such as financial programmes and recommen-
dations for the negotiations of international agreements
• Implementing and delegating acts
© FUOC • PID_00288926 34 Reference Architectures: the case of EIRA

7. EIRA©

7.1. EIRA© high-level viewpoint

Recommended link
The EIRA© high-level viewpoint, depicted in figure� 6, models an in-
troductory overview of the focal architecture building blocks (ABB) of About the interoperability
maturity model:
each view. It aligns the EIRA© with the service delivery model described https://ec.europa.eu/
within the interoperability maturity model (IMM), and the new Euro- isa2/actions/assess-
ing-progress-being-made-to-
pean interoperability framework (EIF) conceptual model for public ser- wards-interoperability_en
vices, depicted in figure 2.

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.

Figure 6. EIRA© high-level viewpoint

© FUOC • PID_00288926 35 Reference Architectures: the case of EIRA

With its views, the EIRA© provides a set of architecture building blocks, im-
portant for facilitating interoperability. Each view, one for each interoperabil-
ity level, is represented with the focal architecture building blocks needed for
delivering an interoperable solution. These focal architecture building blocks
are indicated with a highlighted colour.

The ABBs that link the EIRA©’s views enabling navigation between the differ-
ent views are represented in the high-level. They should be considered as crit-
ical components of any interoperable public service. They are not necessarily
compulsory, 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 high-
lighting the focal building blocks of the EIRA:

• The selected architecture building block of the legal�view shows the public policy
which is the mainspring of the solution.
• The selected architecture building blocks of the organizational�view shows a pub-
lic policy that is implemented by a public service which can be an aggregation of
other public services serving [public service consumers] and is provided by a [public
service provider]. The [public service] is realized by a [business capability] which can
be an aggregation of other [business capabilities]. A [business capability] describes
key functions supporting the [public service]. An [exchange of business information]
accesses [business information].
• The selected architecture building blocks of the semantic�view shows that the [ex-
change of business information] is realized by a [representation] of [data] which de-
scribes interactions between public administrations, businesses, and citizens.
• The selected architecture building blocks of the technical�views shows that an [in-
teroperable European solution] supports one or more [public services] and lets con-
sumers access it via a [machine to machine interface] and/or a [human interface].
An [interoperable European solution] exposes one or more [application services] via
its [machine to machine interfaces] and/or [human interfaces]. It makes use of [or-
chestration services] and [choreography services]. The [interoperable European solu-
tion] uses a [digital service infrastructure] which uses a [hosting and networking in-
frastructure]. It can also use other [interoperable European solutions].
• The selected architecture building blocks of the EIF underlying�principle�view show
that [interoperability specifications] realize [interoperability principles], the general
intended properties used to achieve interoperability. The interoperability specifica-
tions can be used to define the interoperability aspects for any of the architecture
building blocks.

7.2. Legal view

The legal view models the most salient public policy development en-
ablers and implementation instruments that shall be considered in or-
der to support legal interoperability.
© FUOC • PID_00288926 36 Reference Architectures: the case of EIRA

Figure 7. Legal view of the EIRA©

Narrative:

A [public policy] is the outcome of a specific [public policy cycle] that aims at address-
ing the needs of a group of stakeholders and of the [public policy implementation ap-
proaches] that supports its implementation. The policy is formulated and implemented
with the help of a [legal act] in the form of either [binding instruments] or [non-binding
instruments. A [legislation catalogue] aggregates the [legal act].

These different architecture building blocks define the [legal interoperability

content] and each of these architecture building blocks can have any [interop-
erability specification] associated, of which the [legal interoperability specifi-
cation] is a specialization. Moreover, the [legal interoperability specification]
defines the interoperability aspects for the [legislation catalogue]. The [legal
authority] signs a [legal interoperability agreement], which mandates a [legal
interoperability specification].
© FUOC • PID_00288926 37 Reference Architectures: the case of EIRA

• A public�policy is a designated name for grouping legal acts with a com- Recommended linkS
mon scope to be implemented by a public authority. It is based on certain
About the EU strategy:
values and objectives and is implemented by using a variety of resources. https://ec.europa.eu/info/
It applies in the territory within which the public authority has delegated strategy_en
The policies: overview of EU
powers by the legislative authority. activities in all areas, from
• A legal� interoperability� specification is a specialization of interoper- agriculture to transport can
be found on the EU strategy
ability specification containing agreed normative statements for solution page (based on EuroVoc).
building blocks legally used in an information exchange context. It refers
to EU legal acts adopted by the European institutions (Article 288 TFEU).

7.3. Organizational view

The organizational view models the most salient architecture building

blocks that shall be considered in order to support organizational inter-
operability among the providers and the users of a public service.

Figure 8. Organizational view of the EIRA©

Narrative:

The [organizations] in the role of [public service providers] supply [public services] to
[citizens] and [businesses] and/or [public administrations] which have the role of a [pub-
lic service consumer]. The [public service] is delivered according to its [service delivery
model]. The [public services] are documented in [public service catalogues] that can be
used among others for the service portfolio management. The [public service providers]
can delegate the delivery of [public services] to [public service delivery agents] who will
© FUOC • PID_00288926 38 Reference Architectures: the case of EIRA

act on behalf of the [public service providers]. The [public service providers] can sign an
[interoperability agreement] to agree on how to deliver a [public service] to its users.

The delivery of these public services is realized through [business capabilities] using an
[exchange of business information] that exchanges [business information]. The [business
information] is instance oriented and is subject to the [business rules] originating from
[organizational interoperability enablers], such as [organizational structures], [organiza-
tional procedures], [organizational policies] or the [organizational skills] of the [organi-
zations] involved. The [interoperability organizational authority] is responsible for the
[interoperability governance] which influences the [interoperability strategy].

The [interoperability strategy] implements the [interoperability framework]. The [inter-

operability skills] are a specific form of [organizational skills] that allows the organization
to excel in interoperability. A [security framework] is a specific form of [security policy]
which is an [organizational policy] focused on security related aspects.

These different architecture building blocks define the [organizational con-

tent] and each of these architecture building blocks can have any [interoper-
ability specification] associated, of which the [organizational interoperability
specification] is a specialization.

• A European�public�service comprises any public sector service exposed

to a cross-border dimension and supplied by organizations, either to one
another or to businesses and citizens in the Union. A public service com-
prises any public sector service exposed to a cross-border dimension and
supplied by organizations, either to one another or to businesses and cit-
izens in the Union. A public service is a mandatory or discretionary set
of acts performed, or able to be performed, by or on behalf of a public
organization. Services may be for the benefit of an individual, a business,
or another public authority, or groups of any of these. The capacity to act
exists whether it is used or not, and the term ‘benefit’ may apply in the
sense of enabling the fulfilment of an obligation. As defined in the revised
version of the European interoperability framework, a European public
service comprises any service provided by organizations, or by other or-
ganizations on their behalf, to businesses, citizens, public service and/or
activities that public authorities identify as being of particular importance
to citizens (A2C), businesses (A2B) and public administrations (A2A) and
that would not be supplied (or would be supplied under different condi-
tions) if there was no public intervention (based on ISA² core vocabularies
and the interoperability maturity model (IMM)).

• A public service consumer is a public administration, business or citizen

consuming public services.

• A public service provider is any natural or legal person or public entity or

group of such persons and/or bodies which offers the execution of public
services.

• A business�capability is a particular ability or capacity that an organiza-

tion may possess or exchange to achieve a specific purpose or outcome.
Defining a business capability involves identifying and describing what
needs to be done by the business in support of its overall mission. Business
© FUOC • PID_00288926 39 Reference Architectures: the case of EIRA

capabilities provide an abstraction of the business reality in a way that

helps to simplify conversations between interested stakeholders (based on
the TOGAF© definition of business capability).

• An exchange�of�business�information is a communication of business

information by a business capability. This ABB is a key interoperability
enabler for assessing the compatibility of interaction in exchanged infor-
mation.

• Business�information is the representation of data that, in the context of

a public service, enables interpretation (i.e., situational meaning). Some
examples are a medical prescription and a driving licence.

• An interoperability�specification is a document containing agreed nor- Bibliographic reference

mative statements for solution building blocks used in an information ex-
Source: How does the EIRA©
change context. It can refer to existing standards or specifications. support interoperability?.
https://joinup.ec.europa.eu/
collection /european-inter-
• An organizational�interoperability�specification is concerned with how operability-reference -archi-
tecture-eira/document/how-
organizations cooperate to achieve their mutually agreed goals. In prac-
does -eira-support-interoper-
tice, organizational interoperability implies integrating business processes ability
and the related data exchange. Organizational interoperability also aims
to meet the requirements of the user community by making services avail-
able, easily identifiable, accessible, and user focused.

7.4. Semantic view

The semantic view models the most salient architecture building blocks
that should be considered in order to support semantic interoperabili-
ty of information exchanges between administrations, businesses and
citizens.
© FUOC • PID_00288926 40 Reference Architectures: the case of EIRA

Figure 9. Semantic view of the EIRA©

Narrative:

[Business information] is realized by a [representation] of [data]. [Data] can be grouped

in [data sets], which can be documented in [data set catalogues]. A [legal act] also has
a [representation]. [Data] is subject to [data policies], which also influence their [repre-
sentation]. A [data policy] defines a guiding framework for data usage. Specific cases of
[data policies] are the [master data policy], the [open data policy] and the [descriptive
metadata policy]. There is also a [reference data policy] and a [base registry data policy]

These different architecture building blocks define the [semantic content] and
each of these architecture building blocks can have any [interoperability spec-
ification] associated, of which the [semantic interoperability specification] is
a specialization. The following [semantic interoperability specifications] are
divided in [data models], of which [core data models] and [data entities] are
specializations, and which implement the semantic interoperability associat-
ed with the data, and [data syntaxes], which implement the syntactic interop-
erability. An [interoperability specification] is mandated by a [semantic inter-
operability agreement]. A [semantic interoperability agreement] is negotiated
and reached by a [public service consumer] and a [public service provider].

• Representation�is�the�perceptible�form�of�data. Representations can be

classified in various ways; for example, in terms of medium (e.g., electronic
or paper documents, audio, etc.) or format (HTML, ASCII, PDF, RTF, etc.).
© FUOC • PID_00288926 41 Reference Architectures: the case of EIRA

• Data�policy is a set of broad, high level principles which form the guiding Bibliographic reference
framework in which data management can operate.
Based on OECD. https://
www.oecd.org
• Data are symbols obtained through an encoding process of a phenomena.

Bibliographic reference
• An interoperability�specification is a document containing agreed nor-
mative statements for solution building blocks used in an information ex- Source: How does the EIRA©
change context. It can refer to existing standards or specifications. A se- support interoperability?.
https://joinup.ec.europa.eu/
mantic interoperability specification enables organizations to process in- collection /european-inter-
operability-reference -archi-
formation from external sources in a meaningful manner. It ensures that tecture-eira/document/ how-
the precise meaning of the exchanged information is understood and pre- does-eira-support-interoper-
ability
served throughout exchanges between parties. In the context of the EIF,
semantic interoperability encompasses the following aspects:
– Semantic�interoperability is about the meaning of data elements and
the relationship between them. It includes developing vocabulary to
describe data exchanges and ensures that data elements are under-
stood in the same way by communicating parties. Semantic interoper-
ability specifications support semantic interoperability by addressing
the core semantic interoperability background for solutions.
– Syntactic� interoperability is about describing the exact format of
the information to be exchanged in terms of grammar, format, and
schemas.

7.5. Key interoperability enablers viewpoint

The key interoperability enablers viewpoint models the most salient

key interoperability enablers. The viewpoint uses the ArchiMate© mo-
tivation extension to assess the “sharing and reuse” readiness, the “ex-
change readiness” and the “interoperability readiness” of solutions that
are necessary to enable the efficient and effective delivery of public ser-
vices across administrations.

European public service provision often requires different organizations to

work together to meet the 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 plan-
ning, implementing and operating European public services. Services should
be governed to ensure integration, seamless execution, reuse of services and
data, and development of new services and ‘building blocks’.

The key interoperability enablers viewpoint should cover all layers: legal, or-
ganizational, semantic and technical. Ensuring interoperability when prepar-
ing legal instruments, organizing business processes, information exchange,
services and components that support European public services is a continu-
© FUOC • PID_00288926 42 Reference Architectures: the case of EIRA

ous task, as interoperability is regularly disrupted by changes to the environ-

ment, e.g., in legislation, the needs of businesses or citizens, the organization-
al structure of organizations, the business processes, and by the emergence of
new technologies.

Figure 10. Key interoperability enablers viewpoint

Narrative:

This viewpoint selects architecture building blocks related to key interoperability en-
ablers:

EIF [interoperability principles] are used to realize the overall goal of [achieving interop-
erability].

• Specifically, the goal of [achieving legal interoperability] is realized by [legislation

catalogues] that are used for provisioning/consuming legal texts, by [public policy
implementation approaches] that are used to ensure compatibility cross legal/juridi-
cal certainties and by [legal interoperability agreements] which are used to ensure
agreed legal terms/conditions for sharing, reusing and exchanging information.
• Specifically, the goal of [achieving organizational interoperability] is realized by [pub-
lic service catalogues] that are used for provisioning/consuming front-office public
services as well as by the [service delivery model] that are used to ensure compatibili-
ty between business interfaces and by an [organizational interoperability agreement]
that defines the operational terms/conditions for sharing, reusing and exchanging
information.
• Specifically, the goal of [achieving semantic interoperability] is realized by [data set
catalogues] that are used for provisioning/consuming data, by [representations] that
are used to ensure compatibility between interpretations of business information and
by the [semantic interoperability agreement] which is used to ensure agreed semantic
terms/conditions for sharing, reusing and exchanging information.
• Specifically, the goal of [achieving technical interoperability] is realized by [service
registry components] that are used for provisioning/consuming back-office services,
by [machine to machine interfaces] and/or [human interfaces] that are used to en-
sure compatibility between technical interfaces and by the [technical interoperabili-
© FUOC • PID_00288926 43 Reference Architectures: the case of EIRA

ty agreement] which is used to ensure agreed technical terms/conditions for sharing,

reusing and exchanging information.

7.6. Technical - application view

The technical-application view contains the most salient application

architecture building blocks that need to be considered in order to sup-
port technical interoperability when building an interoperable Euro-
pean solution. An interoperable European solution can support one or
more public policies.

Figure 11. Technical - application view of the EIRA©

Narrative:

An [interoperable European solution service] implements a [public service] and supports

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]. The [interoperable European so-
lution component] realizes the [interoperable European solution service]. The [interop-
erable European solution component] is tested through the use of [application test en-
ablers]. Data can be exchanged, cross-border and cross-sector, with the support of the [ap-
plication mediation enablers] containing the logic for data transfer and validation. The
[interoperable European solution component] can execute complex business processes
© FUOC • PID_00288926 44 Reference Architectures: the case of EIRA

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

lution] can have any [interoperability specification] associated, of which the
[technical interoperability specification] is a specialization, which is mandat-
ed by a [technical interoperability agreement]. The [technical specification] is
a specialization of the [technical interoperability specification].

A human interface is a boundary set of means enabling the exchange of data

between an individual and a service. This ABB is a key interoperability enabler
for assessing compatible interfaces.

• A machine-to-machine�interface is a boundary set of means enabling the

exchange of data between a service and other services. This ABB is a key
interoperability enabler for assessing compatible interfaces

• An interoperable�European�solution (IES) is a solution developed by or-

ganizations that facilitate the delivery of electronic public services and
cross-border exchange of information between organizations (or citizens)
in support to the implementation and advancement of EU, national or
local public policies (based on the ISA definition of a trans-European sys-
tem (TES)).

• An orchestration� service shares the functionality of defining the se-

quence and conditions in which one service invokes other services in or-
der to realize some useful function (based on W3C).

• An interoperability�specification is a document containing agreed nor-

mative statements for solution building blocks used in an information ex-
change context. It can refer to existing standards or specifications (source:
How does the EIRA© support interoperability?).

• A technical� interoperability� specification is a specification contained

in a document which lays down the characteristics required of a product
such as levels of quality, performance, safety or dimensions, including the
requirements applicable to the product as regards the name under which
the product is sold, its terminology, symbols, testing and test methods,
packaging, marking or labelling and conformity assessment procedures.
© FUOC • PID_00288926 45 Reference Architectures: the case of EIRA

7.7. Technical - infrastructure view

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 interoperability when
building an interoperable European solution.

The difference with the application part of the technical view (see section 10.6)
is that the architecture building blocks in the infrastructure view are relevant
for solutions in any sector of the government.

Figure 12. Technical - infrastructure view of the EIRA©

Narrative:

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 the [forms management service], the [record management
services], the [e-archiving service], or the [metadata management service].

The [data] can be archived using [e-archiving services] and published in external data
sources with a [data publication service].

The [collaboration enablers] can exchange messages between [interoperable European

solutions] using [messaging services] and exchange multimedia using [audio-visual ser-
vices].

The [application services] provided by an [interoperable European solution] can be dis-

covered by users or systems through [discovery enablers].

Privacy preservation is performed by the [privacy enablers]. The administration and op-
erational management of an [interoperable European solution] is performed through
[administration enablers].

Trust between systems is established with [trust service provisioning components], re-
alized by using signature validation and verification, such as an [e-signing creation ser-
vice], an [e-signature verification and validation service], or an [e-signature preservation
© FUOC • PID_00288926 46 Reference Architectures: the case of EIRA

service], and through e-seal services, such as an [e-seal creation service], an [e-seal veri-
fication and validation service], or an [e-seal preservation service], and e-timestamping
services, such as an [e-timestamp creation service], or an [e-timestamp verification and
validation service]. Identity management is realized with an [identity management ser-
vice]/[identity management component].

Evidence of transaction between parties is realized using the [registered electronic deliv-
ery service]. The [interoperable European solution] can register its architecture and ap-
plication documentation by using a [configuration and cartography service].

The [interoperable European solutions] and the [digital service infrastructures] are de-
ployed and operated through [hosting and networking service infrastructures], provid-
ed 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 infra-
structure] and the [hosting and network service] can have any [interoperabili-
ty specification] associated, of which the [technical interoperability specifica-
tion] is a specialization. The [technical interoperability specification] is also a
specialization of the [technical specification].

• A digital� service� infrastructure is an infrastructure which enables net- Bibliographic reference

worked services to be delivered electronically, typically over the Internet,
Source: Regulation (EU) No.
providing trans-European interoperable services of common interest to 283/2014).
citizens, businesses and/or public authorities, and which are composed of
core service platforms and generic services.

• A hosting and networking infrastructure service shares the functionalities

for i) hosting interoperable European solutions and ii) providing the nec-
essary networks for operating these solutions.

• An interoperability�specification is a document containing agreed nor-

mative statements for solution building blocks used in an information ex-
change context. It can refer to existing standards or specifications (source:
How does the EIRA© support interoperability?).

• A technical�interoperability�specification is a specification contained in

a document which lays down the characteristics required of a product,
such as levels of quality, performance, and safety or dimensions, includ-
ing the requirements applicable to the product as regards the name under
which the product is sold, its terminology, symbols, testing and test meth-
ods, packaging, marking or labelling, and conformity assessment proce-
dures.
© FUOC • PID_00288926 47 Reference Architectures: the case of EIRA

8. Other architecture styles

8.1. Modular monolith architecture style

In a modular�monolithic�architecture, the functionalities of a solution

are realized by a single integrated system (by modules), called monolith.

The modular monolith combines the simplicity of single process communica-

tion with the freedom of integration via componentization. Modular mono-
liths segment software code into individual feature modules. Each module is
exposed via a programming interface, API, to other modules. This means a low
coupling (i.e., not rigid) approach because we could change a module without
it having an impact on other modules.

This approach is applied by isolating data store and front-end. The modules
are traditionally clustered into 3-tiers: a front-end tier, a back-end tier (also
called business-tier), and a database tier.

This architecture style is often adopted due to its lower complexity, both from
the development and operational perspectives. Some benefits are:

• Software code is easier/faster to understand.

• The logic encapsulated in modules enables reusability.
• The impact of changes is limited through encapsulation and decoupling.
• Data structure remains simple (i.e., common).
• The underlying orchestration of modules is embedded in the integrated
system and has a low complexity.
• Operational costs are traditionally low.
• The code is executed in a single runtime environment (i.e., just one tech-
nology environment, one same system).

A major concern associated to this architecture style is the silo implication as

there is no interoperability with other runtime environments.

This type of architecture style promotes legacy. Indeed, it should be mentioned

that a non-modular monolith architecture should be moved to other types of
styles, with the modular being the closest one.

For example, the front-end module could be developed in Microsoft typescript. The back-
end modules could be developed in Java (e.g., Spring-boot ecosystem). The back-end is
exposed to the front-end through a layered system of APIs with a REST API dealing with
the resource and an API gateway distributing the requests. The back-end could commu-
© FUOC • PID_00288926 48 Reference Architectures: the case of EIRA

nicate with the database (i.e., Oracle) using JPA APIs. The (Oracle) database could be
hosted on the AWS platform.

EIRA© provides guidance on the modules that could be required, for example,
a module on authentication might be required, etc.

The deployment options could be:

• On�premises. This means a traditional data centre with the following con-
figuration:
– open-source Apache web server hosting the front-end,
– an Oracle WebLogic application server hosting the back end, and
– a database server (it could be Oracle) hosting the database manage-
ment system.

• Outsourcing. This would involve a container using a managed service,

either in a private or a public cloud setting.

Figure 13. Modular monolithic architecture

© FUOC • PID_00288926 49 Reference Architectures: the case of EIRA

8.2. Client-server architecture style

The client-server architecture style is a centralized network architecture

that partitions tasks or workloads between the providers of a service,
called the server, and service requesters, called the clients. The backbone
in this architecture style is a network resource (Internet, LAN). Client(s)
and server(s) might, or might not, reside in the same system. The pro-
tocol used is mainly TCP/IP.

Figure 14. Illustrations of client-server architectures

The server acts hosting just one digital solution (i.e., a dedicated server) or
several digital solutions and sharing it/them with clients. A client launches
requests for a service to be performed by the server through an API interface,
hence the clients do not require being aware of the server specifics (i.e., soft-
ware and hardware). However, compared to SOA, the client is typically tightly
coupled to the server. The clients, therefore, initiate communication sessions
with the servers, which await incoming requests. Examples of computer ap-
plications that use the client-server model are email, network printing, and
web servers.

The computing power, memory and storage requirements of a server must be

scaled appropriately to the expected workload. Load-balancing and failover
systems are often employed to scale the server beyond a single physical ma-
chine.

In a client-server architecture, the server is online and accessible within the

network for the clients to successfully process their requests. SOA services tra-
verse multiple and independent networks.

If the server end is a web hosting server, the on-premises architecture is de-
picted below. A relevant challenge in on-premises architectures is to manage
scalability.
© FUOC • PID_00288926 50 Reference Architectures: the case of EIRA

Figure 15. Illustration of an on-premises web hosting server

8.3. Peer-to-peer architecture style

In a peer-to-peer,� P2P,� architecture� style, two or more servers pool

their resources and communicate in a decentralized system.

An example of this would be several DBMS servers. The client-server architec-

ture style is a specialization of a P2P architecture with one centralized server.
In the P2P, clients and servers are called nodes.

Any node can launch a peer-to-peer request to another node. An algorithm

balances the load. If a node becomes unavailable, its shared resources, such
as processing power, disk storage or network bandwidth, remain available if
© FUOC • PID_00288926 51 Reference Architectures: the case of EIRA

other peers offer them. This is done without the need for central coordination.
Nodes are both servers and clients, in contrast to the traditional client–server
model in which the consumption and supply of resources is divided.

This means that a peer does not need to achieve high availability because
other, redundant peers make up for any resource downtime; as the availability
and load capacity of peers change, the protocol reroutes requests.

Figure 16. Peer-to-peer architecture

8.4. Microservices architecture style

A microservice�architecture�style is a variant of the SOA style where

a digital solution is built through a collection fine-grained loosely cou-
pled services called microservices. Integration is achieved through light-
weight protocols.

Some key principles of this style are:

• Services are fine-grained and organized around business capabilities

through the practice of domain-driven design software development ap-
proach.
© FUOC • PID_00288926 52 Reference Architectures: the case of EIRA

• High-availability and resilience is achieved through the implementation

of a choice of system patterns. The literature mentions patterns like data-
base per service, event-sourcing, command and query responsibility segre-
gation, eventual consistency, SAGA design, circuit breaker, and back-pres-
sure.

• Microservices are autonomously developed, operationally independent,

independently deployable, built and released with automated processes

Major benefits are:

• It takes advantage of the cutting-edge paradigm on software development

(i.e., cloud, containers, DevOps, serverless).
• Faster time to market and higher agility.
• It supports iterative or incremental modernization.
• It supports horizontal scaling (deploying more instances) and granular
scaling (scaling only the services that need it).
• Lower cognitive complexity on the developer’s head due to the smaller
size of the services.

But there are some disadvantages too:

• The digital solution is distributed in nature, and it leads to intrinsic com-

plexity in different runtime environments.
• Resilience is not automatic - it can only be achieved through the imple-
mentation of specific patterns.
• Observability of the whole solution is critical to keep a good response time
for investigating incidents and fixing problems.
• Security is more challenging to manage.
© FUOC • PID_00288926 53 Reference Architectures: the case of EIRA

Figure 17. Modular monolith vs. microservices

If we consider a granularity continuum between SOA and microservice there

is the�mini�services�alternative.

The Mini services are coarser-grained services, with respect microservices, im-
plementing multiple features functionality related to a domain, and sharing
a�common�data�store�with�other�services. Miniservices are a compromise
between the SOA and the extreme flexibility and scalability of microservices
architecture.

From the perspective of an API associated to the resource (service, miniservice,

microservice), granularity is the extent to which an API gateway divides re-
quests among individual resources. It does not refer to how much information
an API exposes, but rather to how many resources that information is spread
across. With a fine-grained API (i.e., for a microservice), a consumer might
have to make multiple, highly specific requests to different endpoints in order
to get the same amount of information as they would from a single call to a
coarse-grained API (i.e., service). There is a case for both fine and coarse gran-
ularity in terms of API performance. With coarse-grained resources, developers
need to make fewer calls to get the same amount of information, thereby re-
ducing cumulative latency and speeding up implementations. However, with
coarse-grained resources, we run the risk of giving consumers more informa-
tion than they need, thereby using excessive amounts of bandwidth.
© FUOC • PID_00288926 54 Reference Architectures: the case of EIRA

The opposite is true for fine-grained resources. On the one hand, we are not
giving consumers more information than they need (thus saving bandwidth),
but on the other hand, developers now need to make more calls to get the
same amount of information (thus slowing down client implementations).

When it comes to performance, we will have to make a trade-off between fine

and coarse granularity.

Figure 18. Microservices architecture

A microservice architecture typically gives more flexibility on the choice of

technologies used for each microservice. However, we do not want to multi-
ply the options too much here, as this would require acquiring and keeping
the knowledge and expertise for each option. Microservices provided by third-
parties, or from a cloud platform, are not subject to the following recommen-
dations and could be integrated in the digital solution:

• The microservices could be developed in Java by using Spring-boot.

• Microservices are integrated with other microservices through REST APIs
webservices, and messages-based asynchronous communications through
Apache Kafka.
• The microservices are exposed through REST APIs calling an API gateway.
• Authorization could be built by using the Nexus library.
• The microservices interact with databases, when they need one. Each mi-
croservice has its own database.
• Front-ends, when present, are similar to the front-ends of the modular
monolith architecture. Front-end microservices are exposed through REST
APIs.
© FUOC • PID_00288926 55 Reference Architectures: the case of EIRA

• The users are authenticated through a SOA identification service.

• Communication between front-end and other microservices could be se-
cured with OpenID Connect.
• Mobile applications, when present, would be exposed through REST APIs
as the front-ends.

The deployment options could be using containers, which could be either:

• On� premises. This means a traditional data centre using, for example,
Kubernetes.
• Outsourcing. To a cloud-provider.
© FUOC • PID_00288926 57 Reference Architectures: the case of EIRA

Bibliography
References

Baheer, B. A.; Lamas, D. and Sousa, S. (2020). A Systematic Literature Review on Existing
Digital Government Architectures: State-of-the-Art, Challenges, and Prospects. Administrative
Science, 10(2).

Bovalis, K.; Peristeras, V.; Abecasis, M.; Abril, R.; Alvarez, M.; Gattegno, C.; Kar-
alopoulos, A.; Sagias, I.; Szekacs, S. and Wigards, S. (2014). Promoting Interoperabil-
ity in Europe’s E-Government. Computer, 47(10), pp. 25-33.

Dick, J.; Hull, E. and Jackson, K. (2017). Requirements Engineering. (4th ed.). Springer.

Engelsman, W., Jonkers; H., Franken; H. M. and Iacob, M-E. (2009). Architecture-Dri-
ven Requirements Engineering. In E. Proper, F. Harmsen, and J.L.G. Dietz (eds.). Advances
in Enterprise Engineering II PRET 2009. Lecture Notes in Business Information Processing, 28.
Springer, Berlin, Heidelberg.

European Commission (2017). Communication on The European Interoperability Frame-

work- Implementation Strategy COM (2017). 134 Annex 2. https://eur-lex.europa.eu/le-
gal-content/en/TXT/?uri=CELEX:52017DC0134

European Commission (2019c). European Interoperability Reference Architecture,

EIRA©. https://joinup.ec.europa.eu/collection/european-interoperability-reference-architec-
ture-eira/about Accessed 6 April 2020.

Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addi-
son-Wesley Professional. ASIN: B00794TAUG

Fouad, A.; Phalp, K.; Kanyaru, J. M. and Jeary, S. (2011). Embedding requirements
within Model-Driven Architecture. Software Quality Journal, 19(2), 411–430

Geraldo, F. D., España, S., Pastor, O., & Geraldo, W. J. (2018). Considerations about
quality in model-driven engineering. Software Quality Journal, 26(2), 685–750

Glushko, R. J. (ed.) (2013). The Discipline of Organizing. The MIT Press.

Greefhorst, D. and Proper, D. (2013). Architecture Principles. The Cornerstones of Enterprise

Architecture. The Enterprise Engineering Series. Springer. DOI:10.1007/978-3-642-20279-7.

Lankhorst, M. (2013). Enterprise Architecture at Work. Modelling, Communications

and Analysis. The Enterprise Engineering Series (3rd edition). Berlin: Springer
DOI:10.1007/978-3-642-29651-2.

The Open Group (2014). The Service-Oriented Architecture Ontology Version 2.0 Specifi-
cation. https://www.opengroup.org/ Accessed 6 April 2020.

The Open Group (2017). The ArchiMate® 3.0.1 Specification. 2017. https://
www.opengroup.org/ Accessed 6 April 2020.

The Open Group (2018). The Open Group Architecture Framework (TOGAF® v9.2).
https://www.opengroup.org/ Accessed 6 April 2020.

Zachman, J. A. (1982). Business Systems, Planning and Business Information Control

Study: A comparison. IBM Systems Journal, 21(3).

Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems

Journal, 26(3).