Navigation path

European Interoperability Reference Architecture (EIRA)

(
 
)
3.33/5 | 15 votes
Editor's choice

Available Translations

Available Translations:

EIRA release v0.9.0 beta

(
 
)
3.67/5 | 3 votes |

Description

  1. About the European Interoperability Reference Architecture (EIRA)
  2. Pilots
  3. Release
  4. Public review

About the European Interoperablity Reference Architecture

The European Interoperability Reference Architecture (EIRA), is an architecture content metamodel defining the most salient architectural building blocks (ABBs) needed to build interoperable e-Government systems. The EIRA provides a common terminology that can be used by people working for public administrations in various architecture and system development tasks. The EIRA was created and is being maintained in the context of Action 2.1 of the ISA Programme. The EIRA uses (and extends) the ArchiMate language as a modelling notation and uses service orientation as an architectural style. The EIRA is aligned with the European Interoperability Framework (EIF) and complies with the context given in the European Interoperability Strategy (EIS). Further information about the EIRA can be obtained in the document 'An introduction to the European Interoperability Reference Architecture v0.9.0' (EIRA_v0.9.0_beta_overview.pdf).

Pilots

In the period September 2014 – May 2015, a number of pilots (see pilot report) were conducted using the EIRA with public administrations in Denmark, Estonia, and The Netherlands, and with European Commission Directorate-Generals DIGIT, CONNECT (e-SENS project), and MARE.

 

This release

 
This release incorporates the feedback received from participants of the EIRA/CarTool pilots conducted with public administrations of Member States and EU Institutions in 2015.
 

It consists of the following release components:

  1. EIRA_v0.9.0_beta.archimate: Archi file containing the EIRA ArchiMate model.
  2. EIRA_v0.9.0_beta.html: HTML version of the EIRA ArchiMate model.
  3. EIRA_v0.9.0_beta_overview.pdf: PDF document containing an introduction to the EIRA, including its key concepts, used ArchiMate notation, tool support, and views.
  4. EIRA_v0.9.0_beta_ABBs: An HTML file containing the definitions of the architecture building blocks.
  5. EIRA_v0.9.0_beta_release_notes.pdf: PDF document containing the release notes.
  6. EIRA_v0.9.0_beta_release_document_set.zip: Zip file containing each of the above mentioned files.

Public consultation

On 8 June 2015, this release (EIRA v0.9.0 beta) entered a public review period. Stakeholders working for public administrations in the field of architecture and interoperability are invited to provide feedback until 30 September 2015.

How can you help?

  1. Download the release 0.9.0 beta of the EIRA from the Joinup platform;
  2. Login to Joinup (registration is required); and
  3. Provide your comments on the bottom of the page ‘release 0.9.0 beta of the EIRA’  (login is required).

What happens with your feedback?

  1. All comments will be monitored, processed and analysed;
  2. Based on the comments, requests for change will be proposed;
  3. Resolutions of those issues will be shared on Joinup and the approved requests for change will lead to a new release of the EIRA.

EIRA High Level Overview

ArchiMate® and TOGAF® are registered trademarks of The Open Group.

ArchiMate© and TOGAF© are copyright of The Open Group. All rights reserved.

Archi® is a registered trademark of Phillip Beauvoir.

 

Pavel Hrabe
Posted by Pavel Hrabe on October 07, 2015 at 19:00
"

To reference models

I fully agree that EIRA, which is only reference architecture for these parts of enterprises (agencies) in public administration, which are related to interoperability itself, should be aligned with EA methods and standards (frameworks) providing guidance in management of agencies and its IT  support as whole and with reference models of these frameworks and reference models representing current best practice.

Reference model of FEAF is to me one of important original models, but currently I prefer its New Zealand modification, which seems to me much better.

For Czech Government EA we will use the same (similar) structure of domains like GEA-NZ 3.1, but would like to adjust the structure and content of all corresponding reference models. Would be good to discuss GEA reference models and other accelerators with all of you, who are interested.

 

Pavel Hrabe, Ph.D.

Czech GEA Methodist

EIA Team
Posted by Eia Team on October 02, 2015 at 10:32
"

Dear contributors,

 

Thank you for the comments regarding EIRA v0.9.0. The public review period is now closed. We will process and review the comments. Please check-in in the following months for new releases of the EIRA.

 

Thank you

 

The following comments have been received via different channels:

Nicola Guarino
Posted by Nicola Guarino on August 03, 2015 at 22:19
"

