Reacties EIRA 0.9.0
Advies over de EIRA versie 0.9.0 beta[bewerken]
De NORA en Bureau Forum Standaardisatie hebben namens de Nederlandse gemeenschap van architecten in de publieke sector een gebundeld advies uitgebracht over de EIRA versie 0.9.0 beta, zoals die ter publieke review is aangeboden. Dit advies is gebaseerd op de reacties die binnen zijn gekomen bij NORA, Bureau Standaardisatie en de Architectuur Board Rijk. Zie NORA bundelt reacties NL op EIRA.
Het advies zoals dat is aangeboden aan het programma is te downloaden:
- Nederlands advies over EIRA v0_9_0 beta.pdf (PDF, 50 kB)
- Engelse vertaling Nederlands advies over EIRA v0_9_0 beta.pdf (PDF, 51 kB)
Antwoord op reacties en verdere betrokkenheid[bewerken]
Op 22 maart 2016 kregen NORA en Bureau Forum Standaardisatie officieel antwoord op de reviewcommentaren vanuit het EIA team, dat gaat over de ontwikkeling en doorontwikkeling EIRA. In een nieuwe release zijn een aantal commentaren direct meegenomen, zo is versie 1.0.0. uitgebracht in Open Group ArchiMate Exchange File Format.
In de Nederlandse reactie werden daarnaast een aantal zorgpunten geuit, die we op de agenda willen houden in de verdere ontwikkeling. EIA nodigt ons uit om dit te doen als lid van de werkgroep die in het op te zetten Change proces de verdere evolutie van de EIRA mede zal sturen. Hoe we dit het beste in kunnen vullen wordt de komende tijd bekeken.
EIRA versie 1.0.0 is gepubliceerd op 21 maart 2016. De ontvangen commentaren op 0.9.0 beta en de antwoorden hierop zijn gedocumenteerd in een verzameldocument, het (Engelstalige) antwoord op de Nederlandse reactie is hieronder integraal te lezen.
Integrale tekst aantwoord op Nederlandse reactie[bewerken]
Dear Nora team,
Thank you for your comments on the public release of the "European Interoperability Reference Architecture", version 0.9.0 beta, which was released on Joinup. It was also logged in a dedicated document, reflecting all comments from the public consultation. Some of the mentioned issues have been taken into account. For instance, the EIRA v1.0.0 will be released in the "Open Group ArchiMate Exchange File Format" and no longer in the Archi (the tool) proprietary format.
There are many other remarks for which we cannot provide an answer at the moment, they require further discussion. For example; you mention the explicit expression of the need of reference architecture and the link to the (missing) principles, the enforcement of agreements and the added value of the EIRA in relation to other architectures. These issues all fall in the realm of Governance and Architecture Vision, a topic that is under continuous discussions. Since we cannot given an appropriate answer to some of the valuable remarks you made, we would like to invite you to actively participate in the evolution of the EIRA, and join our Change (and Configuration) management process as member of the workgroup, a process in which we monitor and steer the evolution of the EIRA, based on evolutions, feedback from the community, etc.
We will send more information on the process shortly afterwards,
Finally, we would be happy to discuss with you any further remarks you might have on EIRA. The new version of EIRA v1.0.0 was released on 21.03.2015.
With kind regards, The EIA Team
Integrale tekst advies (Nederlands)[bewerken]
Belangrijke bevindingen en vraagstukken
1. Wij zijn verheugd over het initiatief om te komen tot een Europa-brede (referentie) architectuur. De ervaring leert dat de vele voorzieningen die in Europees verband tot stand komen een goede architectuur ontberen. Het is ook geen eenvoudige opgave om te komen tot een goede overkoepelende architectuur, die standaardisatie en noodzakelijke flexibiliteit in balans brengt. Vanuit Nederland willen we daarom graag nauw betrokken worden bij deze ontwikkeling. Vanuit onze rollen hebben we een breed netwerk in de relevante sectoren en kunnen we de betrokkenheid vanuit Nederland dan ook coördineren en organiseren.
2. In het document komt de noodzaak voor een Europese referentiearchitectuur onvoldoende tot uiting. We hebben moeite om de leidende gedachte te zien die ongetwijfeld schuil gaat achter een groot deel van het metamodel. De schrijvers hebben duidelijk energie gestoken in het verantwoorden van het doel en de doelgroep in de eerste drie hoofdstukken. De verbinding daarvan met het daadwerkelijke metamodel is ons echter niet duidelijk. Concrete voorbeelden, zoals uit het Eicart project, zouden het model kunnen verduidelijken. Zo begrijpen we dat het waardevol kan zijn om beleid te modelleren, maar betwijfelen of dat in ArchiMate-achtige constructie behoort.
Het is vanuit de lidstaten moeilijk om de visie van de Commissie als geheel op architectuur te doorgronden. Verschillende sectoren lijken nog te veel los van elkaar te werken, hetgeen op nationaal niveau grote interoperabiliteitsproblemen kan veroorzaken. Wil de EIRA een krachtig instrument worden, dan moet het uitademen dat het breed gedragen is binnen de Commissie en één visie vertegenwoordigt. In Nederland voelen we de noodzaak van zo’n visie, als we te lang vanuit de verschillende sectoren langs elkaar heen werken krijgen we er allemaal last van.
3. Ook op het gebied van publieke dienstverlening door de lidstaten is nog geen inzicht in waar we gemeenschappelijk kunnen optrekken, dan wel zelfstandig moeten opereren. De eerste stap daarvoor is inzicht in de huidige praktijk. Dat inzicht per land ontbreekt nu, maar zou toegevoegde waarde hebben om de bestaande “volwassenheid”, uniformiteit en verschillen van beschreven diensten duidelijker te maken. De kennismodellen en formats die landen hanteren voor hun (grensoverschrijdende) dienstverlening zouden input moeten zijn voor het ontwikkelen van een uniforme beschrijving van architectuurelementen. De EIRA geeft nu al wel een zeer gedetailleerde beschrijving van de elementen die bij publieke dienstverlening van belang zouden kunnen zijn, maar dit is nog te weinig verbonden met wat er in de praktijk al is ontwikkeld bij de diverse lidstaten. Lidstaten met een relatief hoge volwassenheid op dit gebied hebben hierin reeds aanzienlijke investeringen gedaan. Om draagvlak te krijgen, extra investeringen te voorkomen en opgedane kennis te benutten moet de EU die voorlopers identificeren en betrekken.
4. In Nederland onderkennen we de impact die overheidsafspraken kunnen hebben op organisaties die met verschillende overheidsonderdelen te maken hebben. De NORA is daarom het landelijke overlegplatform voor de sectorale architecturen, samen de NORA-familie genoemd. De NORA-familie maakt zo veel mogelijk dezelfde keuzes voor dit soort generieke zaken, ook over sectoren heen. De impact van EU-afspraken die afwijken van de nationale keuzes op het gebied van generieke zaken als authenticatie, gebruik van bouwstenen, standaarden enz is potentieel nog groter. We willen graag actief deelnemen in de EU om dit ook op EU-niveau hoog op de agenda te houden.
5. De toepassing van standaarden. In Nederland hebben we in de NORA-familie een samenhang aangebracht tussen de Nederlandse bouwstenen van de elektronische overheid en de bijbehorende standaarden voor gegevensuitwisseling, zoals de “pas toe of leg uit”-standaarden van Forum Standaardisatie. Deze koppeling lijkt in de EIRA ook goed te leggen bij bijvoorbeeld het gebruikte element “machine 2 machine interface”.
Aanvullende suggestie: Het zou goed zijn als op Europees niveau de standaarden die worden toegepast in de bestaande bouwstenen worden aangemeld voor de lijst met voorkeursstandaarden van het Multi Stakeholder Platform (MSP) en andersom: bij de ontwikkeling van een nieuw bouwsteen zou de bestaande MSP lijst met standaarden gecheckt moeten worden, voordat er keuzes worden gemaakt over de toepassing van standaarden (parallel aan de Nederlandse situatie met de lijst “pas toe of leg uit”-standaarden).
6. De EIRA heeft een sterke focus op de mechanismen en bouwblokken voor het uitwisselen van gegevens c.q. van informatie binnen Europa (de HOE-vraag). Uit de EIRA wordt echter niet duidelijk hoe de aansluiting ervan is op de bestaande infrastructuur van de landen. Hoe bijvoorbeeld wordt de EIRA gezien ten opzichte van de Gemeenschappelijk Digitale Infrastructuur (GDI) van Nederland? Kan worden aangegeven wat de EIRA aan de GDI toevoegt?
7. In aanvulling daarop zouden we graag zien dat -met hoge prioriteit- aandacht wordt gegeven aan de reden waarom die gegevens- en informatie-uitwisseling nodig is, te weten de feitelijke grensoverschrijdende diensten: - welke concrete diensten zijn dat? - waar zijn de beschrijvingen en de gemaakte afspraken over de kwaliteit ervan te vinden? - welke knelpunten spelen daarbij die te maken hebben met de verschillen vanuit de betrokken landen?
8. Dit brengt ons op het punt van een fundamentele vraag over Referentie Architecturen. In Nederland hebben we afgelopen jaren veel geïnvesteerd om het werken met en onder architectuur tot wasdom te brengen. We zetten daarbij de “voorbeeld blauwdrukken” om naar concrete handvatten voor architecten en ontwerpers in de vorm van inzichten in de bestaande situatie (diensten en infrastructuur) en principes om ze te leiden naar verschillende oplossingsmogelijkheden en inzicht in de impact daarvan. Deze beweging van referentie-architectuur naar architectuur zie je in de hele NORA-familie ontstaan. We zien graag dat de EIRA zich ontwikkelt naar een architectuur die aansluit op de architecturen van de aangesloten landen.
We menen ook dat het nu belangrijker is om ervaring op te doen met echte toepassingen van de EIRA en die voorlopig niet theoretisch verder te volmaken. Met “echte toepassingen” bedoelen we volledige uitwerkingen van ABBs en SBBs volgens EIRA en geen oppervlakkige demonstraties of proeftoepassingen. Alleen in zulke echte toepassingen gaat de toegevoegde waarde (de “expected benefits”) bij de diverse sectoren blijken en kan je ontdekken wat ontbreekt of anders moet. Ons advies is dat het ISA / EIRA-programma dit proactief oppakt i.p.v. af te wachten welke feedback er gaat komen.
9. In aanvulling daarop zien we graag dat duidelijk wordt hoe de EIRA aansluit op de wereldwijde architectuur voor publieke diensten. Elk land moet immers in staat zijn publieke diensten te leveren aan zowel Europese landen als aan niet-Europese landen. Internationale (digitale) samenwerking mag dus niet beperkt zijn tot Europa, waarbij een land verschillende standaarden zou moeten hanteren in communicatie met EU-partners, de VN, Azië en de VS. Uniformering moet stimuleren dat standaarden gelijk worden getrokken.
10. Hoewel we het toejuichen dat het model in “.archi” wordt gepubliceerd, geschikt voor het open source instrument “Archi”, raden we aan om in plaats daarvan, “The Open Group ArchiMate exchange format” te gebruiken. Deze laatste is een open standaard, die ook ingelezen kan worden in Archi. Daarnaast zijn er algemenere standaarden voor het publiceren van metamodellen, zoals de Web Ontology Language (OWL).
11. In de EIRA hebben we enkele onderdelen niet kunnen terugvinden, die in de NORA van groot praktisch nut zijn gebleken. Het meeste missen we principes (richtinggevende uitspraken). Principes zijn in NORA en haar dochters belangrijke elementen: ze zorgen voor een goede beschrijving van de relatie tussen organisatie-architectuur en techniek. “Organisational Enablers” kunnen volgens hun definitie in EIRA, principes bevatten maar worden in het model weinig toegelicht. Ook het verband tussen Organisational Enablers en Business rules is ons niet duidelijk. Ze zijn de enige bron voor “Business rules.” Business rules lijken in steeds meer uitvoeringsprocessen een bron te zijn voor modelleren van systemen, maar in EIRA zijn ze slechts van invloed op “Business information”, niet op processen. Procesmodellering lijkt zo buiten de scope van EIRA te vallen, zonder dat ons duidelijk wordt waarom.
12. Als laatste hebben we nog de vraag hoe handhaving plaatsvindt van afspraken die worden gemaakt vanuit architectuur en standaarden. Zo zijn in Europa een aantal standaarden afgesproken (bijv. UMF) die vervolgens niet altijd gehanteerd worden en waarop geen (repressief) toezicht wordt gehouden.
Integrale tekst advies (Engelse vertaling)[bewerken]
Review findings and remaining questions
1. We are very happy with the initiative to develop a (reference) architecture on the EU-level. In our experience, many IT-solutions that are created on an EU level still lack, and could benefit from, a good underlying architecture. Developing a good umbrella architecture with the right balance between standardisation and the necessary flexibility is indeed a difficult challenge. We want The Netherlands to be closely involved in this development. Our own respective roles at NORA and BSF come with large and varied networks within the relevant Dutch sectors, which enable us to coordinate and organize such close Dutch participation.
2. The document, as is, fails to properly express the necessity of a European reference architecture. We struggle to discern the rationale guiding a substantial part of the metamodel. In the first three chapters, the authors have obviously devoted much energy into defining the goal and the target audience for the EIRA. The relationship between these chapters and the actual metamodel, however, is unclear. The model could be clarified with practical examples, like those in the Eicart project. Another question is whether modelling of policy, although valuable on its own, is served by using ArchiMate-like constructs. Seen from the perspective of the member states, it is difficult to discern the joined vision on architecture of the European Committee as a whole. Different sectors seem to operate mainly on their own, which can lead to major interoperability issues on the national level. If we want the EIRA to become a powerful tool, it should project widespread support in the European Committee and represent a clear, joint vision on architecture. The need for such a vision is deeply felt in the Netherlands: if the different sectors keep working in a vacuum, we will all have to pay for the resulting lack of interoperability.
3. We also need more vision on the subject of public services by the member states: where do we benefit from cooperation and where are we better off operating separately. The first step towards such a vision is an overview of current practices. There is considerable added value to be gained from an overview per country of the current services, their ‘maturity,’ uniformity and major differences. The knowledge models and formats that countries use to describe their own (cross-border) services should be a major input for developing a uniform description method for architectural elements. As is, the EIRA provides a very detailed description of elements that could be of importance for public services, but this description needs a stronger connection with the current practice in the different member states. Countries with a relatively high maturity in this area have already made considerable investments. The European Union should identify such front runners and involve them in the process. This ensures a widespread support, prevents unnecessary double investments and puts experience and expertise to good use.
4. In The Netherlands, we acknowledge the impact government choices in architecture can have on organisations that have relations with several government agencies. NORA serves as a national platform, where architectures of different domains (such as education, healthcare et cetera) come together to discuss generic architectural elements. Together, these architectures form the NORA-family. Members of the NORA-family strive to align IT-choices on generic elements, across sectors and domains. The potential impact on organisations is even greater when EU choices for generic elements and solutions such as authentication, building blocks, standards et cetera differ from the national choices. We therefore want to participate actively in the EU process to keep this concern high on the agenda.
5. Applying standards. The NORA-family relates the Dutch solution building blocks of the electronic government to the applicable standards for information exchange, such as the ‘comply-or-explain’ list of the Standardisation Forum Office . This relationship can be easily demonstrated in the EIRA as well, for instance at the element “machine 2 machine interface.”
Additional suggestion: At the European level, it would be good practice to register the standards that apply to existing (solution) building blocks with the Multi Stakeholder Platform on ICT Standardisation (MSP) and vice versa: developers of new European building blocks should check the list of existing MSP standards before making a decision on the standards they do or do not apply (parallel to the ‘comply-or-explain’ list in The Netherlands.)
6. EIRA has a strong focus on the mechanisms and building blocks for the exchange of data / information in Europe (the ‘HOW?’ question). However, the document does not explain how these mechanisms would connect to the existing infrastructures of the member states. What, for example, is the relationship between EIRA and the Dutch Gemeenschappelijke Digitale Infrastructuur (GDI, Common Digital Infrastructure)? Could you clarify the added value of EIRA in relation to the GDI? 7. We would like to see a shift in attention from the HOW of data and information exchange to the reason WHY we need them in the first place, that is to the actual cross border services. A number of questions has high priority:
- Which actual cross border services exist?
- Where can the descriptions of these services be found and what commitments are made for quality control?
- What bottlenecks exist regarding these services, stemming from differences in the member states concerned?
8. This brings us to a fundamental question regarding Reference Architectures. These past few years, we - in the Netherlands - have strongly invested in bringing ‘working with and within architecture’ to maturity. In this effort, we transform ‘template blueprints’ into practical tools for architects and designers. Tools such as overviews of the current situation (services and infrastructure) and principles to guide them to various possible solutions and their impact. We see this movement away from reference architecture towards architecture in the entire NORA-family. We would like to see the EIRA develop towards an architecture, that connects to the architectures of the member states.
Furthermore, we believe it more important at this point to gain experience with the EIRA through real applications, than to try to perfect the theoretical framework. By ‘real applications,’ we mean complete elaborations of ABBs and SBBs according to EIRA, not just superficial demonstrations or trials. The ‘expected benefits’ in the different sectors will only show in such real-world applications and they are the only way to discover flaws and omissions. Our advice to the ISA/EIRA Programmes is to be proactive in stimulating and realising such real applications, rather than to wait for further feedback before seeking application.
9. We also like to see some clarification of how the EIRA connects to the global architecture for public services. After all, each member state should be able to provide certain services to EU and non-EU countries alike. International (digital) cooperation cannot be limited to the EU, or countries would have to apply different standards to communication with EU-partners, the United Nations, Asia and the United States. ISA should stimulate international harmonisation of standards.
10. Although we commend publication of the model in the .archi format, suitable for the open source tool “Archi,” we recommend exchanging the .archi for “The Open Group ArchiMate Exchange format ”. This is an open standard, which also can be imported in Archi. You could also consider adopting commonly used standards to publish metamodels, such as the Web Ontology Language.
11. A number of elements – with great practical value in the NORA – are absent in the EIRA. The most important of these are the Principles (guiding statements). Principles are important elements in the NORA and the NORA-family: they provide a good description of the relationship between organisational architecture and technology. In the EIRA definition of ‘Organisational Enablers’ it is stated that these could contain principles, but their use in the model requires further clarification.
The relationship between Organisational Enablers and Business Rules remains unclear to us as well. Organisational Enablers appear the sole source for Business Rules. More and more processes tend to use Business Rules as a source for modelling their systems, yet in the EIRA Business Rules only influence ‘Business Information,’ not processes. Modelling processes therefore seems to be placed out of scope of EIRA, without a clear indication why this would be the case.
12. As a final question, we wonder how the agreements on architecture and standards will be enforced. A number of European standards, such as UMF, are not applied in practice, nor are they under (strict) auditing.