English version


Nederlandse versie

Steven's Weblog (Nederlands)

Iedereen kan informatie van deze weblog overnemen onder de voorwaarde dat hij/zij blijft verwijzen naar deze weblog.

 

5 juni 2009: Nederlandse Overheids Referentie Architectuur (NORA)

9 januari 2009 is versie 1.0 van het NORA-Katern Strategie NORA-versie 3.0 gepubliceerd. Dit document is openbaar gereviewd op maandag 23 februari tijdens een bijeenkomst bij ICT~Office in Woerden. Ik heb deel uitgemaakt van de groep reviewers.

Tijdens review is stevig gesproken over NORA. Om mijn eigen standpunt nader toe te lichten heb ik een samenvatting gemaakt van mijn mening. Deze samenvatting kunt u vinden door hier te klikken.

Op 30 mei is door Daan Rijsenbrij een discussie gestart op Via Nova Architectura over NORA (zijn tekst staat ook hier). Hij heeft mij gevraagd om daarop te reageren. Hierna staat mijn eerste reactie op zijn tekst. Voor de verdere discussie verwijs in hier naar wat op Via Nova Architectura staat.

Rond NORA 3.0

Beste Daan,

Je vroeg me om een reactie op je stukje over NORA in Via Nova Architectura te schrijven. De voornaamste reden daarvoor zal zijn dat we allebei, met meer dan 20 anderen, in februari 2009 deelgenomen hebben aan een door ICT~Office georganiseerde expertsessie over het “Katern Strategie” van NORA. Ter afsluiting daarvan heb ik mijn mening in een document gezet, dat document openbaar gemaakt en naar ICT~Office en de NORA ontwikkelaars gestuurd. Het navolgende baseer ik vooral op dit document en op de stellingen die jij in je stukje betrekt. De genoemde documenten zijn ook op mijn website te vinden.

NORA is in feite bedoeld om het mogelijk te maken voor de resp. overheidsorganisaties (en andere organisaties) om gegevens met elkaar uit te wisselen. Om die reden is NORA opgezet rond wat in IT-kringen middleware genoemd wordt. Dat is een bepaalde opzet van (systeem)software tussen en binnen IT-infrastructuren die bedoeld is om gegevens van de ene applicatie over te brengen naar de andere. NORA is daarbij uitgebreid met een context van uitgangspunten, randvoorwaarden, eisen en wensen die nodig is om deze middleware, zoals IT-professionals dat zien, op de juiste manier in organisaties te realiseren.

In het navolgende zal ik eerst kort ingaan op wat ik hier onder de overheid en onder middleware versta, inclusief enige eerste kritische punten. Daarna zal ik ingaan op de punten die Daan in zijn stukje maakt en daarna maak ik enkele afsluitende opmerkingen.

Nederland kent anno 2009 ongeveer 1.600 overheidsorganisaties: ministeries, provincies, gemeenten, organisaties rond water, gezondheidszorg, werkgelegenheid, research, onderwijs, statistiek en vele andere. Die organisaties hebben hun informatievoorziening. Die informatievoorzieningen zijn, en dat past bij de wat een overheid is en doet, gewoonlijk complex tot erg complex. Dat is zo omdat een overheidsorganisatie vaak veel moet weten en bijhouden om naar behoren te kunnen functioneren.

Nederland is een land met veel water en ongeveer 17 miljoen inwoners: de burgers. Overheidsorganisaties zijn bedoeld om het nodige te doen voor Nederland, voor het algemeen nut. Omdat het dan steeds om hetzelfde stuk land gaat verzamelen overheidsorganisaties vaak dezelfde informatie over dat land, het water, de mensen, de organisaties en ga zo maar door. Burgers worden door de ene organisatie gezien als patiënt, door andere als militair, student, belastingbetaler, slachtoffer, autochtoon, kind, werkloze, ZZP-er, chauffeur, kiezer, werknemer, veroordeelde, energiegebruiker, vervuiler en nog veel meer. Allemaal rollen van die zelfde 17 miljoen mensen, en dan spreken we nog niet over de vele rollen die mensen met een andere nationaliteit spelen, net als miljoenen organisaties, objecten, locaties, werken enz. in Nederland om veelheid aan redenen kunnen spelen.

Er zijn vele redenen voor de overheid om gegevens per “rol” te verzamelen, en de antwoorden te combineren. Als je bijvoorbeeld weet hoe ziek mensen kunnen (of zullen) worden kan je de kosten van de gezondheidszorg beter inschatten, en dus beter budgetteren. Of om antwoord en actie op morele vragen te krijgen als: kan iemand die WW trekt een dure nieuwe auto kopen? Om enkele van de vele redenen als voorbeeld te noemen waarom de overheid zoveel gegevens verzamelt.