Comments to the EIRA

 

          With respect to the Conceptual Model for Public Services developed as part of the EIF initiative, and reported in Fig. 10, this EIRA draft document makes an important step forward, by making explicit how the various EIRA building blocks belong to the different levels of the EIF interoperability hierarchy (reported in Fig. 3). In particular, a very important clarification introduced by the EIRA is that public services (differently than, say, Web services) are not software solutions, but they are business level entities that are realized with the help of software solutions. A further important clarification is the relationship between public services and public policies: public services are described as implementations of public policies. So, the explicit account for an organizational level and a legal level is in our opinion the most relevant contribution of this document.

 
However, despite the laudable intentions, the way this document accounts for the legal and (especially) the organization level makes it almost unusable to address the interoperability needs of European public services. In short, the main problems are the following ones:
 
  1. The definition of public services is extremely problematic. Indeed, the definition reported at page 23 merges together three different definitions, all problematic. The first one sees a public service as an economic activity of particular importance that would have not be supplied if there were no public intervention. Suppose however that a particular administration, although recognizing the importance of a certain activity, does not have the money for implementing it. Would this activity count as a service provided by that administration? The second definition sees a public service as a capacity to carry out a certain procedure. What if the administration, although having a certain capacity, decides NOT to the provide the corresponding service, for various reasons (e.g., saving money?). Finally, the third definition sees a public service as a set of deeds or acts performed for the benefit of the citizen. What about services such as snow removal, fire brigades, or social insurances, which are suppose to exist even when (under normal conditions) no actions are performed? All these examples show that public services should be based on a notion of commitment, which is absent in the EIRA.
  2. No attempt is made to provide guidelines to describe the nature of the various public services (what they are about – e.g.,what makes the difference between an emergency medical assistance service and a residence change service); In our opinion, the nature of a service is base –first of all– on the kind of action the provider commits to guarantee. Such actions should be explicitly put in the model. Among other advantages, modelling core actions associated to services explicitly would allow for the easy classification of the various technical infrastructure services appearinf in Fig. 16.
  3. Also the structure of public services is very poorly modeled: the roles of the various organizational units involved in a public service are poorly described, responsibilities and service level agreements are crucial for monitoring the quality of service, but they are not mentioned.
  4. The crucial role of external providers is not taken into account. In many cases (typically for cloud services) software solutions are developed and provided by external providers, who sign a contract with a Public Administration as a result of a public pauction. In these situations, complex relationships need to be modeled involving the citizen (as a service consumer), the Public Administration (as the primary provider) and the external (secondary) provider.
  5. The way semantic interoperability would be enforced by the EIRA is not clear at all. No notion of ontology is mentioned, and apparently semantic interoperability builds on a vague notion of "interoperability agreements" (among whom?) which is not discussed.
Further modeling issues:
 
Especially the Organizational view presents several technical problems. We mention just a few of them (if useful, we can provide an annotated PDF file with all the problems we found).
 
  1. There is no uniformity when associating Interoperability Agreement with Providers and Consumers: it is associated with Public Service Provider in one side, but directly to Citizen and Organization on the other side, and not with Public Service Consumer, as expected.
  2. The Interoperability Agreement is defined (according to the description) in relation to a Public Service to be provided, but Public Services do not have a direct relationship with Interoperability Agreement.
  3. A relationship between Organization and Organizational Enabler should be represented in the model, as expected and to follow what is contained in the corresponding description.
  4. Organizational Policy, Organizational Procedure and Organizational Structure are all Organizational Enabler, but enabler of what? What is the relationship that “creates” this role?
  5. There is no association between Organization Policy and Organization Procedure, which seems to naturally exist.
Finally, the definitions presented for Business Information Exchange and Business Information are identical (page 24).
 
Acknowledgements. The comments above are the result of a research work on the ontological foundations of services and service science which started at the ISTC-CNR Laboratory for Applied Ontology in Trento (Italy), and then involved the Federal University of Espirito Santo and Rio de Janeiro (Brazil) in the framework of two joint projects funded by the Brazilian government, as well as the Department of Computer Science of University of Salento (Lecce, Italy) in the framework of the joint participation to the Cloud4Europe call. Some relevant research papers are listed below. Main people involved: R. de Almeida Falbo, N. Guarino, G. Guizzardi, Antonella Longo, Luiza Machado Campos, J. C. Nardi.
 
Relevant papers
 
