NORA Gebruikersraad/2016-06-14

Uit NORA Online
< NORA Gebruikersraad
Naar navigatie springen Naar zoeken springen


Bijeenkomst van NORA Gebruikersraad op dinsdag 14 juni 2016, 13.00-17.00, locatie: ICTU, Wilhelmina van Pruisenweg 104, 2595 AN DEN HAAG. .

Opening vergadering & mededelingen[bewerken]

Governance NORA / BZK[bewerken]

De NORA valt binnen het beleidsdomein van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties. BZK, in het bijzonder de directie Informatiesamenleving en Overheid, is de opdrachtgever voor de NORA als programma en tevens de linking pin naar de Regieraad Interconnectiviteit. Door BZK is in de Regieraad Interconnectiviteit de vraag gesteld welke kandidaten beschikbaar zijn voor het voorzitterschap van de Gebruikersraad. Hierop is Saco Bekius voorgedragen. In de novemberbijeenkomst zal het onderwerp ‘governance’, als ook de verbinding tussen NORA en haar dochters worden geagendeerd.

NORA Gebruikersraad/2016-09-14 is bij Geonovum, waarschijnlijk in Utrecht of Amersfoort[bewerken]

Jeroen Baltussen werkt aan het actualiseren en uitbreiden van het onderwerp Geo in de NORA-wiki, met een overzicht van de relevante standaarden en bouwstenen, beleidskaders en antwoorden op veelgestelde vragen. Dit zal het Dossier Geo-informatie (PDF, 5,03 MB) in zijn geheel vervangen.

Actiepunt 2016-06/1: ALLEN: geven door welke vragen of voorbeelden uit de praktijk ze graag besproken willen zien tijdens de Gebruikersraad over Geo​​

Het verslag van deze bijeenkomst staat op Wetgeving in verbinding/2016-05-27. Het was een goede bijeenkomst met zo'n 60 aanwezigen. Linked Data krijgt veel aandacht vanuit deze bijeenkomsten. Vanuit de NORA is contact gelegd met het Platform Linked Data Nederland (PLDN) met de intentie om samen te gaan werken om linked data en de gegevens van de overheid optimaal met elkaar te verbinden.

De afstemming van NORA en Linked Data met het Gegevenslandschap van de Nederlandse samenleving (Stelsel van Overheidsgegevens) is blijvend nodig.