Anno 2009 bestaat de overheid dus uit ongeveer 1.600 verschillende organisaties. Op die manier georganiseerd denken zij dat zij al het werk dat door de Overheid gedaan moet worden zo goed mogelijk, of zelfs het beste gedaan kan worden. Maar uiteindelijk is er dus één Nederland, en samen zijn deze organisaties dan ook één Overheid voor Nederland. Wat de ene overheidsorganisatie weet kan een andere misschien graag willen weten. Bijvoorbeeld omdat de ene organisatie WW verstrekt, en de andere registreert welke auto iemand koopt. Omdat in een ziekenhuis in Groningen voorgeschreven pillen niet passen bij medicatie die na een ongeluk in Den Haag direct toegediend moeten worden. Enzovoort.

NORA. NORA’s middleware bedoelt overheids- en andere organisaties van gegevens-kanalen, -grachten en -sloten te voorzen via welke gegevens kunnen stromen, uitgewisseld worden, tussen (en binnen) die organisaties. Met een immense hoeveelheid verschillende “pontjes” (berichten, boodschappen, messages) wordt met gegevens heen en weer gependeld. Elke soort bericht een eigen pontje, dus miljoenen verschillende soorten pontjes, of zelfs meer.
En daar begint een probleem. Er zijn snel zoveel soorten berichten dat het beheer ervan een probleem op zich wordt. En dan spreken we nog niet over het aantal berichten dat per berichtsoort verstuurd wordt, en goed aan moet komen. Je kunt het laconieke antwoord van de IT-wereld geloven dat je de aangelegde kanalen/grachten/sloten gewoon breder/dieper/sneller moet maken. Maar congestie, net als files in het autoverkeer, zijn snel niet meer te voorkomen en de eerste berichteninfarcten zijn te verwachten. En dan tussen organisaties, dus door een gebied waar geen organisatie controle op heeft. Nachtmerries voor beveiligers, en vele plaatsen waar informatie gemakkelijk op straat kan, en dus zal, komen liggen.

Het voorstel van IT om zoiets complex als de in NORA beschreven manier om het uitwisselen van gegevens via middleware te realiseren heeft een logisch/technisch reden. In de 70 jaar dat we nu iets met automatisering doen is een groot aantal IT-systemen op vele manieren gebouwd en in gebruik genomen. Die systemen zijn meestal opgezet omdat een groep mensen een keer aangegeven heeft wat zo’n systeem moet zijn, moet omvatten en bevatten. In de loop van de tijd zijn wel steeds meer afspraken gemaakt over de opzet en inhoud van IT-systemen, maar veruit de meeste implementeren lokale en/of door en met leveranciers gekozen kenmerken en ideeën. Ze bevatten dan ook regelmatig dezelfde gegevens, maar steeds weer op een andere, eigen manier.
Als iemand gegevens uit een IT-systeem nodig heeft kan daarvoor een gegevensstroom uitgewerkt worden. De middleware ideeën binnen NORA staan één standaard manier voor om die gegevensstromen te realiseren. Omdat gegevens op zoveel verschillende manieren in allerlei systemen vastgehouden worden zijn ontzettend veel verschillende gegevensstromen nodig. Binnen NORA betekent dit dat er vele soorten berichten zijn, dus vele “pontjes” tussen de (IT-systemen) binnen en tussen de resp. (overheids)organisaties.