Nardi, J. C., de Almeida Falbo, R., Almeida, J. P. A., Guizzardi, G., Pires, L. F., van Sinderen, M. J., Guarino, N. , Fonseca, C. M. (2015). A Commitment-based Reference Ontology for Services. Information Systems (in press). 
 
Nardi, J. C., de Almeida Falbo, R., Almeida, J. P. A. An Ontological Analysis of Service Modeling at ArchiMate’s Business Layer. 2014 IEEE 18th International Enterprise Distributed Object Computing Conference (EDOC 2014)
 
Ferrario, R., Guarino, N. 2012. Commitment-Based Modeling of Service Systems. In M. Snene (Ed.), IESS 2012, International Conference on Exploring Services Science, Springer Verlag, Lecture Notes in Business Information Processing, vol. 103, Berlin Heidelberg 2012, pp. 170-185.
 
 
Ferrario R., Guarino N. Towards an Ontological Foundation for Services Sience. In Domingue, J., Fensel, D., and Traverso, P.: First Future Internet Symposium, Vienna, Austria, September 28-30, 2008: Revised Selected Papers.  Lecture Notes in Computer Science, Vol. 5468, Springer Verlag 2009, pp. 152-169
Linda Humphries
Posted by Linda Humphries on August 03, 2015 at 12:12
"
The EIRA documentation sets out a positive vision of how interoperability can support better delivery of online public services. I think this revision of the EIRA is a useful opportunity to think about our ambition, what we are looking to achieve with this work and how we can best make it happen. In particular, it would be good to revisit the question of the user needs that are being addressed by this work. It seems that there are 2 main sets of users here: technologists (both in government and those who use government services and data to build additional services) and the service users (the people who transact with the services it intends to help deliver).
 
From the technologists perspective, our experience is that there can be a lot of value in a model that echoes the wider open source community, where search tools, some common open standards, and community forums help people find code. There's very solid evidence that open source tools have much more adoption among software developers than complex architectural frameworks.
 
For example, when sharing software components across European governments, common vocabularies may help – but the needs here are about the ability to find relevant code (an outcome), not the need to be able to categorise it (a mechanism). That is what will help us, both for building services without repetition, sharing components, and in moving towards interoperability.
 
Looking at what both technologists and service users need to do and why will be important in considering the best architecture for interoperability. For example, in some instances we may find situations where publication of open data and APIs are the most effective route, enabling technologists outside of government to build on government data/services to meet a user need.
 
To deliver the most effective architecture, it will be important to consider EIRA in the light of genuine use cases, focussing possibly on the cross-border services where work is already being done in Europe, or on new questions being raised as genuine user needs for more effective cross-border service delivery. Part of that will be working more closely with other programmes on cross-border service delivery such as the eIDAS Regulation and work on the interconnection of business registries. The e-government action 2016 - 2020 plan will hopefully pick up on how some of these initiatives fit together.
 
By spending some time orienting this work through the lens of user needs, we can hopefully ensure that it produces the most useful output.
Jari Kallela
Posted by Jari Kallela on July 31, 2015 at 10:26
"

As a general observation we would like to note that the document is clear and useful. TOGAF as the enterprise architecture method and ArchiMate as the notation are widely used and thus good frameworks.

 

Unfortunately, the Cartography tool is not yet available. The objective of EIRA is to develop and find common solutions and this is hard in practice with just this document. The tool for using the models is needed in order to evaluate the content and usefulness of the definitions and concepts in this document. The name “Cartography” is a bit confusing, because the tool is more like a visual metadata repository and is not related to INSPIRE or other location data.

 

Version management is not defined. What would be the version policy for the future versions of EIRA? Is there going to be backwards compatibility?

 

The benefits of EIRA can be realized only after EIRA has been adopted by a number of member states. Unfortunately, this will be a risky and slow development. Member states may find it difficult to model and structure their national architectures according to this framework. The modeling concept is comprehensive but the downside is that it can be also quite heavy and laborious. It would be beneficial to include a stripped-down, simplified but still compatible version which can be used for the management communication.

 

3.2.1: EIRA uses quite many Archimate model concepts. In many cases models and views are easier to read and understand when the model concept set is more limited.

 

3.2.2.: Using stereotypes in the concept names can complicate the analysis afterwards. It may be difficult to search for same or similar concepts. Similar definition can be made using “realization” relationship although this would not be visible in all the views.

 