Bureau Forum Standaardisatie en het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties coördineren samen de Nederlandse inbreng op het Europees Interoperabiliteitsframework (zie Interoperability Solutions for Public Administrations (ISA). NORA Beheer heeft hiervoor gegevens aangeleverd. Wie individueel of namens de eigen organisatie nog wil reageren kan dat via de link hierboven. (reageren is nog mogelijk tot en met 29 juni 2016).

Het blijkt dat voor de EU-lidstaten een hoge score voor digitale diensten gelijk op gaat met een hoge score op EIS/EIF.Nederland scoort hoog op beide en wellicht is het beter om de EIS/EIF de eerste tijd niet verder door te ontwikkelen, maar juist de achterblijvende landen de kans bieden om op hetzelfde niveau te komen.

Er zijn geen grote wijzigingen op de EIS/EIF sinds de vorige consultatie. Niet alle aangedragen wijzigingen zijn overgenomen, het is niet duidelijk waarom niet. Het zou kunnen dat de focus om de zwakkere broeders mee te krijgen ook minder aandacht voor de voorhoede betekent, maar dat is niet evident.

NORA Beheer heeft nu een reactie gegeven namens de NORA Familie. Dat kost echter wel veel tijd en aandacht. Het zou goed zijn om een inner circle van belangstellenden te hebben die mee willen denken over EIS/EIF en die in voorkomende gevallen hun expertise en visie kunnen delen.

Actiepunt 2016-06/2: Geïnteresseerden in EIS EIF: melden zich bij NORA Beheer​​
  • Verslag. Er zijn geen opmerkingen over het verslag van de vorige keer en dat is daarmee goedgekeurd.

Voorstel Afgeleide Principes Revisited[bewerken]

Robert van Wessel (ICTU) licht het voorstel (PDF, 544 kB) toe om de Afgeleide Principes opnieuw te bezien met het oog op actualisatie, consistentie en het aanscherpen van formuleringen.

Er is brede steun voor het aanpakken van de AP's, maar er is wel twijfel over de beste procedure. Gaan we de AP’s apart of in samenhang aanpakken? Vooralsnog is gekozen om de prioritering per individueel AP uit te vragen, zodat we de opmerkingen per AP kunnen verwerken. Op basis van alle opmerkingen kunnen we nog clusteren bij de herzieningssessie, op bestaande of nieuw gebleken clusters. Dan moeten we die opmerkingen dus wel plaatsen bij het invullen van de prioriteitenlijsten. Een vraag is nog of we de eenduidigheid en leesbaarheid van AP’s beter kunnen loskoppelen van de inhoudelijke discussie? Het lijkt efficiënter om alle aspecten gelijk mee te nemen in het aanpakken van een AP, dus dat zal onze eerste aanpak worden. NB. Tekstuele aanpassingen die geen inhoudelijke wijzigingen inhouden vallen binnen het mandaat van NORA Beheer en kunnen altijd nog worden doorgevoerd. Alleen inhoudelijke wijzigingen komen dan aan bod in de RFC's.

De eerste sessie is gepland op woensdag 6 juli, van 13.30 – 15.30 uur bij ICTU, zie Afgeleide Principes Revisited voor opgave en de huidige prioriteitenlijst.

Wijzigingsvoorstel AP 35-40: Beveiliging[bewerken]

De laatste zes Afgeleide principes hebben voornamelijk betrekking op Beveiliging. Vanuit de Nationale Werkgroep Beveiliging bestaat al geruime tijd de wens deze principes te wijzigen en aan te scherpen. Jaap van der Veen (voorzitter Werkgroep) licht de redenen hiervoor toe (PDF, 1,3 MB). Het RFC (PDF, 816 kB) zelf zal in de Gebruikersraad van 14 september ter besluitvorming op de agenda staan.

Jaap zet de huidige principes af tegen het functiemodel. Hieruit blijken een aantal witte vlekken zoals logging. Als je Archimate plot op de NORA Basis- en Afgeleide Principes (lees hierbij een basisprincipe als een doel) dan blijken de Afgeleide Principes over beveiliging niet altijd op het juiste niveau geformuleerd te zijn. In het RFC zijn de hernieuwde Afgeleide Principes wel allemaal op hetzelfde niveau en hangen alle onderdelen van het thema Beveiliging in één hiërarchisch model.

Uit de zaal is bijval voor de hiërarchische aanpak van deze Afgeleide Principes. Dat zouden we eigenlijk bij alle AP's moeten doen. Deze insteek nemen we dan ook mee in de Afgeleide Principes Revisited.

Privacy is deels verwerkt in dit RFC en deels niet: De onderdelen die raken aan privacy en aan security of continuïteit wel, de insteek is om deze drie integraal mee te nemen in je ontwerp. Er zijn echter ook nog losse aspecten van privacy, zoals doelbinding, die nog apart moeten worden benoemd en aangepakt.

Als we deze wijziging doorvoeren, zal de toepasbaarheid van de beveiligingsnormen in de praktijk makkelijker worden en dus meer effect krijgen.

Het is belangrijk dat de NORA dochters goed beoordelen wat deze wijziging voor hun eigen domein betekent.

Actiepunt 2016-06/3: Alle architecturen van de NORA Familie: gaan na wat de impact van het RFC Beveiliging gaat zijn voor de eigen afspraken en brengen dit voor of in de vergadering van 1 september in.​​

Informatiebeveiliging raakt in ieder geval aan de informatiehuishouding en Duurzame Toegankelijkheid. Gijsbert Kruithof zal de raakvlakken samen met Jaap bekijken.

Impact recente kabinetsuitspraken voor uitspraken over open source in NORA?[bewerken]

Er is al een tijd ruis over open source en het beleid hierover. Dat is mede veroorzaakt door het samen nemen van open standaarden en open source in veel communicatie, terwijl er nooit sprake is geweest van een gelijk beleid voor beide onderwerpen. Het in de Tweede Kamer aan de orde gesteld beleid 'altijd open source' heeft nooit bestaan. Wel is voor de Rijksdienst geformuleerd dat bij gelijke geschiktheid de voorkeur werd gegeven aan open source.

Met het benoemen van dit misverstand is echter nog geen volledige helderheid geschapen, zoals ook blijkt uit de vraag die binnen is gekomen bij NORA Beheer. Bij de waterschappen en de gemeenten leven veel van dit soort zaken ook. We moeten dit daarom vanuit de dochters in één keer goed afhandelen.

Harry Wever (EAR) neemt het voortouw om dit onderwerp te verhelderen en te bepalen of er impact is voor de NORA en Paul de Frankrijker (Waterschappen) en Theo Peters (Gemeenten) zullen het voorstel aanvullen. Robert van Wessel (ICTU) ondersteunt dit vanuit NORA Beheer. Wie mee wil denken of aan kan geven hoe het in de eigen afspraken is geregeld kan contact opnemen met Harry, rechtstreeks of via nora@ictu.nl.

Actiepunt 2016-06/4: NORA Beheer: stuurt een mail rond aan de NORA Familie ter herinnering hieraan (input open source).​​

Overheid Mobility Overleg (OMO)[bewerken]

Het Overheid Mobility Overleg is aan de laatste sessie toe en het is tijd de belangrijkste conclusies te delen met de bredere NORA Community. Herriet Heersink (NORA) laat de concept-presentatie zien voor het laatste OMO-overleg. Deze presentatie wordt hier niet gedeeld omdat het OMO zich eerst zelf uit zal moeten spreken over de lijn die er in wordt uitgezet. De leden van de Gebruikersraad zijn van harte uitgenodigd voor de slotbijeenkomst van het OMO.

De komende periode zal de impact op de NORA concreet gemaakt worden. Een deel hiervan kan mee in de Afgeleide Principes Revisited, waar nodig kunnen ook losse RFC's worden uitgewerkt en voorgelegd. Sowieso zal het slotdocument van OMO gedeeld worden met de NORA Gebruikersraad. Hieronder staan opmerkingen, vragen en extra toelichting die gegeven is naar aanleiding van de presentatie.

Mobility heeft een grote impact op de digitale dienstverlening. Een aspect is de verdere integratie met de business. Dit stelt andere eisen aan ontwerp en ontwikkeling. Zo is KPN gestopt met outsourcing naar India om de lijntjes zo kort mogelijk te maken.

We moeten LEREN werken met Mobile, leren snappen waar we mee bezig zijn. Dat is een kwestie van oefenen en experimenteren. Dat kan overigens steeds sneller: de tijdspaden voor trial en error worden zichtbaar korter in een Mobile samenleving.

Het is niet meer te vermijden dat publiek & privaat gecombineerd worden. Het is dus zaak te zorgen dat het goed gebeurt.

Je kunt voelen dat Mobility spanning veroorzaakt, men worstelt er mee. Het is ook geen vervanging, maar dubbel werk: je moet de andere infrastructuren ook blijven onderhouden.

De impact van Mobility in de NORA zit hem vaak in formuleringen die scherper moeten. De Basisprincipes staan bijvoorbeeld conceptueel nog overeind, maar de tekst voelt verouderd aan.

Een de wens die geopperd werd is een Overheids Appstore. De behoefte is om transparantie aan de burger/gebruiker te geven: wat ik daar vandaan haal is betrouwbaar. Daarnaast wordt het zo gemakkelijker om te zien of er al een vergelijkbare oplossing bestaat die je kunt hergebruiken.

Opmerkingen: Het ministerie van BZk denkt er juist over om te stoppen met de eigen appstore: er zijn in de praktijk weinig aanbieders die er gebruik van willen maken. Misschien is het belangrijker te focussen op de betrouwbaarheid van de data die de apps gebruiken. Vanuit Digitaal Erfgoed is hier ervaring mee. De betrouwbaarheid van de data wisselt, maar als je die betrouwbaarheid goed aangeeft kun je de data vervolgens op welke manier dan ook laten ontsluiten. De achterkant is het belangrijkste, de rules et cetera. De voorkant kun je los laten. Misschien is er dus eerder behoefte aan een API, dan een APP-store. Of een overheidsbrede datastore, die ook de betrouwbaarheid van de data aangeeft.

Als je kijkt naar feedback zoals dat nu in de NORA staat dan is die nog niet op Mobility gericht. Doe je dat wel, dan is verwachtingsmanagement belangrijk: de overheid is een monopolist, die anders met feedback en gebruikerstevredenheid kan en hoort om te gaan dan een marktpartij. We zullen niet altijd iets doen met feedback, zelfs als die massaal en eenduidig is.

Naast een impact op de bestaande Basisprincipes staan in de presentatie ook een aantal nieuwe elementen die nog niet aan bod komen. Dat zijn niet per se aanzetten tot principes, maar kunnen misschien ook op een andere manier worden opgenomen of opgelost.

Een daarvan is de vraag of de ontvanger of gebruiker zelf niet ook verantwoordelijkheid draagt: bewustzijn bij mensen hoe je verantwoord om gaat met informatie is essentieel omdat zaken helemaal veilig maken niet mogelijk is. Opmerking: dit kan geen NORA-principe zijn, omdat het buiten de invloedssfeer van overheidspartijen ligt. Maar: we stoppen wel veel geld in awareness.

Opmerking: Er is een trend dat organisaties segmenteren naar kerntaken. Misschien moet de overheid alleen de data slim openstellen en voor de rest de markt zijn gang laten gaan. De kerndoelen van de overheid vormen de basis voor architectuur - die moeten misschien opnieuw worden bepaald: waar zijn wij van? de rest moet je dan loslaten.

Open data kan in de NORA nog explicieter worden benoemd en uitgewerkt. Daarnaast zijn ook lang niet alle begrippen in de NORA helder gedefinieerd en kunnen bestaande definities aangescherpt worden in de context van Mobility. NORA zet in op gezamenlijk gebruik en hergebruik van standaardoplossingen, dat zou bij mobiele toepassingen ook expliciet gestimuleerd kunnen worden.

Opmerking: de presentatie stelot dat Mobility zorgt dat veranderingen 'veel sneller gaan dan we denken.' Voor de private sector lijkt dat ook te kloppen. Voor de overheid staan echter vragen als 'mag dat?' 'wat kost het' en 'wie moet het betalen' snelle veranderingen doorgaans in de weg. Als het niet mag dan doen we het niet, dus wetgeving kan belemmerend werken. Een vraag die je vanuit het Overheid Mobility Overleg dan ook zou moeten opwerpen is: Wat zijn de ambities van de overheid?

Conclusies en vervolgacties uit enquête NORA Familie[bewerken]

Jan van Dijk (NORA) en Joris Dirks (NORA) presenteren (PDF, 1,17 MB) de belangrijkste conclusies van de enquête NORA Familie (PDF, 1,1 MB) en de vertaling hiervan in plannen voor de komende periode.

Een tweetal zaken kwam vaak terug in gesprekken van Jan van Dijk met de leden van de Gebruikersraad:

  1. Hoe zorgen we er voor dat onze architectuur in een wiki ontsloten wordt? En hoe koppelen we die wiki dan vervolgens aan de NORA-wiki?
  2. Hoe borgen we dat op ons eigen terrein de architectuur ook daadwerkelijk wordt gebruikt? Hoe laat je het bij bestuurders landen?

Vraag bij de presentatie: Een deel van de 'dochters' gebruikt de NORA op dit moment niet, of is nog gebaseerd op oudere versies van de NORA. Hoe komt dat? En kunnen dit wel 'dochters' genoemd worden? Antwoord: Niet alle architecturen uit de NORA Familie zijn klassieke dochters: een aantal is even oud als NORA of ontstaan uit andere initiatieven. Niet alle architecturen zijn bovendien even actief of dynamisch: een aantal heeft al enkele jaren geen nieuwe versie gepubliceerd. Architecturen die zijn opgesteld zonder de NORA zijn van harte welkom om later alsnog toenadering te zoeken. Wijzigingen zullen bovendien altijd gebaseerd zijn op de op dat moment geldende versie van NORA. De focus op het faciliteren van overerving in het Jaarplan 2016 is juist bedoeld om architecturen te helpen steeds de meest actuele kennis en afspraken toe te passen.

Joris Dirks ondersteunt familieleden bij het praktisch aansluiten op NORA. Geïnteresseerde dochters kunnen van NORA beheer hulp krijgen bij het inventariseren welke elementen uit NORA kunnen worden gebruikt in de eigen architectuur. Daarnaast helpt hij een begin maken met de technische koppeling van NORA naar de eigen wiki of andere architectuurrepository. Ten slotte wil NORA beheer de informatie uit de NORA wiki zo aanbieden dat dochters het goed kunnen hergebruiken.

Om leden van de gebruikersraad een duidelijk beeld te geven van wat ze van NORA kunnen gebruiken en hoe ze dat in gang kunnen zetten, organiseert NORA beheer twee bijeenkomsten. Bij de eerste bijeenkomst zal in anderhalf uur uitgelegd worden hoe overerving werkt en wat de voordelen zijn. Bij de tweede bijeenkomst wordt in een dagdeel intensiever gewerkt zodat deelnemers aan het eind van de dag werkplan voor overerving kunnen maken.

NORA-advies aansluiting NL op CEF[bewerken]

Menno Gmelig Meijling (ICTU), Marijke Salters (Logius) en Hans Sinnige (RINIS) geven een toelichting (PDF, 1,53 MB) op een pilot waarmee een aansluiting vanuit Nederland naar de Europese ICT-infrastructuur wordt gerealiseerd. Het ontwerp is gebaseerd op het Vijflaagsmodel en conform ArchiMate en gerelateerd aan zowel de NORA als de European Interoperability Reference Architecture (EIRA). De eerste pilot heeft drie deelnemers, maar kan uitgroeien tot een generieke voorziening voor Nederland in verbinding met Europa. In het ontwerp wordt gebruik gemaakt van de Nederlandse standaard Digikoppeling en de Europese bouwsteen eDelivery. Het is de bedoeling dat de Europese aansluiting uiteindelijk deel gaat uitmaken van de Generieke Digitale Infrastructuur (GDI). Tijdens de presentatie is ruimte voor vragen en discussie. Bijlage Een brug naar Europa (PDF, 217 kB).

De in dit stuk en de presentatie genoemde Programma's en actoren EU staan sinds kort ook in de NORA-wiki binnen het thema Architectuur internationaal.

Opmerkingen en vragen bij de presentatie:

Er zijn nu al tenminste 4 'bruggen' naar Europa. Hoe kan je naar 1 brug gaan? Dat is een van de vragen die nog open staan en een van de redenen waarom we de leden van de Gebruikersraad vragen aan te geven wat de impact in het eigen domein zou zijn.

Binnen e-SENS is een aantal Large Scale Pilots uitgevoerd, telkens binnen een bepaald domein. De voorzieningen uit deze pilots zijn voor een deel breder inzetbaar. Deze worden de komende jaren uitgewerkt tot generieke bouwstenen. eDelivery is daar één van.

Een eDelivery Gateway geeft een technische vertaalslag van protocol tot protocol. Is er ook voorzien in een letterlijke vertaling van de boodschap? Nee, dat valt buiten de scope van eDelivery. eDelivery speelt een vergelijkbare rol als Digikoppeling in Nederland, andere bouwstenen kunnen hier weer op aansluiten. Op het gebied van vertaling zijn MT@EC en eTranslation internationale bouwstenen die wellicht relevant zijn.

Waarom zou je op dit moment kiezen voor het uitwisselen van transactionele documenten? Zou voor een deel van de uitgewisselde informatie een cloud-deel oplossing niet beter zijn? De DG's DIGIT en CONNECT maken geld vrij voor het verder ontwikkelen van dit bouwblok. Na de pilot zal een evaluatie moeten volgen, waarbij ook dit soort vragen (wat is impact, is dit het juiste bouwblok, hoe past het in het bestaande landschap) aan bod moet komen.

Voor de pilot is bewust gekozen voor drie projecten die veel van elkaar verschillen. Zo heeft TenderNed al veel ervaring met de andere internationale bouwstenen. Door de nieuwe gateway naast de bestaande diensten op te zetten kun je snel controleren of alles naar behoren werkt en zo niet, waar de oorzaak ligt.

eDelivery werkt volgens het Four Corners model. Het bericht komt vanuit het systeem en protocol van de zender (corner 1) binnen bij de eDelivery gateway (corner 2). eDelivery verzendt het bericht naar de gateway in het ontvangende land (corner 3) en daarvandaan naar de ontvanger (corner 4). Dat wil zeggen dat er twee keer een vertaalslag nodig is: van de verzender naar de eDelivery ingang en van de eDelivery uitgang naar het protocol van de ontvanger. In het voorbeeld in de presentatie gaat een bericht van Nederland naar Italië. In Nederland gaat dit volgens de Digikoppeling standaarden, met een vertaalslag naar eDelivery. De Nederlandse eDelivery gateway brengt het bericht bij de Italiaanse, waar de Italianen het vervolgens vertalen naar SNTP.

De wat vreemde situatie is dat de vertaalslag in Nederland van de ene configuratie van EBMS naar de andere is. EBMS 2.0 en 3.0 verschillen erg, waardoor mapping nodig is. In deze pilot wordt overigens alleen de slag vanuit EBMS meegenomen, niet vanuit WUS.

Waarom levert de EU geen module die de slag tussen corners 2 en 3 regelt?

Kunnen we het niet gezamenlijk in Open Source maken en dan in heel EU hergebruiken?

Waarom leren we het de markt niet, in plaats van het zelf te moeten ontwikkelen?

Waarom maken Digikoppeling en eDelivery überhaupt gebruik van twee verschillende versies van EBMS?

Antwoord: dit zijn allemaal goede vragen, een deel van die verwondering speelt ook bij de direct betrokkenen van de pilot.

Connecting Europe Facility (CEF) publiceert calls waaraan iedereen mee mag doen. Zo kun je financiering krijgen voor experimenten, in de vorm van pilotbudgetten met weinig administratie achteraf. De financiering voor deze pilot loopt tot 31-6-2017. Technisch gesproken zijn we misschien iets eerder klaar, maar je wilt ook tijd nemen voor de aansluitinformatie en de communicatie daarover. Het resultaat van de pilot is nadrukkelijk alleen een pilot: er wordt geen live-systeem opgeleverd waar organisaties op aan kunnen sluiten. Zo kan de pilot de technische kant uittesten los van governanceaspecten en andere vraagstukken.

Wij beproeven nu vanuit Nederland eDelivery en dat zal ongetwijfeld ook in andere landen gebeuren. Wat doen we / kunnen we doen als we fouten tegenkomen die moeten worden opgelost op EU-niveau? Antwoord: Je hebt een stevige vuist en één stem richting Europa nodig als je dergelijke wijzigingen doorgevoerd wilt krijgen. Op basis van de pilot kunnen we ook werken aan die gemeenschappelijke vuist en stem.

eDelivery lijkt erg op EESSI. Kunnen we dit niet samenvoegen om tot één goed werkende bouwsteen te komen? Antwoord: Er is wel degelijk communicatie tussen eDelivery en EESSI. Bij beide zijn ook leveranciers et cetera al in het voortraject betrokken.

Is eDelivery een voorwaarde voor het uitvoeren van de eIDAS-verordening? Wanneer checken van de identiteit via eDelivery moet gebeuren en de pilot pas half 2017 klaar is kunnen we dan wel in 2017 voldoen aan EIDAS? Antwoord: eDelivery is hier niet voorwaardelijk, de check op het eID gaat niet via deze transportlaag.

Vraag aan de leden van de Gebruikersraad: wat is de impact van een eDelivery pilot en welke architectuur is nodig om van pilot naar generieke voorziening te gaan?

Reacties:

  • De ontwikkeling in de wetenschappelijke wereld (o.a. bio-informatica, relevant voor RIVM) is om bestanden niet meer via transactionele systemen te verwerken vanwege de grootte. Goed regelen van transacties alleen kan dus niet afdoende zijn voor grensoverschrijdende informatieuitwisseling.

Net als bij EESSI is er het risico om in te zetten op de techniek van het verleden (asynchrone informatieuitwisseling), terwijl de trend is om rechtstreeks met elkaar mee te kunnen kijken. De twee als losse bouwblokken doorontwikkelen lijkt niet kansrijk.

  • Kijk eens naar Digikoppeling en de discussies aan de Digikoppeling-tafels. Er is een grote overlap in het type vragen, zorgen en issues met waar we het nu over hebben.
  • Wat moet je intern nog doen om hier gebruik van te maken? Dat bepaalt voor een groot deeel de impact. Als je zelf veel moet doen dan wordt het automatisch minder aantrekkelijk om er gebruik van te maken. Waar zit precies de verandering als je al gebruik maakt van Digikoppeling, moet er dan nog een extra sticker opd econtainer voor buitenlands gebruik? Verandert de Digikoppeling als geheel misschien? Dat zou impact hebben voor sectorvoorzieningen als Edukoppeling.
  • Wanneer er extra slagen te maken zijn zou je dit ook als sector kunnen regelen, met een sectorspecifieke semantiek, zodat je het als organisaties niet allemaal zelf hoeft te doen.
  • Als je dit uitvoert met EU-geld zou de nadruk moeten liggen op de vraag wat het toevoegt wat we nu nog niet kunnen en waar we dus iets nieuws voor nodig hebben. Die vraag zou je ook bij de Digicommissaris neer moeten leggen, uiteindelijk moet het in het GDI-landschap passen.
  • Bij EESSI was de techniek niet zozeer het struikelpunt, maar de vraag hoe je aansluiting blijft houden - een business & beheer issue. Ook hier moet je kijken waar je verandermogelijkheden en beperkingen krijgt voor je enterprise architectuur door gebruikmaking van eDelivery. Op EU-niveau wordt er zocht naar een duurzaam beheersmodel van de ontwikkelde bouwblokken, bijvoorbeeld bij eu-LISA.

In hoeverre ga je lessen trekken uit de use cases, o.a. voor de impact op de business kant?

Antwoord: dit valt buiten de scope van de pilot zelf. Wel is bewust gekozen voor drie pilotpartners waar de business op andere niveaus is aangehaakt. Deel van de test van de gateway zou ook moeten liggen bij de business: wat heb je nodig in de productiesituatie? Dit is vooral relevant na de pilot, bij de evaluatie en de keuze of er een generieke voorziening van gemaakt wordt. De impactbepaling die we nu aan de Gebruikersraad vragen is wel gericht op die (post-pilot) fase, dus de vraag is nadrukkelijk om hierbij de business te betrekken.

Vraag aan de leden van de Gebruikersraad: Wat betekent dit vanuit NORA bekeken? GEMMA: NORA moet helpen in ketens tussen overheidslagen. eDelivery past dus heel goed in of bij de NORA. Is het genoeg om hier de NORA toe te passen? Nee, je moet het gesprek actief aangaan omdat er goed een wisselwerking zou kunnen ontstaan, die ook de NORA aanpast. De evaluatie van de pilot zou dus ook iets moeten zeggen over wat er wel en niet in NORA wordt afgehecht.

ROSA: Ja, de uitwisseling naar buiten toe is ook een keten en hoort dus in NORA thuis. De verbindingen met de Dienstenrichtlijn en de bestaande bouwstenen moeten daarbij duidelijker worden gemaakt: staan ze naast elkaar of niet? Je wilt voor de bouwstenen en standaarden de context/werkingsgebied helder maken: in welke keten gebruik je ze wel/niet?

Er is behoefte aan een richtinggevoel: waar moet dit heen om een generieke voorziening te worden? Die vraag kun je op verschillende momenten proberen te beantwoorden, met voor en nadelen. Het is nu geen onderdeel van de pilot zelf, dat kan ook niet met de toegewezen menskracht en expertise. Bij het maken van een PSA voor de pilotprojecten bekijk je alle Nederlandse kaders en geef je bovendien aan of er iets mist. Vervolgens kijk je in de pilot echter alleen naar de effecten van het proces in de eigen organisatie. Als de pilot is afgelopen is de tijd om de evaluatie breder te trekken, maar wel vóór besloten wordt er een generieke voorziening van te maken. Als dat besluit al eerder valt moet je de discussie vooruit trekken: achteraf repareren kan erg duur zijn. Naast de voortgang van de pilot is dus ook de voortgang van de besluitvorming belangrijk.

Actiepunt 2016-06/5: Xander van der Linde (secretaris Stuurgroep): zal ons op de hoogte houden en aangeven op welk moment besluiten genomen worden.​​

Voor de impactbepaling is een maand in de zomer kort. Daarbij is een hoop informatie nog niet bekend en is de impact dus ook niet altijd even duidelijk. Het doel van de impactbepaling is dan ook meer om de risico's aan te geven en te kijken of het ingewikkeld wordt indien je het door wilt ontwikkelen tot generieke voorziening. Op basis van de reacties in de vergadering is al duidelijk dat het ingewikkelder wordt als organisaties zelf een aansluiting en vertaalslag moeten realiseren. Wanneer het bijvoorbeeld via Diginetwerk eenvoudig is aan te sluiten en je ontzorgd wordt, of in sectoren voorzieningen getroffen worden is de impact een stuk kleiner.

Actiepunt 2016-06/6: Menno Gmelig Meijling: vraagt de leden van de Gebruikersraad en toehoorders per mail om hun inschatting van de impact van het doorontwikkelen van de pilot tot één eDelivery gateway naar Europa.​​

Als het besluit genomen is om op basis van de pilot-uitkomsten een generieke voorziening te gaan ontwikkelen dan wil de NORA Gebruikersraad graag advies geven, op basis van een PSA.

Referenties[bewerken]