Een belangrijke reden voor IT om middleware te willen is dat in de tijd zoveel manieren gevonden zijn om IT-systemen te realiseren (men zegt wel “laat 1.000 bloemen bloeien”) dat het steeds lastiger wordt om al die IT-systemen aan elkaar te koppelen. Het aantal IT-systemen en hun diversiteit is zo groot geworden dat het lijkt alsof het toevoegen van middleware aan de bestaande IT-infrastructuren nog de enige oplossing is om al de gegevensstromen tussen deze IT-systemen enigszins gecontroleerd te kunnen realiseren. Simpeler gezegd: de huidige situatie zou middleware nodig te maken.
Middleware vormt echter zelf ook snel een uiterst complexe en kostbare IT-infrastructuur die veel zorg en beheer behoeft. Het is dan ook de vraag of je een zo complexe IT-infrastructuur beter in de hand kunt krijgen door daar een zeer complexe IT-infrastructuur aan toe te voegen. Zou het niet beter zijn om in ieder geval een deel van de vele tijd die in middleware gestoken moet gaan worden te besteden aan het decompliceren van bestaande IT-infrastructuren? Natuurlijk moet dan wel structureel kennis van de behoefte aan informatie opgebouwd worden die in de meeste organisatie nog niet of alleen verspreid aanwezig is. Maar meer en beter weten wat je, als organisatie, wil geeft de kracht om regie te gaan voeren over de inzet en het beheer van IT. Een idee dat nog maar weinig organisaties onder de knie hebben.
Zo kan gemakkelijk een vraagteken komen bij het op een bestaande technologie gebaseerde standaard, een vaste afspraak, een referentie architectuur neer te zetten om bestaande problemen op te lossen. Is het niet veel beter om decomplicatie als hoofddoel te stellen op basis van een lean-and-mean behoefte vaststelling en middleware alleen zo lang in te zetten om de huidige moloch te temmen? Tot het moment dat die moloch tot optimale proporties teruggebracht is, waarbij het inzetten van ook middleware geminimaliseerd kan worden.
Maar wie denkt bij het inzetten van een gekozen standaard, NORA, aan het bedenken hoe je die standaard ooit weer uit kan laten faseren? Weinigen zullen dat doen, ook niet als zij zich realiseren dat technologie zich erg snel ontwikkelt en dat de kosten van middleware snel astronomische vormen kunnen aannemen. De kans is groot dat nieuwe technologie, mits deze goed ingezet en beheerd wordt, de noodzaak van middleware snel kan minimaliseren, waarbij de afspraken in de NORA-standaard zeer snel aan betekenis zullen inboeten.

Dat middleware een tijdelijk of hoogstens beperkt inzet zal kennen blijkt wel uit het volgende. Als je de stelling neerzet dat mensen, burgers, zelf eigenaar zijn van de informatie die over hen verzameld en vastgelegd wordt, dan wordt het gebrek aan kracht van de huidige informatievoorziening, zeker het deel dat met IT gerealiseerd is, van de overheid duidelijk. De overheidsorganisaties, net als ieder ander die informatie van en over Nederlandse mensen vastgelegd, is daarmee namelijk als “houder” in het “bezit” van iets dat “eigendom” is van iemand anders: de burgers zelf. Als juridisch naar het begrip eigenaar gekeken wordt zullen houders, bezitters en gebruikers van informatie zich moeten houden aan de beperkingen die de eigenaars opleggen aan de manier waarop met zijn of haar informatie wordt omgegaan. Als we dan 1.600 organisaties hebben die elk op tientallen, honderden zo niet duizenden manieren gegevens over burgers vasthouden wordt het spannend om te zien of zij aan die regels voldoen. Laat staan dat alle 1.600 organisaties samen aan die regels voldoen.
Als dit een waar principe zou zijn, en ik acht de kans groot, zal men zich hier aan moeten houden. Dan is de conclusie snel getrokken dat de miljoenen IT-systemen die de Overheid anno 2009 heeft niet aan dat principe voldoen. Met als direct gevolg dat de “pontjes” in de kanalen, grachten en sloten van de middleware van NORA het geheel zelfs sterk compliceren. Per “pontje” wordt immers alleen gekeken naar het transformeren van gegevens in het zendende formaat naar gegevens in het ontvangende formaat. Het geeft geen regels over of de gegevens inderdaad verzonden en ontvangen mogen worden, of de ontvangen gegevens vastgelegd mogen worden, of de betekenis van de verzonden gegevens inderdaad altijd gelijk zal zijn en blijven aan de ontvangende kant. Sterker nog: een gegevensstroom kopieert meestal gegevens van de ene naar een andere plek. Na dit kopiëren kunnen de gegevens op 2 (of meer) verschillende plaatsen bestaan. De IT op elk van die plaatsen zal meestal de mogelijkheid geven om gegevens aan te passen. Zodra dat voor de eerste keer gebeurt zijn de gegevens direct vervuild, want de kans dat zender en ontvanger altijd op exact hetzelfde moment gegevens op dezelfde manier aanpast is verwaarloosbaar. En dan spreken we nog niet over wat gebeurt als diezelfde gegevens steeds verder uitgekopieerd worden. De eigenaar kan zo steeds weer andere gegevens over zichzelf tegenkomen in de vele systemen van de overheid, en dit maakt werken met gegevens en informatie lastig, zo niet onmogelijk.

