The new European data protection regulation– are you prepared?

Update: Webinar with Andreas Richter on GDPR 24 March. Click here for registration.

The European Union’s new data protection regulation takes effect in 2018 and will have a bigger impact on European organizations than many might yet be aware of. For those approaching the subject from the right angle, the new rules do not just bring obligations, but also a variety of opportunities.

Since May 2016, the European Union’s new data protection rules (General Data Protection Regulation, GDPR) is in force, establishing a harmonized data protection framework for personal data across the entire European Union and European Economic Area (EEA). The regulation is now being transposed in all EA/EEA member states and will take effect as national law in May 2018. With this comprehensive regulation, the all Europeans are provided with a variety of new rights when it comes to protection and handling of our personal data. For all organizations collecting, processing and storing information, the new law first of all carries a broad range of obligations and new requirements they have to understand and comply with. Failing to keep personal data appropriately secure can result in fines of up to 20 million Euro or 4% of global annual turnover, whichever is greater.

The new regulation aims to strengthen people’s rights in the digital age and to simplify rules for internationally acting businesses by unifying them. After all, the data protection regulation is replacing varied national laws with just one framework that is equally valid in the entire EU/EEA. The ultimate goal is to give everybody more control over our personal data.

How are organizations affected?

The impact of the new regulation on organizations will be manifold and no business will remain unaffected, especially in the light of the ongoing digitalization. Organizations have to understand which of the information they are keeping are impacted by the regulation and how it is handled today, where and why it is kept and how it is protected. It requires understanding and adaption of business rules, business processes, information systems and IT infrastructure. Sounds like a complex and pretty big task to get on top of, and, bad news first, it is for sure not something that is done overnight. But the good news is that now is a good time for getting prepared, and that both methods and tools exist for getting a good grip on the job. Organizations that already have control over the enterprise’s architecture get a head start when it comes to understanding how they should react to changing market dynamics. And businesses that already today are managed with a strong process orientation can gain an advantage when it comes to easier transformation. QualiWare and Qualisoft, having over 20 years of experience as experts in the fields of Business Process Management (BPM) and Enterprise Architecture (EA), already started supporting our first customers in this transition with a structured approach. Such a structured, holistic approach is the perfect starting point for slicing the elephant of what is the new data protection regulation.

What is “personal data” and who is affected?

Understanding what “personal data” is a good thing to start with, and already comes as a surprise to many organizations. The EU defines “personal data” as “any information relating to an identified or identifiable natural person” – both directly and indirectly. Following this wide definition, not only names, addresses, credit card numbers or log in names, but also mailing lists, minutes of meeting, cookies or even photos from the last company picnic fall under this category (everything that makes somebody “personally identifiable”). Some data needs more protection and special rules apply for such sensitive data.

It becomes clear that the new regulation will affect virtually any company that is operating in the EU/EEA, not at least the public sector and those handling sensitive personal data. Most organizations are dealing with more personal data than they know. What you don’t know, you can’t control. It’s about time to get an overview.

What to do now?

It will take some time and resources to get accustomed to the new rules and transform the way of working in order to be compliant, so it is smart to start planning already now. But where to start? An issue that many will face is that it is not yet entirely clear to anybody what the new regulation will actually mean and how it actually will impact businesses. The Norwegian Data Protection Authority (Datatilsynet) is currently working through the 156 pages strong EU law, trying to break it down to practical guidelines and actionable tasks for getting a grip on the situation – but will not be finished with doing so until late 2017, only a few months before the regulation already becomes law. Do not wait that long. Even though you might not yet fully understand what the law will mean for your business and where you will actually need to adapt your policies and processes, there is a lot that you can do already now in order to be prepared. Be proactive rather than reactive. Start with understanding your organization and establish a sound information basis. This means you will need to:

  1. Get an overview over relevant requirements and where they are affecting your systems and processes
  2. Get an overview over which information you have today that is affected by the new law. Find out which data you are handling, why you are handling it and how it is used
  3. Ensure that the organization is compliant with the current law – this is the best possible basis!
The QualiWare/Qualisoft roadmap for achieving compliance towards the new EU data protection regulation: Start with getting an overview, understand where the law affects your business and plan for transformation.

The new law will affect organizations on many interrelated levels, from their processes down to the technology they are using internally and for exchanging information with third parties. Get an overview over both the current and the new law and understand where on those levels you are complying today and where your gaps are. After that, map up the information that your organization is using, where you are using it (processes) and where you are storing it (systems and technology). With your first comprehensive overview of how you are using personal data today, it allows you to easily identify requirements for your information and the rationale for handling it. A repository-based tool like QualiWare Lifecycle Manager will make your life a lot easier in these regards, both in terms of uncovering relations and dependencies as well as in terms of collaboration and maintenance.

The information basis that you now established is what you need to start your enterprise transformation journey – identifying gaps and defining necessary actions to close them through adapting your way of working through methods of business process transformation. The job of mapping up requirements against your organization that you did earlier will also help you here.