Fig 9: Business Capability is used as a realization of Business Service (“The delivery of these public services is realised through [Business Capabilities]”) using model concept “Business function”. In TOGAF the meaning of Capability is more abstract than a collection of functions and often capabilities are realized through services and not the other way round. In EIRA Business Capability is used in uniform way but the general meaning is a bit inconsistent. Maybe Business Function could be used instead. Business capability is a difficult concept for non-architects, business functions is better. Unfortunately, the definition of the business functions is missing from the Glossary in page 44.

 

Fig 10: EIRA is based on quite traditional SOA approach and it uses functionalities like orchestration and choreography. In solution development new approaches, like microservices, are dominating today. The SOA approach should be updated. Choreography services and orchestration services are specific SOA concepts and in practice quite rare. Perhaps EIRA would be more understandable if these are excluded.

 

The data policies in page 25 are useful and it is good that there is also a set of named policies. The glossary also refers to data quality policy.

 

In the Glossary on page 52 there is the definition of descriptive metadata. We are wondering the meaning of the word descriptive in this context: metadata is always descriptive anyway. It would be good to have the glossary also in alphabetical order.

Michał Bukowski
Posted by Michał Bukowski on July 29, 2015 at 11:25
"

I've got one remark related to "An introduction to the European Interoperability Reference Architecture v0.9.0  (EIRA)":

“2.3 Target users and use cases

The EIRA targets the following users within public administrations of Member States or EU institutions: (...)”

 

I suggest inclusion to scope of users category of „enterprise architects” who design central and local government enterprise architectures, consisting of – among others – architecture building blocks (ABB). These national, regional, and domain enterprise architectures should be aligned top-down, including conformance with European Union Enterprise Architecture.

John Gøtze
Posted by John Gøtze on July 26, 2015 at 12:26
"

Quick analysis of EIRA

EIRA lists 161 architecture building blocks. Of these, more than half are technical:

  • 82 Technical View (27 Application and 55 Infrastructure)
  • 26 Organisational View
  • 19 Semantic View
  • 18 Legal View
  • 6 Interoperability View
  • 10 Deprecated (11 if ABB59 Logging Service included – not marked in View:Deprecated but in Status).

The building blocks are described via selected archimate model concepts, of which four are used a lot:

  • 40 archimate:ApplicationService
  • 34 archimate:BusinessObject
  • 26 archimate:ApplicationComponent
  • 18 archimate:DataObject

Other model concepts are also used:

  • 6 archimate:BusinessProcess
  • 5 archimate:Contract
  • 4 archimate:BusinessActor
  • 3 archimate:BusinessRole
  • 3 archimate:InfrastructureService
  • 3 archimate:Network
  • 3 archimate:Node
  • 2 archimate:ApplicationInterface
  • 1 archimate:BusinessFunction
  • 1 archimate:BusinessInteraction
  • 1 archimate:BusinessInterface
  • 1 archimate:BusinessService

So, looking at the big picture, EIRA is perhaps a bit “heavy” on the technology side of interoperability, but does cover the four layers. In particular, EIRA establishes a set of views across the four layers. In doing so, it has to “embrace and extend” ArchiMate.

EIRA and ArchiMate

EIRAs commitment to ArchiMate is somewhat courageous. And somewhat creative, for example:

  • EIRAs Business Capability is covered by archimate:BusinessFunction
  • EIRAs Business Information Exchange is covered by archimate:BusinessInteraction

A Business Capability is the expression or the articulation of the capacity, materials and expertise an organization needs in order to perform core functions. Enterprise architects use business capabilities to illustrate the over-arching needs of the business in order to better strategize IT solutions that meet those business needs.

A Business Information Exchange is a piece of business data or a group of pieces of business data with a unique business semantics definition in a specific business context [ISO15000-5, UN/CEFACT CCTS].

These are work-arounds to two well-known ArchiMate limitations.

The archimate:BusinessObject is also quite busy, and for example covers these ABBs:

  • Business Rule
  • Business Information
  • Organisational Procedure
  • Organisational Structure

Again, work-arounds to current ArchiMate limitations.

EIRAs ABBs have changed with each release. Deprecated ABBs in the 0.9 beta include:

  • Business Process
  • Business Process Model
  • Business Transaction
  • Licensing and Charging Policy
  • Privacy Policy
  • Metadata Management Policy
  • Data Routing Service
  • Data Routing Component
  • Information Security Policy
  • Data Quality Policy
  • Logging Service?