Dan een situatie in lijn met de middleware van het landelijke Elektronisch Patiënten Dossier (EPD). Het systeemidee is dat men op vele plaatsen gegevens uit het totale aangelegde netwerk van kanalen, grachten en sloten kan opvragen over eenzelfde patiënt (/cliënt). Als we het patiënt-zijn even beperken tot Nederlandse burgers, dan hebben we ongeveer 17 miljoen patiënten (gezien onze samenleving mag immers verwacht worden dat vrijwel iedereen patiënt/cliënt is). Omdat vele bronnen gegevens op een eigen manier vastleggen zijn enorme vertaalslagen nodig om die gegevens betekenisvol bij elkaar te harken, waarbij het tot je nemen van al die gegevens door de vele formaten zeker zo’n groot probleem zijn als het verkrijgen ervan. En dan spreken we nog niet over de betrouwbaarheid, compleetheid en ga zo maar door. Plus dat het in het eigen systeem vasthouden van verkregen gegevens een probleem zal zijn. Medici zullen wel moeten, want hoe kunnen zij anders garanderen dat zij de juiste beslissing hebben genomen als een gebruikte bron haar gegevens elk moment kan wijzigen? Zo’n verandering zou morgen een totaal andere beslissing kunnen opleveren, met alle gevolgen van dien.

Middleware lost dus hoogstens het probleem van vandaag op maar zal hoogst waarschijnlijk niet de oplossing voor de informatievoorziening van de toekomst zijn. Het voegt vooral complexiteit toe aan de al steeds complexer wordende IT-infrastructuren binnen de overheid. Het nare van groeiende complexiteit is dat het steeds moeilijker wordt om het geheel goed te kunnen blijven overzien en gebruiken, laat staan dat e.e.a. naar behoefte aan te passen, of uit te breiden is.
Als je dan goed kijkt naar de informatie van overheidsorganisaties is duidelijk dat zij relatief veel soorten informatie bevatten, maar dat de hoeveelheid gegevens die informatie zijn voor een overheidsorganisatie toch vaak niet exorbitant hoog is. Het is niet abnormaal dat het in een overheidsorganisatie om 5 tot 10 soorten informatie gaat waar men primair aan werkt. Met de kanttekening dat een aantal, vaak veel van deze soorten informatie in elke organisatie aan de orde is.
Bijvoorbeeld informatie over personen. We spreken dan over natuurlijke en rechtspersonen, die, zoals gezegd, in vele rollen voorkomen. Het is relatief simpel aan te tonen dat veel van deze informatie van dezelfde soort is en dat deze soort informatie in het leeuwendeel van de IT-systemen van de overheid voorkomt. Op deze manier is snel vast te stellen wie binnen de overheid verantwoordelijk is voor welke informatie. Met als consequentie dat anderen die autoriteit moeten respecteren, en alleen “mogen kijken”. Zo kan voldaan aan het eigendom/houder/bezit/gebruik uitgangspunt. Met als consequentie dat de IT-infrastructuur van de toekomst totaal anders moet gaan werken, en middleware niet meer de hoofdrol kan spelen die NORA hem nu toebedeelt.

Dan een aantal onderwerpen die Daan aanhaalt, met mijn kanttekeningen daarbij.

Daan zegt, terecht, dat de naam van het document, Strategie Katern, een vreemde is. Hij heeft gelijk als hij zegt dat het document, en daarmee NORA, weinig strategische elementen bevat. NORA gaat over het inrichten van de IT-infrastructuur van de overheid en bevat daarmee typisch tactisch/operationele uitspraken. Daan noemt het strategie katern een verkoopbrochure voor topmanagement. Dat is hard gezegd, maar wel waar. Het is en blijft moeilijk om strategisch cq. topmanagement over te halen om technologie te kopen. Logisch, want strategisch management heeft voor de realisatie van de doelen van de organisatie informatie nodig. Of de juiste informatie nu met een computer of op een bierviltje aangereikt wordt is in feite irrelevant: zo lang de behoefte aan informatie maar op de juiste manier ingedekt wordt. IT is dan iets dat onder de motorkap hoort, iets dat het op een goede manier moet doen tegen niet al te hoge kosten. Of het nu rood of blauw is, al of geen middleware bevat, met Java of Cobol geprogrammeerd is is feitelijk irrelevant. En dus ka het inrichten volgens NORA alleen hard verkocht worden. Met argumenten die weinig aansluiten bij waar topmanagement dagelijks mee bezig is.

