NORA 15 jaar - kanttekeningen en advies voor de komende jaren (door Guido Bayens)
.
Guido Bayens heeft deze tekst geschreven n.a.v. de NORA Gebruikersdag 10 november 2020, ter ere van het 15 jarig bestaan van de NORA. Deze versie is van 15 november 2020. Zie ook het eerste deel:
Kanttekeningen en advies voor de komende jaren[bewerken]
In een vorige bijdrage heb ik een reconstructie gemaakt van het ontstaan van de NORA. Dit naar aanleiding van het 15-jarig bestaan van de NORA. Er was mij ook gevraagd iets te zeggen over mijn visie op de toekomst van NORA. Daarover gaat deze bijdrage. Ik begin met enige (kritische) observaties en rond af met enkele adviezen, waardoor de NORA aan belang en impact binnen de overheid kan winnen.
De doelgroep[bewerken]
Op het omslag van de NORA-versies 1.0 (PDF, 2,34 MB) en 2.0 (PDF, 6,98 MB) is kort en krachtig aangegeven wat de doelgroep van dit document is: “vóór en dóór architecten”. Zoals we hebben kunnen lezen in mijn vorige bijdrage was NORA 3.0 “… geschreven voor bestuurders van organisaties die overheidstaken uitvoeren, maar in het bijzonder voor de portefeuillehouders informatiebeleid”. Het behoeft geen uitleg dat hiermee het karakter van de NORA fundamenteel werd gewijzigd. Vanaf de uitgave van de 3.0-versie was de NORA dus niet langer een document dat “inrichtingsprincipes, modellen en standaarden voor het ontwerp en de inrichting van de elektronische overheid” bevat, zoals wordt aangegeven in het voorwoord van de 1.0-versie. NORA was niet langer een architectuur-beschrijving van de elektronische overheid. (editor: NORA 3.0 bestond uit meerdere documenten met verschillende doelgroepen, de volle lijst katernen is terug te zien via Historie.)
De principes[bewerken]
We kunnen een onderscheid maken tussen ontwerp-eisen, in ons jargon meestal aangeduid met ‘requirements’ en de principes voor het construeren van een systeem (in de meest brede zin van het woord, dus variërend van een micro-processor, via bijvoorbeeld bedrijven tot de Nederlandse overheid als systeem). Requirements zijn eisen die gebruikers aan een systeem stellen; principes dienen iets te zeggen over de constructie van de oplossing waarmee aan de requirements wordt voldaan. Of in woorden van emeritus hoogleraar Jan Dietz: Er is een fundamenteel onderscheid tussen de functie van een systeem en de constructie ervan.
In de huidige versie van de NORA wordt ook min of meer met deze tweedeling gewerkt: “Basisprincipes (BP’s) beschrijven de kwaliteit van overheidsdienstverlening vanuit het perspectief van de wensen van de samenleving, de burgers en bedrijven (het wat). (…) Afgeleide principes geven meer concrete invulling aan de basisprincipes. Ze zijn te beschouwen als een checklist van kwaliteitskenmerken van de diensten van de overheid en geven handvatten voor operationeel niveau door hun uitwerking in concrete implicaties” De definitie van basisprincipes komt dus overeen met het idee van ‘requirements’. De afgeleide principes kunnen echter in het algemeen niet gezien worden als constructieprincipes.
Laat ik dit illustreren met een voorbeeld: Afgeleid Principe 26: “De afnemer heeft inzage in de eigen informatie en het gebruik er van”. Dit principe beschrijft een requirement; niet hoe deze eis binnen de overheid moet worden gerealiseerd. Meer in het algemeen kan gesteld worden dat ook de afgeleide principes sterk neigen naar een verbijzondering van de gebruikerswensen (requirements) zoals in de basisprincipes zijn verwoord. Helaas ontbreken in de actuele versie van de NORA constructieprincipes.
Mogelijk verklaart dit ook het loslaten van de relatie met 200 of meer standaarden die in de eerdere versies van de NORA in het verlengde van de aangegeven constructieprincipes lagen. Ook hier weer ter illustratie: In het 9-vlaksmodel staat binnen het veld “Berichten en gegevens” een verwijzing naar zes afgeleide principes. Het wekt verbazing dat er een principe voor ‘berichten’ ontbreekt, terwijl berichten toch een onmisbare schakel vormen binnen een moderne informatiehuishouding. Daardoor wordt er dus ook geen relatie gelegd naar bijvoorbeeld de “Gemeenschappelijke Afspraken Berichten”, noch naar standaarden als StUF, SuwiML, ebMS, Digikoppeling of NEN3610.
Afbakening (scope)[bewerken]
De actuele versie van de NORA lijkt met name geïnspireerd vanuit het perspectief van de afnemer van diensten. Hierbij lijkt impliciet te worden uitgegaan van burgers en mogelijk ook bedrijven als belangrijkste afnemers van diensten. In een meer internationaal jargon zouden we dit ‘business-to-consumer’ noemen. Wat daardoor erg stiefmoederlijk wordt behandeld is het ‘business-to-business’ belang van de NORA. De oorsprong van de NORA lag ook in het mogelijk maken van ketensamenwerking. Op het omslag van de versies 1.0 (PDF, 2,34 MB) en 2.0 (PDF, 6,98 MB) stond dan ook als ondertitel “Samenhang en samenwerking binnen de elektronische overheid”. Het belang hiervan ligt in het verbeteren van doorlopende, eenduidige dienstverlening aan burgers, bedrijven en mede-overheden. Hoe meer eenduidig afspraken worden gemaakt over ketenarchitectuur, hoe beter de overheid als één geheel kan functioneren.
NORAonline bevat een buitengewoon grote hoeveelheid informatie; een veelvoud van de als “te dik” beoordeelde aanvankelijke versies. Desondanks is de scope beperkt. Dit vraagt ook om ‘reparatie-acties’ zoals de meer recente ontwikkeling van de GDI-Architectuur (GA), Common Ground, de “Nederlandse Digitaliseringsstrategie ” en het Manifest “Ontwikkeling Digitale Overheid.” Ook parallelle activiteiten als het Federatief Overleg, dat zich bezighoudt met Gemeenschappelijke Afspraken Berichten en de werkgroep “Banaan”, waarin architecten van de Manifestgroep werken aan een overheidsarchitectuur, duiden erop dat de NORA een te stringente afbakening kent. De oorspronkelijke gedachte achter de NORA, samenhang en samenwerking binnen de elektronische overheid, wordt klaarblijkelijk onvoldoende gerealiseerd.
NORA is niet de jongste meer[bewerken]
Het is interessant te kijken naar een recent boekje waarin 35 bestuurders en CIO’s aan het woord worden gelaten over onderwerpen waar zij mee bezig zijn. Een kleine bloemlezing van door hen veel genoemde onderwerpen (met excuus aan het Engels): Datagedreven, data science, data analytics, algoritmen, artificial intelligence, self learning systems, processen, workflow, business rules, process mining, robotic process automation, chatbots, natural language processing, sensoring, edge computing, digital twin, virtual and augmented reality, containerization, multi hybrid cloud, blockchain…. Een steekproef via de zoekfunctie van NORAonline, levert vrijwel geen enkele treffer op. Dat roept de vraag op of de NORA(-community?) nog wel in verbinding staat met de managers die bezig zijn om de overheid verdergaand te digitaliseren?
Adviezen[bewerken]
Ondanks de grote belangstelling waarin NORA zich mag verheugen, denk ik dat het streven van architecten om managers en bestuurders van puike adviezen te voorzien voor de bedrijfs- en informatiekundige inrichting van overheidsorganisaties, meer succesvol zal zijn, als enkele belangrijke wijzigingen worden doorgevoerd. Op grond van de bovenstaande kanttekeningen, geef ik daarom enkele adviezen.
De doelgroep: terug naar de architecten[bewerken]
Laat de NORA (en haar dochters) weer een naslagwerk of gids zijn voor bedrijfs- en informatie-architecten. De aard van de principes en modellen mag dus best aansluiten bij dit mooie vakgebied. De sterk gevoelde wens om ook managers en bestuurders “mee te nemen” kan veel beter vervuld worden door een speciaal op deze doelgroep af te stemmen document: Kort, toegankelijk en ondersteunend aan besluitvorming.
Stel constructieprincipes op en leg koppeling met standaarden[bewerken]
High level requirements zijn slechts het – niet onbelangrijke – begin van de werkzaamheden van de architect. Maar daarna begint dus het echte werk pas: Het aangeven van de constructie van hetgeen gemaakt moet worden. Concrete invulling geven aan de wijze waarop burgers en bedrijven gebruik kunnen maken van overheidsdienstverlening, van de wijze waarop overheidsorganisaties elkaar en private partijen services verlenen, afspraken over communicatie-protocollen en berichtsamenstelling, richtlijnen voor datanetwerken en informatiebeveiliging, enzovoorts, enzovoorts. Verwijs vanuit deze afspraken of richtlijnen naar de vele tientallen standaarden die binnen de Nederlandse overheid, binnen Nederland, binnen de EU of binnen bepaalde sectoren zijn overeengekomen. Kortom: ontwikkel op deze wijze de ‘bouwtekeningen’ van de moderne overheid.
Verbreed de scope[bewerken]
De NORA en haar dochters dienen te zorgen voor een samenhangend ontwerp van de Nederlandse publieke sector. De overheid bestaat natuurlijk uit zeer veel relatief onafhankelijke organisaties. Het is aan architecten om hierin samenhang aan te brengen. Deze samenhang betreft niet alleen dienstverlening aan burgers en bedrijven. Juist om requirements als ‘no wrong door’, ‘one stop shopping’ en ketensamenwerking te kunnen realiseren, is het van belang dat de NORA afspraken bevat over ketensamenwerking, op zowel het niveau van dienstverlening, bedrijfsproceskoppelingen, informatie-uitwisseling als infrastructuur. Door slimme coalities aan te gaan met ontwikkelingen als de Gemeenschappelijke Overheidsarchitectuur, Common Ground, Banaan en dergelijke, kan de NORA het overkoepelende en integrerende verband worden tussen al deze losstaande initiatieven. Een overkoepeling die bij voorkeur ook aansluit en invloed neemt op het European Interoperability Framework.
Zorg voor aansluiting bij actuele ontwikkelingen[bewerken]
Hoe passen de eerder opgesomde actuele ontwikkelingen als data analytics, artificial intelligence en digital twins in de overheidsarchitectuur? Door ook over deze onderwerpen afspraken te maken in overheidsverband, kan ook hier synergie behaald worden. Bestuurders, managers, CIO’s en CDO’s zullen de architecten dankbaar zijn voor goede ondersteuning op deze gebieden.