So, Business Process and Business Process Model are deprecated, but the archimate:BusinessProcess model concept is used several times, namely for these ABBs:

  • Public Policy Cycle
  • Definition of Public Policy Objectives
  • Formulation of Public Policy Scenarios
  • Impact Assessment
  • Public Policy Implementation
  • Public Policy Evaluation

ArchiMate of course allows for a certain amount of flexibility (ArchiMate 2.1, Chapter 9 Language Extension Mechanisms), but the creativity can be dangerous, expecially in an interoperability context.

EIRA is an many ways ahead of ArchiMate. The challenge is that ArchiMate is under continuous development, and is likely to change on exactly these areas in future versions (see chapter 12.1 in the ArchiMate 2.1 spec). So EIRAs current notation standard should be seen as a temporary “fix”.

A note of caution

EIRA has obviously selected a winner of the longstanding Process vs Capability Debate. Eradicating processes is rather bold, and contrary to advice from experts like Roger BurltonPaul HarmonAlan Ramias and Andrew Spanyi, and Keith Swenson. While it is laudable to focus on capabilities, the use of capabilities should not be seen as an alternative to using processes and business process models. Both are needed.

EIRA and Open Data

The EIRA model is available as an Archi file. The data is also available in Archi-produced HTML and images.

From a maturity standpoint, this is only just acceptable. Even an Excel sheet version would be better, but better would be “raw data” available in a range of formats, possible as an api.

Of course, The Open Group is working on an ArchiMate Model Exchange File Format, and has sponsored the development of an Archi plugin for exporting to that format.

Apart from listing a few generic and rather useless Dublin Core metatags (in the HTML table), the current EIRA model is weak on metadata provision. EIRA could, for example, have used Data Catalog Vocabulary (DCAT) andAsset Description Metadata Schema (ADMS), and the team may want to check out this guide.

Interoperable frameworks?

EIRA does not have any mapping to any other framework.

The Legal and the Organisational views are less conventional as architecture views go. The Semantic, Application (Technical) amd Infrastructure (Technical) views are classic architecture views in many EA frameworks. A comparison with established frameworks seems to be a good idea.

A key part of the US Federal Enterprise Architecture Framework Version 2 (FEAF-II) is the Consolidated Reference Model, which equips the US Federal Government and its Federal agencies with a common language and framework to describe and analyze investments. It consists of a set of interrelated reference models that describe the six sub-architecture domains in the framework:crm

  • Strategy
  • Business
  • Data
  • Applications
  • Infrastructure
  • Security

EIRAs Legal view is roughly equivalent to FEAF-IIs Strategy (Performance Reference Model), and EIRAs Organisational view roughly equivalent to FEAF-IIs Business Reference Model.

Contentwise, EIRA and FEAF-II use these two layers in different ways:



prmUS FEAF-II Performance Reference Model

eira-legalEU EIRA Legal Interoperability view

eira-orgEIRAs organisational view

brmUS FEAF-II Business Reference Model

EIRAs model scope is wider than FEAF-IIs, but FEAF-II is more comprehensive as a classification scheme.

EIRA should consider taking inspiration from FEAF-II, and at least add a security view. If anything, such view should become mandatory for all European governments.

Towards EIRA 1.0

The 0.9 release of EIRA is a big step forward for reference architecture work in European governments.

QualiWare proposes a rapid consolidation and documentation process, and then releasing Version 1.0. EIRA should not await the next version of ArchiMate, but rather run with well-documented revision control.

QualiWare is committed to supporting international governments in their interoperability work. QualiWare fully supports using ArchiMate 2.1. If customer demand requires it, the “EIRA ArchiMate” approach can easily be supported.

Read more on https://coe.qualiware.com/european-interoperability-reference-architecture/

John Gøtze, PhD
Editor-in-Chief, QualiWare Center of Excellence
https://dk.linkedin.com/in/johngotze

Pavel Janovjak
Posted by Pavel Janovjak on July 08, 2015 at 11:32
"

Hi,

I have no comments to the EIRA itself. Its nice job, I am pretty happy this is going in good directions.

I have prepared a Motivation layer for EIRA 0.9.0 beta (a simple version), maybe you will find it usefull for stakeholder communications. Feel free to comment/add/adjust.

Keep Archimate-ing!

Many regards,

Pavel

https://sk.linkedin.com/pub/pavel-janovjak/10/567/255

 

Metadata

Type: Interoperability Solution
Solution category:
Framework
Solution type:
Legal View, Organisational View, Semantic View, Technical Vew
Date of creation:
29 May 2015 - 16:06
Date of last modification:
4 Apr 2016 - 10:53