By The Open Group
Moving to a digital infrastructure requires far more interoperability and Boundaryless Information Flow™ than in the past. This is particularly true for digital transformation efforts within governments, many of which are known for being extremely siloed, where information exchange between government branches or agencies can be problematic.
The European Union is currently deploying an Interoperability Reference Architecture as part of its e-Government initiatives. We spoke with Raul Abril, Programme Manager, EU Policies for the European Commission, about how his team is going about building that architecture, which is known as the European Interoperability Reference Architecture. Raul will be a keynote speaker at The Open Group Paris 2016 on October 24.
Tell us a bit about the European Interoperability Reference Architecture. How was it designed and how is it currently being used?
First of all, the European Interoperability Reference Architecture (EIRA) came from a vision. This vision was that it had to fulfill a need, and the need was expressed in the existence of digital barriers across European borders, which is against one of the major political priorities in the European Union: The creation of a real and effective single market. It had to be a reference to build up solutions that are interoperable. This is important at all levels (local, regional, national, European) of public administration because many of the e-Government solutions were created in a silo mode. There was a need to provide a common framework for solutions architects to design their solutions in a way that would allow their solutions to be interoperable. There was a business need obviously, and then the way of implementing the EIRA came from my personal professional experiences. The European Commission in general and the Interoperability Solutions for public Administrations unit, ISA in short, in particular, through the ISA2 Programme, have brought state of the art approaches and talent on board in order to address such needs.
How does the EIRA help provide a structure for interoperable e-Government solutions?
EIRA helps in different ways. One obvious way is that the EIRA is a controlled vocabulary. There are definitions, there are building blocks and there are relationships and the set for those things is in a controlled vocabulary. Why is that important? Because we need to understand each other, so one way of achieving interoperability is by achieving and expressing our designs in the same way.
I’ll give you an example of it in practicality. When you are a public vendor, when you are a government or a member state and you ask for offers and want to express your terms of reference, if we are all using the same controlled vocabulary, there is no doubt that the conformance will be better. But there are other ways. How is EIRA supporting interoperability? The answer also comes from another important concept—the interoperability specifications. Those interoperability specs should be based in open standards. What makes a building block interoperable should be described using interoperability specifications. This becomes a critical success factor for achieving interoperability between solution A and solution B. Why? Because by doing that then solution A and solution B will be using the same interoperability specs. Does it mean that both will be interoperable? Not necessarily, but if they don’t have that it will be almost impossible for them to be interoperable. That’s where the EIRA supports interoperability.
We have started identifying what interoperability specs, based on standards, should be referred in each of the building blocks in the EIRA.
How is TOGAF® helping to inform the EIRA?
TOGAF, an Open Group standard, is one well known approach for enterprise architecture frameworks (EAF). Of course, there are other EAFs. The reason for using TOGAF was because we consider it appropriate in terms of openness, which is what we’re looking for. This does not mean that European public administrations will have to use TOGAF.
EIRA is a reference architecture. A reference architecture is basically a reference model married to an architectural style. The architectural style we selected for EIRA was SOA, service oriented architecture. That was a critical decision, which means that we wanted to conceptualize any type of solution as being service based, which means that we also care about the code components. But we are also putting attention on the behavioral part. That’s why we selected SOA.
The reference model explains the ontological properties of the components that you’re going to have. How do you designate names? What are the properties of the relationships between them?, etc. We selected ArchiMate®, an Open Group standard, as the ontology for our reference model. So, the EIRA is based on ArchiMate as the reference model and in a service oriented architecture as the architecture style.
After explaining the “RA” in the EIRA acronym, we should explain now the “I” for interoperability. In general, reference architectures like the EIRA do not have the same ambition as enterprise architecture frameworks. EAFs like TOGAF have the ambition to provide support for the end-to-end design, implementation and lifecycle of a solution. Reference architectures focus on a specific aspect—in the EIRA case, interoperability—and they need to provide the most salient—not all—architectural building blocks that should be considered to address such specific aspects. The EIRA provides guidance on the most salient architectural building blocks to be considered when designing an interoperable solution.
For example, if you are going to design whatever solution for a business or government, one of the things you’ll consider is back-up services. You’ll consider security measures, and one of those will be backing up your data, files, etc. The EIRA doesn’t care at all about back-up services—it doesn’t mean we don’t care about security, but we don’t care about back-up services because it’s not an essential service for interoperability.
At the beginning we identified the key architectural building blocks that were the most salient for supporting interoperability. Today, the EIRA is the result of a collaborative effort. So far a community of representatives of central public administrations of six European Member States have participated in the design and releases of EIRA with their feedback and they’ve been validating the building blocks that EIRA has as the most salient for interoperability.
Are there challenges that are specific to building Reference Architectures for e-Government? What are they?
The biggest challenges are related to what I said before—getting a consensus in the community on what the interoperability specs should be and the standards for each of them.
Another challenge, I think, is adoption. There is a well-known issue with technology adoption in general and with solutions/frameworks/models in particular. One thing is to have the solution and it’s another to get it adopted. We are not talking about, let’s say, solutions for consumers like smartphones. We’re talking about communities of users that are very special. Generally speaking, solutions architects, portfolio managers, policy makers and also CIOs. Those are the potential users of reference architectures.
There is a lot of effort in communicating and disseminating information, and I don’t underestimate the effort it involves. Our challenge is in demonstrating to users and member states how they can use EIRA to solve national interoperability problems—for example, between their central, regional and local administrations, which in many places are huge. When users realize that the EIRA provides value addressing domestic problems, then they are better equipped to address their interoperability issues in cross-border public services.
What benefits do you expect to be able to receive from using the EIRA?
I expect first of all reusability. With interoperable solutions, you are able to reuse the information that has been produced in another place. So, we support the only once principle. The second one is the elimination of digital barriers. By interoperability of solutions we mean something as complex as to have a solution A in one place that is able to send information to another solution B, and that solution B is able to understand the information that has been communicated without noise and to process it respecting ex ante organizational and legal agreed terms. So, this is a more complex level of interoperability than just a message exchange because, for example, it should support administrative processes across borders. In fact, there has been significant progress understanding what is exchanged (i.e. message, data, documents) not mentioning that the technological aspects are well standardized. The issue remains on what happens in both ends from a legal and organizational perspective.
Coming back to the ultimate benefit, the EIRA will support the digital single market. By having interoperability you eliminate digital barriers. This is a huge expected benefit.
This translates into direct benefits for the citizens and businesses. In Europe there is, by comparison with the U.S., less mobility than in the U.S. If you move from the U.S. East Coast to the West Coast, there may be a three-hour time difference, but you will have less problems with many things. You may need to get a driver’s license in a new state but they recognize each other’s driver’s licenses. Here there are a lot of things to be achieved with the mobility of citizens and their needs in terms of public services. In some cases, if you want to move from one country to another, it is possible to access the public services of our home country via a portal. If we would be able to replicate this approach in all Member States and, very importantly, in a coherent way, then we would provide a huge benefit to citizens and businesses. The EIRA allows implementing holistically interoperability, not just from machine to machine.
Raul Mario Abril Jimenez works in the ISA unit as Programme Manager, EU Policies, European Commission. He recently relocated to Brussels from Barcelona. He has had permanent residences in San Diego (USA) where he worked for 6 years and before he was based in Copenhagen (DK) for 7 years. He has +35 years of IT professional services experience on international professional engagements in Financial & Telco industries. His knowledge domains are Research Methods (Quantitative & Qualitative Analysis), Marketing (Research, IS), IT R&D (Portfolio Mgmt, Product Mgmt), Project Mgmt, and IS & Technology (Knowledge Management, DSS, BI, Data Warehousing, DBMS, IS Design). Raul has been professor in several universities and been active publishing his research.
Raul holds a doctoral degree (Henley Management College, UK), a European PhD Certification (European Doctoral School on Knowledge Management, DK), an Ing. Sup. Informatics (UAB, E), and a Master in Project Mgmt (The George Washington University, USA). He is a PMP certified professional.