Blog

NORA: ICT Architectuur binnen de overheid

De ‘NORA’ is een architectuurmodel dat binnen de overheid ontwikkeld wordt om verbetering van overheidsdienstverlening en ambities als 'de elektronische overheid' mogelijk te maken. Het is een uitgebreid model wat als het goed is overheidsbreed toegepast zal worden.

Vooraf

Het acroniem NORA staat voor de 'Nederlandse Overheid Referentie Architectuur'. Inmiddels is de NORA versie 2 gepasseerd. Na de volledige versie 2 wordt het nu in delen verder ontwikkeld. Per katern komen volgende versies uit. Door de voortdurende ontwikkeling kunnen sommige van de hier genoemde punten op enig moment zijn achterhaald.

De NORA 2 tovert een glimlach op mijn gezicht. Spontaan deel ik een rapportcijfer 8 uit. Eindelijk een doordacht model dat richtinggevend voor de gehele overheid de informatiehuishouding adresseert. En dat is hard nodig! Niet alleen om in de toekomst ambities als elektronische overheid in te vullen maar ook omdat in veel overheidsorganisaties de aandacht voor de inrichting van een consistente informatiehuishouding ver is afgenomen. Om dit te toe te lichten een kort uitstapje naar de historie van informatiehuishouding in Nederland.

Historie in de informatiehuishouding

In de jaren zeventig en tachtig zijn veel bedrijfsprocessen voor het eerst geautomatiseerd. Automatisering is in die tijd veel moeilijker en kostbaarder dan vandaag de dag. Opslag van gegevens is erg kostbaar. Programmacode schrijven kost veel tijd. Met deze beperkingen wordt er wel diep nagedacht voor er stappen worden gezet. Er is veel aandacht voor het ontwerp en bedrijfsgegevensmodellen worden veelal nauwgezet bijgehouden.

Een lichtend voorbeeld uit die tijd is de Postbank. In een gegevensmodel staat ieder bedrijfsgegeven gespecificeerd: 'Een giromaat heeft een giromaatcode. Deze code bestaat uit 6 cijfers. De eerste twee cijfers geven de regio aan, volgens de regiocode. Daarbij worden zonodig voorloopnullen toegepast. De laatste vier cijfers zijn een volgnummer, dat eveneens wordt aangevuld met voorloopnullen. Het attribuut giromaatcode is eigendom van afdeling x en giromaatcodes worden uitsluitend uitgegeven door afdeling y. Vervallen giromaatcodes worden nimmer hergebruikt.' De waarde van zo'n model voor de organisatie is enorm, vooral als je ook weet bij te houden in welke systemen en processen het gegeven in gebruik is. Een model als dat van de Postbank kent over de 10.000 items en vereist een bureau dat het beheert, de capaciteit heeft om het uit te dragen en om onderzoek te doen binnen de organisatie om leemtes op te lossen. Het model is vastgelegd in een softwarepakket dat de relaties tussen de attributen beheert en rapportages kan maken.

In de tweede helft van de jaren negentig komen andere methodieken van systeemontwikkeling op. De aandacht voor een expliciete ontwerpfase vermindert en wordt nogal eens gezien als overtollige ballast uit een verleden. Ontwerpen gebeurt uitsluitend nog in de ontwikkelomgeving (IDE - Integrated Development Environment) van de te maken applicatie. Het overstijgende, organisatiebrede niveau raakt hierdoor geleidelijk buiten beeld. Wat ook niet helpt is dat het leidende softwarepakket voor dit type modellering, SDW van Cap Gemini, geleidelijk achterop raakt en uiteindelijk van de markt verdwijnt. Met het pakket verdwijnt in nogal wat organisaties ook de activiteit van gegevens modelleren.

Onderdelen in de NORA

Onder de noemer basisgegevens is deze old school-activiteit weer helemaal terug in de NORA. Dat is logisch, omdat een grote ambitie binnen de NORA is dat ieder basisgegeven op één plaats wordt vastgelegd binnen de overheid en vervolgens via een 'service' wordt uitgeleverd aan andere organisaties binnen de overheid. Het is evident dat je dan moet weten welke gegevens er zijn, hoe die eruit zien en wie er de eigenaar van is.

Grote delen van de NORA zijn in dit opzicht tamelijk basaal. Gegevensmodellering, onderdelen uit de klassieke administratieve organisatie. Je zou je zelfs kunnen afvragen of we het daar nu nog over moeten hebben. Zoals eerder aangegeven: het wordt hoog tijd dat we het er weer over gaan hebben.