A repository-based tool like QualiWare will make it easier to gain an overview over relations across different perspectives, for example, where requirements touch your business processes

Establishing these overviews and relations before the new law takes effect in May 2018 will make you well prepared. Make sure you are not just waiting to see what will happen and trying to react as good as you can, but be proactive and gain control over both what you have and what you need to do. It is also a prerequisite for creating proper plans and allocate resources.

Enabling positive change

If you now think that the only answer to the question “Why do I need to do this?” is “Because I have to”, you can be assured that compliance is not the only thing you can gain from this exercise. It is not just a legal obligation; it is also an opportunity. If you approach the topic from the right angle, several benefits can be achieved:

  • Internationally operating companies can achieve substantial financial savings through unifying their policies and way of working
  • Demonstrating compliance with the new law will build trust of the customer and also promote innovative use of data
  • Process-based transformation and management leads to better business performance through a more coherent way of working, consistency in changes and increased consensus amongst employees
  • Better alignment of business and technology through a holistic architectural approach, resulting in saved IT cost and a more efficient processes
  • A generally improved approach to information security and compliance with international standards such as ISO 27001

Several of our clients have already started dealing with the new regulation and are gaining necessary overview through their management systems. After all, the most important advice for action is to not spend your time waiting. Be proactive, start looking into the new rules and understand where your organization is today. Are you prepared?

Further reading:


European Interoperability Reference Architecture

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

On 8 June 2015, release 0.9.0 beta of the EIRA entered an eight-week public review period. Stakeholders working for public administrations in the field of architecture and interoperability were invited to provide feedback.

What is EIRA?
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 initiative is part of Action 2.1 of the ISA Programme.

The EIRA is a four-view reference architecture for delivering interoperable digital public services across borders and sectors. It defines the required capabilities for promoting interoperability as a set of architecture building blocks (ABBs). The EIRA has four main characteristics:

  • Common terminology to achieve a minimum level of coordination: It provides a set of well-defined ABBs that provide a minimal common understanding of the most important building blocks needed to build interoperable public services.
  • Reference architecture for delivering digital public services: It offers a framework to categorise (re)usable solution building blocks (SBBs) of an e-Government solution. It allows portfolio managers to rationalise, manage and document their portfolio of solutions.
  • Technology- and product-neutral and a service-oriented architecture (SOA) style: The EIRA adopts a service-oriented architecture style and promotes ArchiMate as a modelling notation. In fact, the EIRA ABBs can be seen as an extension of the model concepts in ArchiMate.
  • Alignment with EIF and TOGAF: The EIRA is aligned with the European Interoperability Framework (EIF) and complies with the context given in the European Interoperability Strategy (EIS) . The views of the EIRA correspond to the interoperability levels in the EIF: legal, organisational, semantic and technical interoperability. Within TOGAF and the Enterprise Architecture Continuum, EIRA focuses on the architecture continuum. It re-uses terminology and paradigms from TOGAF such as architecture patterns, building blocks and views.

EIRA in one picture
The figure below provides a high-level overview of the four views in EIRA. Each of the four views consists of a set of Architecture Building Blocks (ABBs) and relations pertaining to the legal, organisational, semantic and technical domain of an Interoperable European Architecture. Each view has entry and exit points from one view to another.


The legal, organisational, semantic and technical domains are the classic European interoperability concerns. The EIRA defines building blocks for each view.

The views

Legal interoperability View
Organisational interoperability view

Semantic interoperability view
Technology interoperability view – applications

Technology interoperability view – infrastructure

In addition, a new Interoperability specification underpinning view has been added as an additional view, depicting architecture building blocks of the different views as a taxonomy of interoperability specifications:

The “metaview” detailing and specifying interoperability.

EIRAs raison d’etre?

The key concepts of the EIRA and their relationships are described here:


The following list explains the different relationships:

A. The EIRA is derived from the European Interoperability Framework (EIF);

B. The EIRA has one view for each EIF interoperability level;

C. Each EIRA view contains several EIRA ABBs;

D. EIRA ABBs can be used to create reference architectures;

E. A SAT addresses a certain interoperability need. It consists of a sub-set of the most important EIRA ABBs and is derived from a reference architecture;

F. An EIRA SBB realizes one or more EIRA ABB;

G. A (interoperable) solution consists of one or more SBBs;

H. A (interoperable) solution realizes a solution architecture;

I. A solution architecture can be derived from a SAT or directly from a reference architecture;

J. As the EIRA focuses only on the most important ABBs needed for interoperability, other ABBs (= non-EIRA ABBs) can exist;

K. Similar to ABBs, non-EIRA SBBs can exist next to EIRA SBBs.

Release 0.9 of the EIRA does not provide as much detail about the SBBs as it does on the ABBs. This will be done in another project. Also see the SBB template document.

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). The release 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. Zip file containing each of the above mentioned files.

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 Burlton, Paul Harmon, Alan 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) and Asset 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:

US FEAF-II Performance Reference Model
EU EIRA Legal Interoperability view

EIRAs organisational view
US 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.