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.