De NORA maakt op hoog niveau keuzes in de systeemarchitectuur. Die zijn zeer voor de hand liggend. Internet-technologie, een service-architectuur en een opsplitsing van systemen in drie delen (three tier): user interface, procesuitvoering en gegevensopslag. Niet schokkend, maar wel keuzes die gemaakt en benoemd moeten worden en thuis horen in een architectuurmodel.

Interessant is de aandacht die de NORA besteedt aan een semantische laag waarin de betekenis van gegevens en het waarom van de modellen is vastgelegd. Daarbij worden door het hele model uitgangspunten benoemd waarop de architectuur gebaseerd moet zijn. De uitgangspunten worden bovendien onderverdeeld in categorieën als (vrije interpretatie) 'formeel vereiste', 'overheidsbreed principe' en 'goed idee', waardoor ook de aanleiding voor de regel expliciet is.

In de uitgangspunten komt de relatie tussen de overheid en de burger vaak aan de orde. Politiek gezien mag je het verwonderlijk noemen dat dit plaatsvindt in een ICT architectuur. De praktijk is echter niet anders dan dat veel knopen worden doorgehakt bij het ontwerpen van systemen. Het is grote winst dat ze nu expliciet zijn benoemd - en op het Internet zijn te vinden.

Is het dan allemaal rozegeur en maneschijn? Nee, nog lang niet. Dat heeft met name te maken met het torenhoge ambitieniveau. Het is mooi om een architectuur op dit niveau te plaatsen, maar besef wel dat de werkelijke inrichting ervan extreem complex is.

De proceshiërarchie : een ongewenste herintroductie

Met de hernieuwde aandacht voor oude methodieken sluipt ook een enkele zwakheid het model weer binnen. De proceshiërarchie wordt geherintroduceerd. Dit is een déjà vu uit het boek van Esseling en Van Nimwegen 'Administratieve processen' (1982). Het probleem van de proceshiërarchie is vrij eenvoudig. Zij bestaat niet. Processen bestaan alleen op het niveau waarop ze worden uitgevoerd, een hoger niveau is complete onzin. Je kunt wel spreken van een classificatie van processen, een indeling, maar besef dan dat die indeling slechts een indeling is en dat je ook voor een andere dan een hiërarchische kunt kiezen - wat vaak ook wel zo verstandig is. Het geven van workshops over het opstellen van de proceshiërarchie behoorden tot de zware momenten in mijn leven als adviseur - tot ik besloot ze achterwege te laten.

Modernistische visie

Het model is sterk modernistisch getint, iets wat ICT-ers vaak eigen is. De denkwereld van de ICT-er is een mathematische werkelijkheid, vaak de enige werkelijkheid, waar alles klopt, op elkaar is afgestemd en waar wit echt wit is, zwart zwart en grijstinten ontbreken. Denk je daarentegen niet modernistisch dan zie je de werkelijkheid wellicht niet eenduidig, niet zo perfect, slechts ten dele kenbaar en daarmee oneindig veel complexer. Slecht nieuws voor de modernistische ICT-er: met alleen een modernistische visie kom je er niet. Nog meer slechts nieuws: een andere dan een modernistische visie gaat je systemen aanzienlijk complexer maken.

Iedere burger heeft een burgerservicenummer en je woonadres wordt automatisch uitgewisseld tussen overheidsorganisaties. Prachtig toch? Doorgaans wel, maar niet als je ondergedoken zit in een blijf-van-m'n-lijf huis. Een kennis van me liep wegens dringende reden als zestienjarige weg van huis, vond onderdak in een Gronings kraakpand (binnenkort ook al uitgesloten) en vroeg aan de rector van een VWO-school in die plaats of ze mocht komen. De man nam zonder dat formeel iets te regelen was de juiste beslissing, gaf haar een kans en hield haar daarmee van de straat. Het valt sterk te betwijfelen of die ruimte er vandaag de dag nog is.

Aandacht voor disfunctioneren

Waarom deze verhandeling? Wanneer je gaat nadenken over het koppelen van een groot aantal overheidsorganisaties dan moet je daarbij ook een visie hebben op het functioneren van de overheid in uiteenlopende omstandigheden. En op de onvermijdelijke tekortkomingen die zich daarbij voordoen. Een architectuurmodel als dit zal bijdragen aan een efficiënte overheid en een betere dienstverlening aan de burger.Het zal allerlei soorten van fraude en oneigenlijk gebruik kunnen voorkomen. Dat is winst. Maar het moet ook voorzien in mogelijkheden voor de burger, het bedrijfsleven en organisaties binnen de overheid om een antwoord te hebben in de situatie dat de overheid zelf niet functioneert: dat wil zeggen geen adequaat antwoord kan bieden op een ontstane situatie.

Ik pleit daarom voor toevoeging van het volgende uitgangspunt: een disfunctionerend overheidsproces is geen distopie maar een alledaagse werkelijkheid waarbij niet eens iemand schuld hoeft te dragen. Iedere implementatie, service, dienst en koppeling moet daarop een antwoord bieden en ruimte bieden aan de professionele autonomie van de betrokken ambtenaar en organisatie. Disfunctioneren van een onderdeel mag zich niet onvermijdelijk uitstrekken over de grenzen van dat onderdeel.

Systemen moeten in enige mate 'loosely coupled' zijn om 'social deadlocks' en de daaruit voortvloeiende Kafkaiaanse situaties te vermijden. In de praktijk zal een losse koppeling vaak betekenen dat afnemende systemen moeten kunnen omgaan met een situatie waarin een gegeven niet aanwezig is of niet wordt vrijgegeven. Ook moet in sommige situaties kunnen worden afgeweken van de aangeleverde gegevens. De crisisdienst van de geestelijke gezondheidszorg moet ieder adres kunnen hanteren en vrij kunnen invoeren en niet beperkt zijn tot dat adres dat bij de burgerlijke stand bekend is.

Het is verbazingwekkend dat in het hele architectuurmodel nergens aandacht wordt besteed aan de autonomie van de professional terwijl zaken als prestatiemeting en kostprijsberekening wel worden belicht. Dit is een leemte die zeker moet worden gedicht.

De factor 'tijd'

De NORA besteedt veel aandacht aan gegevensverzamelingen en uitwisselingen tussen systemen. Eerder heb ik voor een organisatie (met 'Post' in haar naam) aan en met een systeem gewerkt dat precies dat deed: basisgegevens beheren en uitwisselen. Wat mist in de NORA is de factor 'tijd' bij een gegeven. Dit is een bijzonder belangrijk aspect en onvoldoende aandacht daarvoor leidt tot grote problemen.

Een gegeven is van kracht op een bepaald tijdstip. Bij iedere uitwisseling van gegevens moet je je dan ook afvragen op welk tijdstip die gegevens gelden. Gebruikers van gegevens hebben uiteenlopende eisen. De afdeling accountancy wil voor de jaarrekening een overzicht van alle vestigingen van het vorig boekjaar. De afdeling marketing wil voor de komende campagne een overzicht van alle vestigingen begin volgend jaar. Twee verschillende lijsten, allebei met hetzelfde gegeven.

Omdat basisgegevens voor veel verschillende toepassingen worden gebruikt - daarom zijn het namelijk basisgegevens - kom je onvermijdelijk met die factor tijd in aanraking. Een leverancier van basisgegevens moet met die tijdigheid kunnen omgaan.

In de uitwisseling van gegevens komt de factor 'tijd' ook nog op een andere wijze naar boven. Wisselen we steeds alle gegevens uit of alleen de mutaties sinds de laatste keer? Totaalbestanden en mutatiebestanden hebben beide hun eigen sterke en zwakke punten.

Het is van groot belang om dit op uniforme wijze te faciliteren in het architectuurmodel. Keer op keer blijkt dit een lastig aspect voor veel ICT medewerkers waardoor fouten en misverstanden ontstaan in iedere fase van het project. Ook wil je niet dat iedere uitwisseling een andere manier krijgt in de omgang met dit tijdsaspect.

Tot slot (voorlopig)

De NORA een rapportcijfer 8 en toch zoveel fundamenteel commentaar? Ja, omdat het stuk zoals het er nu ligt een grote sprong voorwaarts is. En omdat de ambitie de moeite waard is. Het inspireert. Maar we hebben minstens een versie 5 nodig voordat de complexiteit van de werkelijkheid zo wordt afgedekt dat grote mislukkingen kunnen worden voorkomen. Er is nog veel werk te doen.

Overname alleen na voorafgaande toestemming.