Waar ik het minder mee eens ben is over wat Daan over interoperabiliteit zegt. NORA gebruikt het woord interoperabiliteit dan ook op een zeer vreemde manier. Toen ik, zo’n 15 jaar gelden, binnen ISO aan de standaardisatie van Application Portability werkte hebben we ook gestoeid met het woord interoperabiliteit. Interoperabiliteit gaat over het vermogen van systemen om met elkaar te communiceren zodat semantisch vergelijkbare informatie gedeeld kan worden. NORA heeft de betekenis van dit woord sterk uitgebreid door het te gaan gebruiken op meer systeemniveaus. Dus niet alleen voor het naast elkaar laten werken van IT-infrastructuren. Ook het samenwerken van mensen en organisaties wordt interopereren genoemd. Daarmee wordt interoperabiliteit dus een synoniem voor het woord samenwerken. Met als achtergrond dat de mens zelf als een systeem gezien wordt en dat het samenwerken van mensen dus het interopereren van systemen is.
Buiten het feit dat het om een bekend woord uit de wereld van technologie gaat zie ik me toch echt geen discussie voeren met bijvoorbeeld gebruikers over hun interopereren. En dat is wel wat NORA voorstelt. Zo worden systeemniveaus ogenschijnlijk gemengd, terwijl dat mengen niet of nauwelijks mogelijk is. Ik zie het beeld niet dat je krijgt als je mensen laat interopereren; net of je met draadje geïmplanteerde mensen verbindt om te “interfacen”. Het woord samen---werken voldoet voor mij uitstekend en laat extra zien op welk systeemniveau ik bezig ben en dat maakt mijn taak heel veel makkelijker.

Daan zegt over interoperabiliteit dat een begin gemaakt wordt met het onder architectuur brengen van informatieverkeer door interoperabiliteitscriteria expliciet te maken. Hij stelt dat interoperabiliteit tot doel heeft dat burgers, bedrijven en andere overheidsorganisaties in staat zijn om informatie en digitale services van overheidsorganisaties in hun eigen taken en werkprocessen effectief te kunnen gebruiken. Daarmee komt de uitleg m.i. erg dicht bij wat we al een jaar of tien IT-business alignment noemen. Zijn stelling is dat vooral eerst aan interoperabiliteit gewerkt moet worden, en niet aan de applicaties zelf. Dat vind ik een lastig gegeven, want wat voegt het invoeren van middleware toe aan de overheidsorganisaties als je niet aan de toegevoegde waarde van de applicaties kan en mag werken? Het klinkt alsof de ontwikkeling van de toegevoegde waarde van de IT-infrastructuur beter stilgelegd kan worden totdat, onder de motorkap, de middleware goed werkt. Lijkt me een slecht voorstel, want dat zou betekenen dat ik nog een tijd moet investeren en toch met de huidige ondersteuning blijf zitten. Lijkt me geen goede zaak.
Mijn advies is dan ook een heel ander: zorg dat je, als organisatie, je kennis van je informatie onder beheer krijgt. Is niet zo moeilijk, want die kennis is er grotendeels al en moet meestal alleen opnieuw gegroepeerd worden. Met die kennis krijg je de kracht om echt te gaan sturen op de inzet en het beheer van IT. Met, bijvoorbeeld, als waarschijnlijke consequentie dat je dan weet waarom je middleware geheel, beperkt of eindig in moet zetten.

Zoals ik aangegeven heb zie ik IT als aanbod van oplossingen op tactisch/operationeel niveau. Informatie is het bedrijfsmiddel van organisaties, daar is behoefte aan en dus vraag naar. Mensen die samenwerken wisselen onder meer informatie uit, en daarvoor kunnen zij IT, als oplossing, vaak goed gebruiken. Er is dus vraag naar informatie omdat een organisatie daar behoefte aan heeft, en aanbod van IT oplossingen die via investeringen (meestal in projecten) en exploitatie (IT-ers noemen dat vaak beheer) die vraag indekken. Het is echter veel te simpel om te stellen dat interoperabiliteit organisaties in staat stelt elkaars gegevens te begrijpen. Syntactisch kan dat waar zijn, maar semantisch zal men toch dezelfde betekenis aan die gegevens moeten hechten. En dan moeten die uit te wisselen gegevens bovendien nog relevant voor de organisatie geacht worden: het pragmatische aspect. Als hier aan voldaan is zal een gegeven informatie zijn. Als een gegeven dan informatie wordt het relatief simpel om over de inspanning te praten die nodig is om die gegevens beschikbaar te krijgen, en uit te wisselen.
Het is dan weinig met interoperabiliteit te maken waardoor organisaties in staat zijn om elkaars gegevens te begrijpen, laat staan dat men te weten komt wat de gevolgen zijn van een digitale services (lees: IT-systemen of applicaties) die men van een ander gebruikt. Het heeft immers weinig nut om elkaars interpretatie van gegevens te begrijpen en elkaars applicaties te leren kennen als een gegeven geen informatie is.
Organisaties dienen hier zelf iemand te zijn, en dus zelf te weten wat van hen verwacht wordt, inclusief hoe zij daarvoor hun werk moeten doen en wat zij daarvoor nodig hebben. Met deze kennis kan men dan gaan zien wat anderen hebben. Ik verwacht dat Daan het daarom over architectuurprincipes heeft die boven de NORA afspraken staan al kan ik dat niet direct uit zijn tekst lezen.

Met als bijkomende opmerking dat gebruik van het woord principe wel erg zwaar en onveranderbaar overkomt. Wat feitelijk bedoeld wordt wordt het beste afgedekt met termen als uitgangspunt, randvoorwaarde, eis of wens. Die woorden geven veel beter weer hoe de vraag stelt wat aanbod moet (kunnen) leveren, en het is veel minder bedreigend voor belanghebbenden om de zaak niet vast te zetten in principes.

De discussie aan de vraagkant wordt nog anno 2009 nog niet of nauwelijks gevoerd. Zeker is wel dat het geen discussie over interoperabiliteit is. Interoperabiliteit komt pas veel later aan de orde, als ook over het applicatielandschap en de IT-infrastructuur van de overheidsorganisaties zelf gesproken wordt. Maar dan wel alleen deze discussie over aanbod als de vraag goed bekend is.

Als tweede geeft Daan aan hoe cruciaal een goed en gedeeld begrippenkader is. Daar ben ik het op zich zeker mee eens. Alleen geeft de opzet en inhoud van NORA me te weinig ruimte om volledig met de mening van Daan mee te gaan.
NORA is bedoeld voor het inrichten van IT-infrastructuren binnen (en rond) de Nederlandse Overheid. Het bij NORA horende begrippenkader is een IT-begrippenkader. Daan zegt daarvan dat de daarbinnen gedefinieerde begrippen als gedeelde taal in de gehele architectuurwereld in Nederland zou moeten worden geaccepteerd. Ik kan niet veel anders dan te denken dat die gehele architectuurwereld die hij bedoelt zich beperkt tot de IT-wereld binnen (en rond) de Nederlandse Overheid, maar ik vermoed dat Daan dit niet zo bedoelt.
Sterker nog, hij gaat verder door NNI als beheerder van die taal aan te wijzen. Nu is NNI er niet alleen voor de overheid, maar vooral voor standaardisatie in het algemeen. Bijvoorbeeld voor de standaarden van ISO. Daan zegt ook dat die taal dan ook maar gelijk door Nederland als geheel geaccepteerd moet worden, zodat NORA feitelijk voor alles en iedereen in Nederland zou gelden. Wederom lees ik hier niet alleen de IT-wereld, maar voor iedereen. Een aantal punten:

… NORA kijkt vanuit haar wezen naar en vanuit de IT-wereld. Om de taal die via NORA door IT-ers gesproken wordt voor andere IT-ers standaard te maken gaat me te ver.

… NORA laat vele, zo niet veruit de meeste zaken liggen die buiten de IT-wereld horen. Om dan toch de taal van NORA standaard te maken voor werelden waar zij niet thuishoren is m.i. naïef, en ongewenst. Het uitdrukken van bijvoorbeeld een behoefte aan informatie kan nu eenmaal niet in de uiterst beperkte IT-taal-mal geperst worden. Je kunt bijvoorbeeld stellen dat samenwerken voortaan interopereren heet, maar het nut daarvan is onduidelijk en het is te verwachten dat de wereld buiten IT zich een bult lacht als IT dat probeert.

… Ik geloof niet dat NORA bepalend kan worden voor het inrichten van andere IT-infrastructuren dan die binnen de overheid. We kunnen dat soort zaken maar beter aan onafhankelijke internationale standaardisatie overlaten, en niet aan een beperkte groep IT-ers die het best wel leuk zullen vinden als hun werk aan de rest van de wereld opgelegd wordt. Dat kan niet werken omdat e.e.a. te zeer toegesneden is op de Nederlandse overheid, en te beperkt van opzet is om een echte standaard te gaan worden.

Oftewel: NORA, hou je bij je leest. Die is moeilijk genoeg. En laten we hopen dat de niet IT-ers binnen de overheid snel aan het echt formuleren van de vraag beginnen.


Als derde gaat Daan in op wat principes binnen NORA genoemd worden. Buiten het feit dat ik, zoals ik hiervoor al geschreven heb, de bedoeling van het woord principe pretentievol, ja stevig megalomaan vind denk ik ook dat NORA zich ook hier bij haar leest moet houden. Beter zou zijn om het woord principe te reserveren voor vakmatige wetmatigheden, zoals het feit dat in veel programmeertalen regels code in een bepaalde volgorde geschreven moeten worden. Of het feit dat het principe van het scheiden van functies in organisaties noodzakelijk is. Of het vrijwel vergeten principe van goto-less programmeren enz. Daarmee wordt de discussie rond of je principes wel mag of zelfs kunt wijzigen veel simpeler. Het gaat immers steeds weer om uitgangspunten, randvoorwaarden, eisen en/of wensen.

Daan heeft het over een opstap om naar de “echte architectuurprincipes” te gaan (ook hier: het woord principe past gewoon niet). Die vallen buiten de scope van NORA omdat die “architectuurprincipes” weinig of niets met IT-aanbod te maken hebben. Ze eraan toevoegen zou verschillende werelden samen in één document brengen, en dat is slecht voor het document en voor wat die werelden willen en kunnen.
Aan de vraagkant, waar Daan dus architectuurprincipes vermoed, werken informatiekundigen en geen IT-ers. Zij specialiseren zich in de informatie waar een organisatie behoefte aan heeft en zij formuleren die behoefte zodanig dat het richtlijnen enz. worden voor de inzet van IT. Hoewel de 10 basisprincipes van NORA 3.0, volgens Daan, geen techneutenuitstraling hebben wil dat nog niet zeggen dat ze niet over technologie en haar inzet gaan. Dat is dus, zoals ik het lees, vooral wel het geval, en dat is ook logisch gezien wat NORA is.

Het is ook de vraag of er in wat Daan architectuurprincipes noemt ooit een limitatieve opsomming kan zijn. Net als dat het m.i. een fictie is dat die “principes” disjunct zouden moeten zijn, of dat je moet proberen daarnaar te streven. Het gaat hier immers om kennis, en die kennis kent vele vormen. Ik begrijp de blauwe, op structuur en functie gerichte wereld van IT in dezen wel; het zou immers zo makkelijk zijn als het zo zou zijn.
Maar zo zit de wereld buiten IT meestal niet in elkaar. De wens om een limitatieve en/of disjuncte opsomming te hebben geeft een reden waarom het vaak zo moeilijk is om over kennis van informatie met IT te spreken. De wereld is nu eenmaal lang niet altijd maakbaar, en die kennis is dus ook niet in een soort orthogonaal stelsel vast te leggen. Een vertaling van die kennis naar oplossingen in termen van een specificatie, een programma van eisen, een bestek en hoe dat allemaal nog meer genoemd wordt is feitelijk waar IT de werkelijkheid raakt als het om investeringen gaat. Die werkelijkheid is dan al vertaald naar de richtlijnen die zij zullen moeten volgen bij het bouwen van een IT-oplossing. Ik vermoed dat Daan de achterliggende kennis architectuurprincipes of de “strategische” uitgangspunten noemt, de basis voor het veranderen van wat hij de digitale wereld noemt.

Daan stelt verder dat hij een herleiding naar een echte integrale toekomstvisie (3 jaar termijn) op de e-samenleving in NORA mist. Ik neem aan dat hij hier een ontwerp op hoofdlijnen bedoelt. Prima. Met dien verstande dat je zoiets niet kunt opstellen zonder dat je weet wat je informatie is, en hoe je daar als organisatie van voorzien wilt zijn. Zo’n ontwerp op hoofdlijnen van de gewenste toekomstige IT-infrastructuur is, in de complexiteit van de huidige situatie en met de beperkte werkkracht die we daarvoor hebben, m.i. vooral een tweede plan activiteit. Op het eerste plan staat dat de overheid goed weet wat informatie is, wat ze met die informatie willen en hoe zij structureel kennis van die informatie opbouwen en beheren. Als je niet voldoende weet en toch gaat ontwerpen mag je verwachten dat je binnen de kortste keren dingen tegenkomt waardoor je je ontwerp moet aanpassen. De wens van IT is een stabiel ontwerp, één die langere tijd niet verandert. In de praktijk wil dat zeggen dat je, hoewel je weet dat zaken veranderen, je daar niet op reageert en gewoon door gaat aan waar je aan werkte. Vaak voor langere termijn, zoals enkele jaren. Vanuit het standpunt van IT is het ook lastig om een ontwerp om te gooien zodat misschien projecten aangepast moeten worden, of zelfs de IT-infrastructuur zelf. Dit lijkt een keuze tussen een steen en een ander hard plekje, of de paradox van An Irresistible Force versus An Immovable Object: welke zal eerst wijken?
Als je hier anders naar kijkt, dus niet vanuit IT, is het niet echt een dilemma. Mits je goed weet wat je met je informatie wil, en op basis daarvan strakke opdrachten geeft. Maar dan ligt wel de bijl aan de basis van NORA, omdat die basis een IT mogelijkheid is. Met een opmerking over de kennis van informatie: die is in elke organisatie aanwezig, alleen is die kennis vrijwel nergens consistent en consequent gedragen. Ieder heeft zo zijn of haar eigen beeld, en dat maakt de basis om strakke opdrachten te kunnen geven, om echt regie te kunnen voeren zwak.

Daan heeft het daarna over IT volwassenheid. Dat is een heel lastig begrip, omdat zeer discutabel is hoe volwassen de resp. technologieën zijn. Laat staan dat goed vast te stellen is of een bestaande technologie volwassen toegepast wordt. Ook hier denk ik dat beter over informatie volwassenheid gesproken kan worden: de mate waarin een organisatie volwassen met haar informatie als bedrijfsmiddel omgaat. Of men daar de juiste hulpmiddelen, zoals bijvoorbeeld IT, voor inzet kan daar een onderdeel van zijn, al is dat feitelijk alleen een afgeleide.

Tijdens de expertsessie “NORA-review” is diverse keren gesproken over Governance. Dit onderwerp is steeds terzijde gelegd omdat het niet zou passen in het voorliggende NORA document. Als dit het geval zou zijn bestaat ook hier een soort dilemma. Aan de ene kant is het NORA document immers bedoeld voor “directieleden, bestuursleden, CIO's, informatiemanagers, stuurgroepleden, programma-managers, projectleiders, auditors, beleidsmedewerkers en adviseurs” terwijl niet ingegaan wordt op waar NORA deze functionarissen “raakt”. Daarmee sluit de inhoud van het voorliggende NORA document per definitie weinig aan bij de denk- en werkwereld van de door hen aangegeven doelgroep. Alleen al omdat de huidige invulling van de functie CIO niet eenduidig genoeg is omdat het acroniem met meer dan één uitleg gebruikt wordt. En iets vergelijkbaars geldt trouwens voor het begrip architectuur. Ook daar kan niet algemeen over gesproken worden omdat, zoals in de praktijk blijkt, iedereen er iets anders onder verstaat. Daarmee wordt dus niet uitgesproken hoe een referentie architectuur, whatever that may be, gemanaged wordt: door wie, en waarom. Een sterk gemiste kans.

Daan stelt ook allerlei nieuwe versies van NORA voor. Mijn advies-met-klem zou zijn om ervaren informatiekundigen, niet-IT-ers dus, eens echt te goed te laten kijken naar de Overheid en haar informatievoorziening. Simpelweg om te voorkomen dat allerlei IT-ers sprongen op basis van NORA gaan maken die niet beperkt worden door NORA omdat NORA vrijwel niets over de vraagkant zegt.
Sterker nog, in feite is de huidige inhoud van NORA weinig interessant voor de niet-IT overheid. Andersom gezegd: als de niet-IT overheid haar informatie echt in de grip wil nemen zal er niet zoveel van de betekenis van NORA overblijven, behalve dan voor IT-ers en IT-leveranciers. Met de verwachting dat de technologie die NORA in haar basis heeft op niet al te lange termijn (sterk) zal verouderen. Wat Daan ziet als het verder uitwerken van principes (4.0) en een architectuurvisualisatie (5.0) staat nog op geen enkele grond omdat de overheidsorganisaties nog onvoldoende goed zelf weten wat ze willen, en kunnen. En dat heeft niets met IT te maken. Principes en visualisaties van nieuwe IT-infrastructuren kunnen en zullen daarom snel op grote problemen stuiten omdat de basis van de nu voorliggende “standaard”, NORA, niet stabiel is. Om er dan veelgeld aan te besteden lijkt niet echt verstandig.

Daarom ter afsluiting: het is goed dat de IT-wereld binnen de overheid afspraken wil maken over de inrichting van haar IT-infrastructuren in de toekomst. NORA baseert zich echter op een stokpaard-technologie die vooral bedoeld is de huidige problemen het hoofd te bieden. Daarom hier het advies om, als NORA gebruikt gaat worden, om eerst vooral ook goed te bedenken hoe je zo goed mogelijk weer van middleware af kunt komen als de huidige problemen opgelost zijn. Wat NORA voorstelt zou een tijdelijke verhoging van de huidige kosten kunnen zijn mits direct ook gewerkt wordt aan wat de informatievoorziening van de toekomst zou moeten zijn. De ervaring leert dat een echt goede informatievoorziening veel en veel minder IT vereist dan nu ingezet is (uitgaande van wat nu geboden wordt en niet van nieuw werk). Het vereist ook sterk management, en organisaties die echt weten wat ze doen met en rond hun informatie. En dat gebeurt nog te weinig, terwijl meer en meer congestie en zelfs IT-infarcten niet ver weg meer lijken te zijn. Interessante tijden, zoals de chinezen zeggen. Tijden al wel lang geleden begonnen zijn. Vrij naar John F. Kennedy: ook een lange weg begint met een eerste stap.

Uw naam:
Uw E-mail:
Uw reactie: