De vernieuwde NORA

Daan Rijsenbrij, zaterdag 30 mei 2009

Na NORA1 1.0 (2006) en NORA 2.0 (2007) werkt ICTU nu aan NORA 3.0. Door de modulaire structuur van deze laatste versie wordt ons beloofd dat het geheel veel overzichtelijker zal worden. Het katern ‘Strategie’2 is het eerste document dat nu min of meer klaar is3. Dit katern beschouwen de auteurs als de basis voor NORA. Een echt basisdocument is een hele verbetering ten opzichte van NORA 2.0., maar ik begrijp niet waarom het dan niet gewoon basisdocument heet in plaats van strategiekatern. Er is trouwens niets strategisch aan, en het is in feite bedoeld als een ‘verkoopbrochure’ over architectuur voor het topmanagement.

Er wordt gesteld dat er inhoudelijk niet echt veel is veranderd. Dus mijn eerste opwelling was: ‘noem het dan niet 3.0, maar 2.5!’. Een nadere analyse van dat katern ‘Strategie’ leert echter dat het ICTU-team zeer zinvol bezig is geweest, je zou zelfs kunnen stellen dat zij een fundamentele herbezinning hebben uitgevoerd. Dat was dan ook wel hard nodig! Want, laten we eerlijk zijn, NORA 1.0 en 2.0 waren in feite eenvoudige onsamenhangende knip-en-plakwerkjes uit de wereldlectuur aangaande digitale architectuur en IT-engineering zonder een duidelijke originele visie. Het enige verdienstelijke van die eerdere versies lag in het identificeren en beschrijven van enkele standaarden en bouwblokken. Mij is echter nog steeds niet duidelijk hoe de inventarisatie van deze bouwstenen is verricht. Welke systeemtheoretische overweging heeft aan deze opsomming ten grondslag gelegen? Is deze opsomming wel limitatief? Maar, eerlijkheidshalve dient ook te worden opgemerkt dat het onderkennen en etaleren van de noodzaak van iets als NORA een belangrijke verdienste is geweest van deze eerste twee versies.

Wat is dan de essentie van die fundamentele herbezinning?

Ten eerste lijkt een begin te worden gemaakt om het informatieverkeer onder architectuur te brengen door het expliciteren van interoperabiliteitscriteria4. Dat is een hele verbetering ten opzicht van de vorige versie. Interoperabiliteit ligt echter op het niveau van standaarden, daar horen dus wel architectuurprincipes boven waarvan deze standaarden een concretisering zijn.
Door interoperabiliteit zijn overheidsorganisaties in staat elkaars informatie te begrijpen (syntactisch en semantisch) en weten zij wat de gevolgen zijn van de digitale services die zij van elkaar gebruiken (pragmatisch). In een fundamentele herbezinning over de samenwerking tussen relatief onafhankelijke organisaties is het cruciaal eerst te werken aan interoperabiliteit, en de architectuur van het applicatielandschap en de infrastructuur van de afzonderlijke overheidsorganisaties zelf nog even met rust te laten.

Ten tweede wordt het cruciale belang van een begrippenkader expliciet onderkend om de potentiële begripsverwarring te vermijden. Het zou goed zijn als die gedeelde taal in de gehele architectuurwereld in Nederland zou worden geaccepteerd, en wellicht beheerd door het NNI. Ik hoop althans dat naast de overheid ook de zorgsector en de onderwijssector zich zullen gaan conformeren aan NORA en wellicht dat grote delen van het bedrijfsleven volgen. Ik zie namelijk niet in waarom ik met mijn bank op een andere wijze zou willen communiceren dan met een overheidsinstelling. Ik hoop dat er over dat katern snel consensus zal zijn.

Ten derde wordt met een nieuwe blik naar de principes gekeken. Het is zeer verstandig dat in die fundamentele herbezinning eerst tien basisprincipes zijn geformuleerd alvorens over te gaan naar de echte architectuurprincipes. Deze basisprincipes worden ‘verkocht’ als de belangrijkste kenmerken van overheidsdienstverlening en vertonen gelukkig niet die techneutenuitstraling5 als de twintig fundamentele principes uit NORA 2.0.
Hoewel de tien basisprincipes uit NORA 3.0 veel compacter lijken dan de twintig fundamentele principes uit NORA 2.0, vraag ik mij af of deze tien echt limitatief zijn en voldoende disjunct. Sommige lijken nogal functioneel van aard. Nu wordt weliswaar voor elk basisprincipe in de onderbouwing de bron van het principe weergegeven, maar ik vraag mij af of deze bronnen zelf wel zijn geformuleerd vanuit de afnemer (burgers, bedrijven, en andere overheidsinstellingen). Ik zou daarom graag een directe relatie zien tussen de basisprincipes en de kwaliteitseisen vanuit de afnemer. Maar eigenlijk had ik liever gezien dat er echte strategische uitgangspunten6 waren gedefinieerd. Daarnaast mis ik toch ook een herleiding naar een echte integrale toekomstvisie op de e-samenleving7.

Ik mis in die fundamentele herbezinning de digitale communicatieruimte8 voor de burger (een soort uitbreiding op de PIP9, die eerder al was aangekondigd). Ik hoop dat dat nog wordt recht getrokken, want een digitale communicatieruimte hoort er bij een moderne architectuur wel bij als je beweert dat je de afnemer centraal zet.

Hoewel NORA een raamwerk heet te zijn, geldt daarvoor in feite hetzelfde als voor een individuele architectuur. Deze dient afgestemd te zijn op de IT-volwassenheid van de onderhavige organisatie. In dit geval het gemiddelde van alle betrokken overheidsorganisaties. Dat vereist dus een stapsgewijze verfijning van het betreffende raamwerk en een heldere architectuurgovernance. Ik krijg geen duidelijkheid hoe de architectuurgovernance over NORA eigenlijk in elkaar zit, laat staan over de gehele architectuurfamilie van de overheid (dus NORA, MARIJ, PETRA, GEMMA en WILMA).
Omdat NORA nog niet uitgekristalliseerd is, lijkt het mij verstandig als ICTU het vervolg kenbaar maakt. Mijn voorlopige voorstel zou zijn: NORA 3.5 ‘governance van de architectuurfamilie bij de totale overheid’, NORA 4.0 ‘architectuurprincipes concreter, specifieke architectuurconcepten en bouwblokken’ en ten slotte NORA 5.0 ‘architectuurvisualisaties als oriënteringsplaten om de verschillende organisaties binnen de overheid inclusief hun samenwerkingsvormen en ketens te positioneren’.
Voorts hoop ik dat er een expliciete gebruiksaanwijzing komt hoe NORA-conformiteit dient te worden bereikt van het hoogste niveau van referentiearchitectuur tot en met een individuele architectuur.
Er zijn geluiden, met name van ICT~Office, dat NORA standaard onderdeel dient te worden voor aanbestedingen. Persoonlijk zou ik de aanbesteding richting de bouwer pas willen laten beginnen na de functionele specificaties. Dat impliceert dat bij aanbesteding alleen dient te worden vermeld van welke NORA-bouwblokken dient te worden uitgegaan. Het functioneel ontwerp wordt gemaakt onder de verantwoordelijkheid van de architect en dus conform NORA, lijkt mij.

Bij het doorlezen van het eerste katern van NORA 3.0 krijg ik het stellige gevoel dat om redenen van haast er een soort ‘middle out’ benadering is toegepast, dus voortbouwend op allerlei beleidsdocumenten die ook niet gebaseerd zijn op een integraal toekomstbeeld van de e-samenleving. Daar is niets op tegen. Maar om te voorkomen dat er net als bij de Belastingdienst een paar jaar geleden, over een paar jaar voor de totale overheid een complexiteitsreductieprogramma dient te worden opgesteld, zou ik het conceptuele kader veel meer aandacht geven.

Als ik als architect een digitale (referentie)architectuur zou mogen formuleren voor de overheid (of zelfs de gehele publieke sector) zijn er twee separate aandachtsgebieden: het informatieverkeer tussen de relatief onafhankelijke overheidsorganisaties10 en een referentiearchitectuur voor die overheidsorganisaties, eventueel verbijzonderd naar specifieke domeinreferentiearchitecturen.
De architectuur van bovengenoemd informatieverkeer zou zelfs veel verder kunnen gaan dan de overheid. Het lijkt immers wenselijk dat het informatieverkeer tussen burgers onderling, tussen burgers en private ondernemingen en zelfs tussen private ondernemingen onderling aan dezelfde architectuur gaat voldoen.
Het is de vraag of er voordat een overheidsarchitectuur wordt opgesteld eerst niet een architectuur voor de digitale samenleving hoort te worden geschetst, waarin de NORA hoort te passen, en die tevens infrastructurele voorzieningen schetst voor een e-samenleving die door de overheid wordt gefaciliteerd.
Ik zou daarom beginnen een expliciete visie op de gewenste toekomstige digitale samenleving te formuleren. Een architect dient zich eerst een beeld te vormen over hoe burgers en bedrijven (horen te) functioneren in een digitale samenleving. Daarop dient een toekomstbeeld te worden geschetst van de daarin passende gewenste digitale overheid. Voorts rijst dan de vraag wat de overheid levert aan faciliteiten11om die digitale samenleving optimaal te laten functioneren. Etaleer beide beelden heel breed, via het internet, zodat elke burger de mogelijkheid heeft om laagdrempelig zijn commentaar te geven. Daarna kan op basis van deze beelden de overheidsarchitectuur worden geformuleerd. Deze beelden zouden de belangrijkste bron dienen te zijn van de architectuurprincipes. Daarnaast zijn er natuurlijk nog de concerns, het ecosysteem en de bestaande situatie die onder andere tot additionele architectuurprincipes aanleiding kunnen geven.

Afsluitend, NORA 3.0 lijkt een verstandige stap in een goede richting. Het zou alleen wat sneller mogen en er dient een echte conceptuele onderbouwing te worden gemaakt. Het lijkt mij verstandig het katern ‘Strategie’ om te bouwen naar enerzijds een echt basisdocument dat conceptueel stevig in elkaar zit en anderzijds een vlotter geschreven verkoopbrochure om overheidsbestuurders van de noodzaak van architectuur en NORA in het bijzonder te overtuigen.

Gepubliceerd in sterk verkorte vorm in de Automatisering Gids, 29 mei 2009, nummer 22, pagina 18.

1 NORA staat voor Nederlandse Overheid Referentie Architectuur, zie www.noraforum.nl.

2Deze column is gebaseerd op het NORA-katern Strategie, versie 1.0, distributie13, revisie 664 (23 april 2009).

3Het wachten was op de formele vaststelling door het college Standaardisatie op 20 mei.

4Interoperabiliteit heeft als doel dat burgers, bedrijven en andere overheidsorganisaties in staat zijn informatie en digitale services van overheidsorganisaties in hun eigen taken en werkprocessen effectief te kunnen gebruiken.

5Er is niets mis met technologie. Maar technologie is slechts een mogelijke invulling en mag geen doel op zich zijn.

6Strategische uitgangspunten zijn richtinggevende uitspraken die voortkomen uit de visie en strategie van de overheid ten aanzien van haar informatisering/digitalisering en dienen om de digitale (referentie)architectuur in te kaderen.

7Ik zou daarvoor een expliciet beeld willen krijgen hoe de e-samenleving er over drie jaar uit dient te zien en hoe zij er over tien jaar uit zou kunnen zien.

8 Zie ook mijn column over de persoonlijke digitale werkruimtein de Automatisering Gids, 27 februari 2009, nummer 9, pagina 14.

9 Persoonlijke Internet Pagina: www.e-overheid.nl.

10en natuurlijk met de afnemers (burgers en bedrijven).

11 Ik kan mij bijvoorbeeld voorstellen dat aan iedere Nederlander bij geboorte een emailadres met een virusvrije emailbox ter beschikking wordt gesteld. Wellicht gratis Internet (immers de openbare ruimtes in Nederland zijn ook gratis te gebruiken), met veilige digitale discussieruimtes. Voorts zou het wenselijk zijn dat er gratis betrouwbare back up faciliteiten komen en non repudiation faciliteiten in het emailverkeer.

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.46

Geschreven door Mark Paauwe op 31-05-2009 08:37

Daan heeft wat mij betreft bruikbare kritische opmerkingen en verbeteringsuggesties aangedragen voor NORA.

Maar hij gaat nog lang niet vergenoeg.

Het is jammer dat hij niet pleit om te stoppen met discussie over NORA als theorie en dat we over het praktijkgebruik van NORA gaan praten. HIER OP VIA NOVA. We moeten meer NORA in de praktijk brengen en toetsen en deze praktijkervaring te gebruiken om NORA te verbeteren. Dit omdat een NORA nooit perfect kan zijn, er altijd discussie over mogelijk is en we wel keihard en snel de digitale e-overheidsdiensten nodig hebben. Dus als Daan bepaalde zaken mist in NORA dan zou ik zeggen: Daan, zoek mensen bij-elkaar, start een (proof of concept) project op, ontwerp en bouw iets en lever dat resultaat als generiek bouwsteen met principes en stijlelementen aan voor NORA. (in wezen vraag ik om bronverwijzing van principes en concepten)

Wat ik niet wil? Ik wil op het LAC2009 geen oeverloze en kansloze theoretische beschouwingen meer van gefrustreerde architecten die zich zelf onbegrepen voelen met hun eigen architectuurmethode of beschouwing. Daar hebben we niets aan en we kunnen er niets mee.

Wat ik wel wil? Ik wil op het LAC2009 en LAC2010 zien welke onderdelen uit NORA bij welke overheidsinstellingen, burgers en bedrijven hebben gezorgd voor vernieuwing en betere digitale e-overheidsdienstverlening. We kunnen dus het LAC2009 programma opnieuw maken op basis van de inhoudsopgave van NORA 3.0.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.46

Stel je voor op het LAC: 800 architecten-achtigen die in Nieuwegein constructief met elkaar communiceren en discussiëren over de problemen die je tegenkomt bij de toepassing van NORA in de praktijk en allerlei successen en oplossingen die het brengt.

Als NORA bedoeld is als referentie enterprise architectuur voor een e-overheid, dan dienen we op basis van NORA e-overheidsdienstverlening voor overheidsinstellingen te gaan ontwerpen en realiseren. Waar is het voorbeeld ontwerp (dus geen architectuur) vanuit NORA om te laten zien hoe het eruit ziet als je op basis van NORA gaat ontwerpen? NORA is toch niet alleen bedoeld als discussie stuk, daar heeft geen enkele digibetische Nederlander wat aan. Dus NORA moet zelf ook nog wat meer handvatten bieden om architecten en beleidsmedewerkers in Nederland op gang te helpen.

Zoals bouwkundige architecten wel eens zeggen: In een architectuur kun je niet wonen, in een gebouw wel! Na architectuur MOET altijd ontwerp en realisatie volgen.

Ik heb voor NORA 2.0 een serie platen gemaakt voor enkele klanten om uit te leggen hoe je NORA in de praktijk kunt brengen. Ik ga dus zelf maar de handschoen oppakken en een vrij/openbaar bladerboek maken met mooi platen die laten zien hoe het eruit ziet als je een gemeente, provincie en ZBO ontwerpt op basis van NORA 3.0. Dat je ziet welke problemen er mee kunnen worden geïdentificeerd en opgelost, wat voor de lange termijn toekomst (rots)vast is en wat een realistisch en haalbaar nabije toekomstscenario is en wat dus tijdelijke stijlelementen en principes zijn in de organisatie.

In de praktijk zie ik helaas veel mensen die zichzelf architect noemen, maar niet kunnen ontwerpen. Bij hun organisatie maken ze wel AS-IS-architectuur-analyses en TO-BE-architectuur-analyses. Dit is ook 100 x eenvoudiger dan op basis van een werkende architectuur een organisatie breed ontwerp te maken dat toekomstvast en duurzaam is. Dus als mensen willen meehelpen met het maken van het bladerboek, dan sta ik open voor alle architecten waarvan anderen vinden dat ze kunnen ontwerpen (en dus ook modelleren en visualiseren).

Veel bouwkundige architecten maken (of laten dit doen) een informatiemap van een masterplan waarin een architectuur is gebruikt voor een project. Ik zal op basis van NORA dit ook gaan doen voor een zelfbedachte opdracht. Open en vrij.

Ik ben gelijk al tegen drie zaken aangelopen vorige week bij de aanzet voor een bladerboek die ik miste in NORA.

Probleem 1: In NORA wordt te weinig gewerkt met verschillende beschouwingsmomenten of architectuurplateau’s. Het is normaal om in architectuur drie beschouwingsmomenten te onderkennen: AS-IS, TO-BE, Envision. NORA geeft te weinig aan wat de huidige problemen zijn en waar ze zitten in de organisatie en waarom ze een probleem vormen. En hoe realistisch het is ze op een bepaald kwaliteitsniveau op te lossen voor de nabije toekomst (TO-BE). Dus ik kan met NORA nu nog niet zo goed onderbouwen dat je met NORA een TO-BE enterprise architectuur en ondernemingsontwerp kunt maken voor een overheidsinstellingen. Je moet daar zelf je eigen aannames bij doen en invullingen aan geven. Maar zoals ik al eerder zei, dit breng ik straks weer in als voorstel-aanvulling op NORA.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.46

Probleem 2: NORA gaat te weinig in op de dynamiek bij de overheid dat alles over 10 jaar weer anders is. (De envision architecture). Als we weten het er sowieso over 10 jaar uit ziet, kunnen we zeer toekomstvaste en duurzame onderdelen voor overheidsinstellingen onderkennen. En dan kunnen we daarmee weer terug redeneren naar de TO-BE architecture.

Probleem 3: Niet alles wat architecten maken is architectuur. Architecten maken ook masterplannen, structuurtekeningen, proofs of concepts. Soms gebruikt een architect architectuur voor beheerste risico-loze innovatie bij een instelling. Soms gebruikt een architect pionieren (risico-volle aanpak) om nieuwe concepten te proberen in de praktijk. In NORA wordt je niet geholpen bij het maken van verschil hierin en er staat niet duidelijk en voldoende genoeg welke producten je als architect nu moet maken.

Probleem 4: Er staan zaken in NORA die je niet even bij andere overheidsorganisatie kunt bekijken. Ik vraag me ook af of sommige zaken (zoals principes en gestelde uitgangspunten) ook wel vanuit ervaring zijn opgesteld in NORA of dat het theoretisch er goed uit ziet. Het ijkt mij dat er voor NORA zelf ook ontwerpregels gelden: Alleen zaken die in de praktijk al werken mogen er in komen. Als deze ontwerpregel niet wordt gehanteerd is NORA eigenlijk geen referentie architectuur maar een referentie pioniersaanpak.

Probleem 5: De principes in NORA neigen te veel naar strategische uitgangspunten zoals die gesteld zouden moeten worden door bestuur en directie bij de overheidsinstellingen. In de principes zou meer geformuleerd moeten worden wat de gehandhaafde werking is van de achterliggende concepten. Ook staat er zo’n beetje van geen enkel concept in NORA een principeschets en principetekening waar mee je als architect aan een leek de voordelen van het hanteren van bepaalde concepten kunt uitleggen. Omdat er geen verschil wordt gemaakt tussen strategische uitgangspunten, kwaliteitsaspecten (ilities) en concepten met hun principes in NORA is het ook lastig om uit te leggen aan bestuurders en directie waarom zeker concepten en principes op een afgesproken kwaliteitsniveau bepaalde strategische uitgangspunten gaan realiseren en bepaalde strategische problemen gaan wegnemen. Kortom de uitlegbaarheid en verdedigbaarheid van NORA is nog laag.

Wat ik zelf doe aan gebruik van NORA voor ontwerp is natuurlijk op veel te kleine schaal. Mijn voorstel is daarom ook: er dienen vier overheidsinstellingen als proeftuin te worden aangewezen waar NORA op de millimeter wordt gevolgd. Als het aan mij ligt komen daarvoor in aanmerking: de Belastingdienst, Gemeente Rotterdam (met zware uitkeringsvraagstukken), Provincie Utrecht (met zware veiligheidsvraagstukken), Ministerie van Informatie en Technologie (oeps, ik kijk iets te ver vooruit).

Tussen opmerking aan het adres van de opdrachtgevers: Net zoals in de bouwkunde architectuur kunnen opdrachtgevers bij overheidsinstellingen ontwerpopdrachten uitschrijven om competitie en hogere kwaliteit in architectuur en ontwerpen te krijgen. Waarom wordt niet aan twee interne architecten teams en drie externe architecten teams gevraagd een architectuur en ontwerp te maken op basis van NORA voor een passende e-overheidsdienstverlening? En waarom kiest men dan niet voor het mooiste en beste architectuur en ontwerp? Opdrachtgevers: bij jullie begint alles!

Laatste opmerking: Ik ben blij dat NORA er is, maar we moeten wel gaan ontwerpen (met aansprekende visualisaties) om NORA te laten werken en te komen tot een samenhangende e-overheids-dienstverlening.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.46

Geschreven door Daan Rijsenbrij op 31-05-2009 10:16

Mark,

Je hebt gelijk dat het belangrijk is om de praktijkervaringen met NORA maar ook met GEMMA en wellicht MARIJ te evalueren en daaruit verbeteringen door te voeren. Het grote probleem, zoals ik reeds aangaf, ligt het ontbreken aan een degelijke governance.

Ik ben het ook met jou eens dat de discussie in eerste instantie op Via Nova Architectura zou moeten worden gevoerd omdat hier de kritische architecten zitten.
Ik zou ook graag praktijkcommentaar (positief en negatief) willen zien van architecten van de ZBO’s en grote uitvoeringsorganisaties.

Natuurlijk zou ik met een aantal goede architecten een degelijk conceptueel model in elkaar willen zetten, maar ik wil eerst zien dat daar echt vraag naar is. Het grote probleem met architectuur is dat het nog teveel een ‘push’-aangelegenheid is. De ‘pull’ vanuit het businessmanagement is nog nauwelijks aanwezig. Een ‘push’-benadering impliceert meestal dat bij de eerste tegenwind (zoals een kredietcrisis) er direct mee wordt gestopt.

Ook onderschrijf ik jouw oproep dat er meer aandacht mag worden besteed aan het ontwikkelingen van krachtige architectuurconcepten.

Het is een aardig idee als op LAC2009 praktijkervaringen met NORA en de andere overheidsreferentiearchitecturen als MARIJ, PETRA, GEMMA en WILMA worden gedeeld. Ik ben ervan overtuigd dat dat niet alleen leerzaam is voor de architecten in de publieke sector, maar ook voor architecten uit het bedrijfsleven. Immers NORA bevat ook veel onderwerpen die spelen in dat bedrijfsleven.

Ik ben zeer geïnteresseerd in jouw platenboek/bladerboek. Dergelijke boeken zullen de interesse voor NORA pas echt wakker roepen bij businessmanagers en topmanagement.

Ik deel jouw gedachten over beeldvorming (AS-IS, TO-BE, Envision). Ik noem dat de huidige architectuur, de architectuur voor over drie jaar (de gemiddelde duur voor een serieuze businesstransformatie) en de architectuur voor over tien jaar (een soort stip op de horizon).

Ik zou de architectuurprincipes niet alleen illustreren met een principeschets/principetekening waarmee de stakeholders beter inzicht krijgen in de impact van het betreffende architectuurprincipe, ik zou ook cartoons laten maken om het architectuurprincipe te ‘verkopen’ aan de business. Ik heb daar zeer goede resultaten van gezien bij een aantal grote ondernemingen.

Reagerend op jouw laatste opmerking constateer ik dat er gelukkig geen serieuze architecten meer zijn die de noodzaak van NORA nog ontkennen. Maar er moet meer vaart worden gemaakt, want de sense of urgency van ingrijpende businesstransformaties bij de overheid is zeer hoog. Dus ook de sense of urgency van een adequate richtinggevende architectuur!

Vriendelijke groet,
Daan.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.45

Geschreven door Corné Dekker op 02-06-2009 12:34

In het katern Strategie staat weinig waar ik het niet mee eens ben. Inderdaad een hele verbetering t.o.v. de eerdere versies waarin techniek het uitgangspunt leek.
Maar de genoemde bouwstenen betreffen slechts de overheidsbrede bouwstenen. Ik zou graag (bij voorkeur in de vorm van een schets) zien met welke organisatiebrede bouwstenen een bepaalde overheidsorganisatie het best kan aansluiten op die overheidsbrede bouwstenen. Zodat een overheidsorganisatie eenvoudig kan zien met welke organisatiebrede bouwstenen zij de komende periode aan de slag moet om haar informatievoorziening daadwerkelijk te verbeteren. En landelijke initiatieven ook rekening gaan houden met de aanwezigheid van deze organisatiebrede bouwstenen.
De belangrijkste organisatiebrede bouwsteen is het zaaksysteem waarin van alle voor burgers, bedrijven en andere overheidsinstellingen te leveren diensten de statuswijzigingen, de besluiten, het resultaat en de relevante documenten worden vastgelegd.
Zoals basisregistraties bedoeld zijn om basisgegevens in een keten uit te wisselen, kunnen zaaksystemen worden gebruikt om gegevens over processen uit te wisselen.
Zo wordt het heel eenvoudig in een keten alle zaken van één persoon op te vragen. Maar door sub- en vervolgzaken (door een behandelaar gestarte zaken vanuit een bestaande zaak) ook tussen verschillende overheidsorganisaties toe te passen, ontstaat optimale ketenintegratie. Heeft men bij een aanvraag evenementenvergunning bij een gemeente bijvoorbeeld een advies van de politie nodig, dan maakt het zaaksysteem van de gemeente geautomatiseerd een subzaak bij de politie aan. De behandelaar bij de gemeente kan als aanvrager van de subzaak, vanuit het zaakdossier van de evenementenvergunning, de status en het resultaat van het advies van de politie zien.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.45

Geschreven door Erik Saaman op 08-06-2009 14:00

In aanvulling op de bijdrage van Daan, de definitieve versie van het besproken NORA-katern Strategie is te vinden op:

www.noraonline.nl/Documenten%20NORA%2020

Hier staat ook een apart document met een korte verantwoording voor de gemaakte keuzes.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.45

Geschreven door op 15-06-2009 01:58

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.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.45

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.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.45

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.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.45

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.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.44

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.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.43

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.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.43

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.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.42

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.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.42

… 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.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.41

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.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.41

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.

Steven van ’t Veld
Steven.van.t.Veld@AIM.nl

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.41

Geschreven door Daan Rijsenbrij op 15-06-2009 13:22

Steven,

Met veel interesse heb ik jouw waardevolle commentaar gelezen. Zeer inspirerend, ik denk echter dat het wezenlijke verschil tussen ons kleiner is dan het lijkt. Ik gebruik - doordat mijn achtergrond iets anders is dan de jouwe - wat woorden die bij jou een andere klank oproepen dan ik bedoel.

Het zou overigens interessant zijn als de overheid eens een stevig project start (denktank) waarin vier à vijf seniore deskundigen (architecten/informatiekundigen) conceptueel mogen nadenken over een e-overheid en de architectuurconsequenties daarvan.

Voorts mis ik bij de totstandkoming van overheidsbrede architectuur de Digitale Rijksbouwmeester waar ik al sinds mijn tweede oratie voor pleit. Maar daarover volgende week.

Vriendelijke groet,
Daan.

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.41

Geschreven door op 15-06-2009 13:50

Beste Daan,

Graag gedaan. Uiteindelijk kunnen onze meningen niet ver uit elkaar liggen omdat het in principe immers om hetzelfde gaat. Ons beider aanvliegroute is echter stevig anders, zodat ons beeld van het geheel, incl. de bewoordingen die we gebruiken, ook anders is. Maar dat maakt het ook interessant.

Zoals je weet zie ik niet zoveel in een Digitale Rijksbouwmeester omdat ik niet geloof dat informatie techniek ergens leidend moet zijn. Misschien dat je een expertise centrum voor informatie techniek kunt hebben waar men kan buurten als men naar oplossingen zoekt. Om diezelfde reden zie ik ook absoluut geen minister of staatssecretaris van informatie techniek zitten. Zo'n super projectleider/programmamanager lijkt me vooral op decentraal niveau van groot belang, al of niet als onderdeel van de overheid, maar niet centraal.
Waar wel erg veel behoefte aan is is een topmanager van de behoefte aan informatie van de overheid met een rechterhand die de kennis van de informatie van die overheid beheerd. Daarmee zou de inzet van IT onder strakke regie gebracht kunnen worden, en een vermogen bespaard kunnen worden terwijl de effectiviteit toch groter wordt. Zie mijn bovenstaande reactie. Maar zoiets past eigenlijk niet bij de huidige invulling van wat een CIO en wat een architect doet, tenzij die termen vooral en alleen rond IT management en IT advies gebruikt zouden worden, op tactisch/operationeel niveau dus.

Als de overheid hulp nodig heeft dan lijkt het me leuk om die hulp te geven. Ik zie dan niet zoveel in een volgende praat en denkgroep, maar meer in een groep die echt meters maakt en gestelde doelen haalt. Ik laat me graag verrassen.

Met vriendelijke groet,

Steven van 't Veld
Steven.van.t.Veld@AIM.nl

Reactie van Stichting Digital Architecture op 1 Juni 2012 op 11.40

Geschreven door Corné Dekker op 15-06-2009 14:28

Hallo Steven en Daan,

Geen minister of staatssecretaris van informatie TECHNIEK, maar wél van informatie. Of nog beter: van dienstverlening.

Het lijkt me sowieso dringend gewenst om dit onderscheid duidelijk te maken. Zolang de informatievoorziening van overheidsorganisaties slecht op elkaar is afgestemd, moeten we niet teveel energie in de techniek steken.

Overigens om dezelfde reden helemaal met Steven eens dat technische middleware vooral complexiteit toevoegt aan de bestaande infrastructuur.

Zolang elk organisatieonderdeel zelf haar informatievoorziening mag inrichten (landelijke sturing door een Rijksbouwmeester Informatievoorziening ontbreekt helaas, maar zelfs organisatiebrede sturing ontbreekt veelal), is deze sterk verkokerd georganiseerd. Organisatieonderdelen houden geen rekening met andere organisatieonderdelen die voor een groot deel vergelijkbare werkzaamheden uitvoeren.

Elk organisatieonderdeel schaft haar eigen procesondersteunende toepassing aan, zonder rekening te houden met in de organisatie reeds aanwezige toepassingen.

Dit leidt niet alleen tot een zeer slechte informatievoorziening, deze is bovendien onnodig duur. Dezelfde gegevens worden op talloze plaatsen vastgelegd en onderhouden. Vergelijkbare functionaliteit wordt talloze keren aangeschaft.

Starten dus met de informatievoorziening te verbeteren door per overheidsorganisatie generieke instrumenten verplicht te laten gebruiken door alle afdelingen. Ik zou het toejuichen als een Rijksbouwmeester Informatievoorziening overheidsorganisaties verplicht generieke instrumenten in te zetten.

Dat maakt afstemming tussen overheidsorganisatie in een volgende fase minder complex.

Dat zou wat mij betreft de kern van de NORA moeten zijn.

Vriendelijke groet,

Corné Dekker

Sponsoren

Sessies

17-04: GIA sessie over data-driven multi-channel marketing meer...

26-04: KNVI sessie over Architecture Mining meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden