Daan Rijsenbrij heeft in zijn forumartikel een kritische beschouwing gegeven over NORA, een referentie informatiearchitectuur over de samenhang en samenwerking tussen en binnen de Nederlandse elektronische overheid.

Op een aantal van de door hem genoemde kritiekpunten wil ik graag ingaan aan de hand van een van NORA afgeleide informatiearchitectuur.

In het kader van de Wet Maatschappelijke Ondersteuning (Wmo), zijn kortweg gezegd, de gemeenten verantwoordelijk geworden voor het organiseren van een deel van de thuiszorg. Mede t.b.v. de hiermee gepaard gaande nieuwe administratieve- financiele en bedrijfsprocessen is op basis van NORA hiervoor een startinformatiearchitectuur ontwikkeld.

In dit ontwerp is een startarchitectuur als volgt gedefinieerd:
"De startarchitectuur is een denkkader. Het is een eerste aanzet om inzichtelijk te maken hoe de Wmo op verschillende niveaus samenhangt.

Tevens

"Een startarchitectuur: beschrijft op pragmatische en realistische wijze de (keten) processen, de wenselijkheden / mogelijkheden tot (landelijke) standaardisatie van gegevens, gegevensmodellen en berichtenverkeer."

En dient primair drie doelen:

Gemeenschappelijke taal, inzicht in functionele (on)mogelijkheden, aanreiken van technische " bouwblokken"
(uit nota startarchitectuur, CapGemini 2005)

Bovenstaande definities legt de focus op drie aspecten: communicatie met de omgeving en het centraal stellen van het proces en een "gemeenschappelijke taal"

In essentie is hier in mijn opinie de kern van een architectuur neergezet. Het is daarom vooral de_script_ief bedoeld. Een goede i-architectuur maakt allereerst duidelijk: "hoe de vork in de steel zit", hoe informatiestromen, processen en verantwoordelijkheden zich verhouden tot elkaar. Toch zijn er wel degelijk pre_script_ieve elementen te benoemen. Ik zal daar later nader op ingaan.

Laten we eerst eens schematisch weergeven hoe de processen en communicatielijnen er in de Wmo uitzien:

http://www.pyrrho.info/contextwmo.mht

Dit schema maakt direct duidelijk hoe complex de informatiestromen zijn, die in het kader van de Wmo moeten worden gestandaardiseerd en geautomatiseerd. Een dergelijk schema schetst is eerste instantie de samenhang tussen de verschillende actoren en is een onmisbaar gegeven voor de daarop ge_base_erde architectuur.

De Wmo geprojecteerd op de NORA levert onderstaande schematische voorstelling van de architectuur op:

http://www.pyrrho.info/norawmo.mht

Deze startarchitectuur focust dus op de maatregelen die de gemeente moet treffen om de dienstverlening aan de burger mogelijk te maken. Bijvoorbeeld het maken van prestatieafspraken met ketenpartners over de kwaliteit van dienstverlening of het inrichten van procesbewaking, zodat ook binnen een acceptabele termijn een voorziening wordt verstrekt aan de hulpvrager. Een gemeenschappelijk denkkader (zoals deze startarchitectuur wordt getypeerd) helpt de gemeenten, naar mening van de auteurs, om adequate en in eerste instantie pragmatische, technisch werkbare oplossingen te realiseren. Deze oplossingen zijn per gemeente verschillend, omdat ook de uitgangssituatie per gemeente verschilt. Een startarchitectuur hoort daarom generiek, maar, waar mogelijk, zo flexibel mogelijk te worden opgezet.

Anders gezegd een startarchitectuur vertrekt paradoxaal genoeg niet vanuit een start-, zeg maar beginsituatie, maar biedt een theoretisch en flexibel kader binnen een staande infrastructuur. De feitelijke situatie is immers, dat er allerlei functionele informatiesystemen operationeel zijn binnen de bij de uitvoering van de Wmo betrokken sectoren (gemeenten, zorgaanbieders, belastingsdienst etc.).

Er is dus sprake van zeer aanzienlijke "sunk costs" en softwareleveranciers die die systemen leveren zijn daarmee effectief actoren in de communicatieketen te noemen. Zij dienen er immers voor te zorgen, dat de systeemsoftware tijdig wordt ge-update, aangepast aan de nieuwe functionele eisen en uitgerold en dat personeel dat met de implementatie van de nieuwe systemen belast is, wordt geschoold en begeleid.

Daan Rijsenbrij vindt dat het bedrijfsleven niet vertegenwoordigd is, met het betrekken van de softwareleveranciers, dat moge op zich juist zijn, maar met bovenstaande heb ik trachten aan te geven dat het betrekken van de softwareleveranciers wel degelijk zeer belangrijk is in het ontwerp van een architectuur vanuit van overheidswege opgelegde en te implementeren wet- en regelgeving.

Waar de overheid wel pre_script_ief zou moeten zijn is in het opleggen van standaarden en daarmee het creeren van een gemeenschappelijke taal. Niet voor niets is "eenheid van taal" een hoofddoelstelling van de startarchitectuur Wmo. Een simpel gegeven als het hanteren van dezelfde berichtstandaarden, definities en coderingen is al moeizaam genoeg tot stand te brengen.

Het doorlezen van de berichten rond het thema NORA wekken een bekend gevoel bij me op. Ik heb me ook een tijdje bezig gehouden met het plaatsen van NORA binnen het overheidsdomein. Dat betekent dat je meewerkt aan de review. En na elke reviewsessie merkte ik dat de NORA buitengewoon geschikt is om onder uit te halen. Ook als je dat niet wilt.

Ook nu zie je weer dat, met de beste bedoelingen, een beeld wordt neergezet waarbij de oppervlakkige lezer makkelijk kan denken "non de_script_, te veel omhaal van woorden, onvoldoende sturend, ... dat k_link_t als een beleidsstuk waarbij het me veel tijd zal schelen als ik het ga negeren".

Ik kan me heel goed vinden in heel veel van de opmerkingen die bij NORA worden geplaatst. NORA is een "bundelstuk" in feite een soort "monster van frankenstein" waarin geprobeerd is om alle relevante overheidspogingen om tot generieke principes te komen aan elkaar zijn gebreid. Het stuk moet consensus verhogend zijn... dus wordt er wat voorzichtig om de harde kaders een gewerkt. Het beschrijft hoofdzakelijk een (nog bijna helemaal te realiseren) architectuur tussen overheidsorganisaties, de "interne" architectuur blijft dus grotendeels buiten schot.

Maar je moet jezelf altijd die utlieme gewetensvraag stellen: had ik het beter gedaan? Antwoord: nee, helemaal niet.
- Ik had niet het geduld gehad om dit allemaal samen te stellen. In een zee van scepsis... Ik wordt al moe van de gedachte.
- Ik had niet aan de verleiding kunnen weerstaan om het document veel sturender en "harder" te maken, waardoor er in de overheidsla met politiek incorrecte plannen zou belanden.

Nu zie je dat overheidsorganisaties wel degelijk kijken naar de NORA (zie ook de project van WMO op NORA). Dat men in ieder geval gaat stellen dat iets in overeenstemming moet zijn met de NORA (ook al weet men nog niet precies wat dat betekent).

Dit is dus geen wetenschappelijke of erg inhoudelijke reactie. Meer een oproep. De NORA is misschien nog een wat lelijk beestje maar laten we besluiten er van te gaan houden. Dan hebben we altijd nog de evolutie achter de hand om er iets van te maken. Per slot hadden we ook niet verwacht dat een schimmelig dinosauriertje met wat huidflappen nog eens magistraal zou gaan vliegen.

Functioneel ontwerp of informatie architectuur?

Ik heb met belangstelling de bijdrage van Ruud Zondervan gelezen.

Het is zeer goed dat de start informatiearchitectuur gemaakt is. Zeker als ik de primaire doelen lees en de visualisaties bekijk. Ook is het interessant om te zien hoe NORA gebruikt is als basis voor het maken van een ontwerp. En ik was dan ook zeer benieuwd om te lezen hoe dat is gebeurd.

Ik geef hierbij echter mijn kritische kanttekeningen bij wat als WMO-start-architectuur is gepresenteerd.

Ik heb er namelijk moeite mee om deze 'start informatiearchitectuur' als een architectuur te zien. Als ik naar de gegeven definitie van architectuur kijk, dan komt de start-architectuur op mij over als een geheel van functionele specificaties en een 'globaal' functioneel ontwerp. Met deze constatering geef ik ook impliciet aan dat de architectuurstap wellicht is overgeslagen.

Hieronder maak ik duidelijk waarom ik tot deze beschouwing kom.

De definitie die ik in mijn promotieonderzoek hanteer, heb afgeleid van bouwkundige architectuur en met vele cases in de praktijk heb verfijnd en getoetst, is:
Architectuur is een ander woord voor bouwkunst of bouwstijl. Een architectuur van een systeem, zoals een organisatiedomein of een integrale oplossing, is het geheel van toegepaste principes, richtlijnen, standaarden en voorschriften afkomstig uit de gehanteerde stijlen en concepten voor de constructie, ontwikkeling en verandering van een systeem. Het toepassen van ontwerp- en bouwstijlen resulteert in een constructie van een systeem dat zelf weer uit bepaalde (type) onderdelen en relaties tussen onderdelen bestaat.

Een architectuur biedt een opdrachtgever sturing en controle op de integrale kwaliteit van een te ontwikkelen systeem. Bijvoorbeeld controle en sturing op kwaliteiteisen zoals de verlaging of beheersing van de complexiteit van het systeem, een flexibel systeem, een integreerbaar systeem, een bestuurbaar systeem of een duurzamer systeem.

Als ik vanuit mijn definitie voor architectuur kijk naar de definitie van de WMO-startarchitectuur dan valt mij op dat in de definitie al expliciet (en niet limitatief) onderdelen van een te bouwen systeem worden genoemd: processen, gegevens en berichten. In feite de constructie van het systeem. Deze onderdelen zouden in mijn ogen het resultaat van het toepassen van bepaalde principes moeten zijn. In de definitie hadden ook net zo goed de volgende onderdelen kunnen staan: functies, services, applicaties en interfaces.

Het hanteren van deze WMO-architectuur definitie zorgt dan al gauw voor het niet onderbouwen van de keuze voor deze onderdelen op basis van stijlen, concepten en principes. Deze definitie draagt in feite een template aan waarbij de onderdelen van het systeem functioneel kunnen worden beschreven in lijn de met de daaraan gestelde eisen. Echter waar wordt dan bepaald welke onderdelen naast de drie genoemde onderdelen moeten worden beschreven?

Wat ik verder lees in de verstrekte informatie van de WMO en wat waarschijnlijk is gebeurd, is het vullen van de template: De processen, gegevens en berichten zijn ingedeeld en op elkaar afgestemd en in samenhang met elkaar gebracht.

De definitie van de startarchitectuur bevat ook het woord: beschrijft. En dat is onhandig gekozen. Een architectuur beschrijft niet. Een architectuur geeft sturing en beperkt ontwerpruimte, maar het beschrijft niet. Een architectuur is niet het geheel van standaarden en processen, maar leidt juist tot standaardisering en ontwerp van bepaalde processen, vanwege de toepassing van principes.

Het woord principe is wat dat betreft een grote afwezige in de WMO-bijdrage.

Als ik kijk naar het doel van de startarchitectuur dan mis ik daar het kwaliteitsaspect van het te ontwikkelen WMO-systeem. Het gegeven primaire doel is overigens eerder een gewenst resultaat. Als primair doel voor de WMO-architectuur zou ik graag geformuleerd zien staan: Het doel van de WMO-architectuur is dat men een WMO-systeem kan ontwikkelen waarbij men een continue operatie van financiele en administratieve processen kan garanderen inclusief een optimale afstemming tussen de verschillende overheidsorganen.

Als ik verder kijk naar de verstrekte informatie over de startinformatiearchitectuur voor WMO, dan zie ik dat:
1. Er is gekozen voor procesmatig werken als concept
2. Er is gekozen voor geautomatiseerde ondersteuning van de processen
3. Er is gekozen voor integriteit en consistentie voor gegevens vanwege de nadruk op gegevensmodellen
4. Er is gekozen voor het uitwisselen van gegevens door middelen van berichten
5. Er is gekozen voor controle op informatiestromen
6. Er is gekozen voor "technische blokken"
7. Er is gekozen voor gemeenschappelijke taal
8. Er is gekozen voor het treffen van maatregelen om als overheid dienstverlening richting de burger mogelijk te maken, zoals prestatie afspraken met leveranciers
9. Er is gekozen voor het treffen van maatregelen om als overheid dienstverlening richting de burger mogelijk te maken zoals inrichting van de procesbewaking

Al deze keuzes ondersteun ik, maar ze dienen te worden onderbouwd in een architectuurdocument op basis van kennis en ervaring in het hanteren van bepaalde principes, concepten en stijlen voor constructie, ontwikkeling en verandering. En ik zou graag willen weten of dat is ook gebeurd.

Wat zijn de WMO-principes die leiden tot bovenstaande keuzes? Waarom is bijvoorbeeld het concept 'procesmatig werken' een goede oplossing voor het voorliggende vraagstuk?
Bovenstaande keuzes in de lijst geven een indicatie welke principes, stijlen en concepten voor de constructie, ontwikkeling en verandering voor WMO zijn gebruikt. Maar niet meer dan een indicatie.

Ik maak vaak onderscheid tussen pionieren en architectureren. Architectureren is dat men op basis van kennis en ervaring van in de praktijk bewezen stijlen, concepten en principes een systeemontwerp maakt. Bij pionieren doet men precies hetzelfde alleen zijn de gehanteerde stijlen, concepten en principes niet bewezen in de praktijk. Pionieren is zeer belangrijk en waardevol. Als we het echter hebben over het ontwerpen van nieuwe administratieve- financiele en bedrijfsprocessen bij de overheid, dan denk ik zelf dat we eerder moeten architectureren dan pionieren.

Het is heel belangrijk dat een functioneel ontwerp wordt gemaakt, en dat dit ontwerp samenhang geeft en een gemeenschappelijk begrippenkader biedt.

Is met de startarchitectuur voor WMO nu de architectuurstap gezet of nog niet?

Reagerend op Gijs Hoek wil ik benadrukken dat mijn opmerkingen opbouwend zijn bedoeld; opmerkingen om mee te nemen in het schrijven van NORA 3.0.
Als de NORA 'consensus verhogend' dient te zijn, zoals hij stelt, dan is er des te meer reden om het zeer compact te houden. Lange notities zijn vaak multi-interpretabel, en consensus over een multi-interpretabele notitie lijkt mij hoogst onwaarschijnlijk.

Gijs Hoek stelt zich zelf de gewetenvraag: had ik het beter gedaan? Zijn antwoord luidt neen.
Mijn antwoord luidt ja.
Natuurlijk kost het veel geduld en overredingskracht om bij een dergelijk complexe organisatie als de overheid iets zo cruciaals als een architectuur te formuleren.
Maar, zoals ik op 31 augustus reeds aangaf, zou ik beginnen een expliciete visie op de gewenste toekomstige digitale samenleving te formuleren, gevolgd door de daarin passende visie op de gewenste toekomstige digitale overheid.
Etaleer beide visies heel breed, via het internet, zodat elke burger de mogelijkheid heeft om laagdrempelig zijn commentaar te geven. Daarna kan op basis van deze visies de overheidsarchitectuur worden geformuleerd. Ook deze dient breed te worden geetaleerd.
Acceptatie van digitale architectuur is geen vanzelfsprekendheid, architectuur moet worden verkocht aan de stakeholders. Dus voeg aan het NORA 3.0 team PR-deskundigen toe en maak de afstemming met de stakeholders speelser.
Het einddocument zou ik door een commerciele uitgever laten uitgeven. Dat borgt de leesbaarheid van het document.

Op de bijdrage vanuit het project WMO heeft Mark al gereageerd. Ik heb echter ook een aantal overheidsorganisaties gezien die werken volgens de NORA. En dat betekent vaak dat de NORA principes zijn opgesomd in een bijlage. Als ik dan probeer te ontdekken welke NORA principes waar zijn toegepast met welke impact, dan wordt dat een moeilijke zaak. Architectuurprincipes beperken de ontwerpruimte. Bij het toepassen van NORA zal je dus impact moeten zien op het ontwerp van het onderhavige systeem.

Natuurlijk moeten wij de NORA accepteren zoals het nu is, er zit immers heel veel overlegwerk in. Ik zou echter wensen dat NORA 3.0 een stuk concreter wordt.

Ik vind het trouwens jammer dat ik in deze discussie nog geen enkel tegengeluid heb mogen horen van het 9-koppige auteursteam noch van de grote review-groep die in het NORA 2.0 document staat vermeld op de pagina's 178 en 179. Maar misschien wachten zij net als ik op Prinsjesdag om te weten wat Jan Peter voor ogen heeft met de overheidsautomatisering. Ik heb mij in ieder geval vast ingeschreven voor het Landelijk Architectuur Congres 2007, waarbij in track 8 op 22 november de NORA zal worden bediscussieerd door ICTU.

De evolutie: Tien punten waarop NORA beter kan en moet scoren.

Mark Paauwe

Inleiding
Bij deze reageer op de prikkelende bijdrage van Gijs Hoek.

Gijs Hoek stelt de vraag: had ik het beter gedaan? Zijn antwoord luidt neen. Mijn antwoord luidt, net als bij Daan Rijsenbrij: ja.

Bij deze geef in het kort aan op welke tien punten in mijn ogen NORA beter kan en moet scoren:
1. De naam, scope en doel van NORA
2. De te hanteren architectuurdefinitie
3. De te hanteren uitgangspunten voor een referentie architectuur
4. De te hanteren principedefinitie
5. De te hanteren indeling van categorieen voor principes
6. De te hanteren principes
7. Het te onderkennen programma van eisen
8. Het onderkennen van een impact analyse
9. De te onderkennen architectuurstijl-beschrijving voor een service georienteerde mid-office voor IT-omgevingen
10. Het te onderkennen architectuurontwerp voor het digitale systeem van overheidsorganen in Nederland

De uitwerking
Hieronder worden de bovenstaande tien punten uitgewerkt.

1. De naam, scope en doel van NORA
Het digitale systeem dat digitale overheidsdienstverlening (services) moet bieden (ergens in e toekomst) omvat delen van het bedrijf, de informatievoorziening en de IT-infrastructuur van overheidorganen. Echter de besturing (en verantwoordelijkheden) van deze digitale systemen mag niet buiten de scope van NORA worden gelaten. De overheidsorganen per stuk zijn instellingen of ondernemingen. De overheidsorganen samen zijn een megastructuur. Het succes van (service)ketens in een megastructuur hangt af van de mate waarop de besturing van de instellingen en ondernemingen samenwerken.

Om het digitale systeem van de overheid te kunnen ontwerpen en bouwen is een overall architectuurontwerp nodig van het digitale systeem met een horizon. De naam van het NORA document zou moeten worden: Architectuurontwerp Digitale Overheid 2010.

In dit architectuurontwerp moet een eenvoudige ontwerpschets worden gemaakt waarin de verschillende overheidsorganen, hun organisatiedomeinen, met verantwoordelijkheden, eigenaarschap en de betreffende keten zichtbaar zijn gemaakt. Met deze visualisatie kan men goed de scope van NORA communiceren.

Het doel dat NORA zou moeten gaan dienen is:
De opdrachtgevers, voor het komen tot digitale dienstverlening door overheidsorganen, dienen met het architectuurontwerp voor de digitale overheid 2010, controle te krijgen op integrale kwaliteitseisen zoals beveiligbaarheid, complexiteit, beschikbaarheid en bestuurbaarheid.

2. De te hanteren architectuurdefinitie
Er mag in een referentie architectuur geen nieuwe definitie, vertaling of interpretatie van een definitie worden gebruikt. In de gehanteerde architectuurdefinitie wordt architectuur als een beschrijving neergezet. Dit is in mijn ogen onterecht. Het lijkt of er een vertaalfout is gemaakt van de Engelstalige IEEE 1471 definitie naar de Nederlandstalige definitie. Zie hieronder de Engelstalige definitie.
'Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution'. Waar staat hier het woord beschrijving?

3. De te hanteren uitgangspunten voor een referentie architectuur
Een referentie architectuur mag niet speciaal zijn ontworpen voor het systeem waar de architectuur als referentie voor moet worden gebruikt. De referentie architectuur moet generiek zien, anders is het geen referentie architectuur meer, maar een specifieke architectuur. Een referentie architectuur dient in mijn ogen te verwijzen naar in de praktijk bewezen stijlen, concepten en principes voor ontwerp en bouw van een systeem. In NORA zouden in feite alleen maar verwijzingen hoeven te staan. Maar dat is niet mogelijk daar in NORA nieuwe zaken staan.
In een referentie architectuur voor het digitale systeem van overheidsorganen staat welke stijlen, concepten en principes gangbaar zijn om te gebruiken bij het ontwerpen en bouwen van
In mijn ogen is NORA geen referentie architectuur.

4. De te hanteren principedefinitie
Er is geen definitie overgenomen of gegeven voor de term principe in het NORA-document. Dit zorgt ervoor dat er geen goede externe kwaliteitstoets kan plaatsvinden op de formulering van de onderkende principes. Dit heeft, gezien mijn definitie voor principes, geleid tot het onderkennen van wensen, eisen en functionele specificaties.

5. De te hanteren indeling van categorieen voor principes
In mijn vorige bijdrage over NORA-principes staat aangegeven welke categorieen in mijn ogen ontbreken voor principes. Men had in het architectuurdocument beter een in de praktijk bewezen domeinenmodel kunnen gebruiken voor het bedrijf, de informatievoorziening en de IT-infrastructuur. Per domein had men de principes kunnen achterhalen. Van het domeinenmodel kan men een visualisatie maken, genaamd structuurvisie, die in elk architectuurdocument thuishoort.

6. De te hanteren principes
In mijn vorige bijdrage staat te lezen dat de wensen en eisen van belanghebbende niet als uitgangspunt voor principes moeten worden gebruikt, want dan krijg je uitgangspunten, globale wensen en eisen als principes. Uitgangspunten zijn veronderstellingen die men voor waar aanneemt, en principes zijn wetmatigheden.
Principes moeten voortkomen uit stijlen en concepten voor constructie, ontwikkeling en verandering van systemen en van een juist abstractieniveau zijn.
Voorbeeld van een goed principe voor NORA is: Geautomatiseerde dienstverlening zorgt voor een hogere beschikbaarheid van de dienstverlening, dan wanneer mensen onderdeel vormen van de dienstverlening.

7. Het te onderkennen programma van eisen
In het NORA document staan uitgangspunten, functionele specificaties, wensen en eisen die in mijn ogen allemaal van groot belang zijn voor de belanghebbenden. Deze zaken horen echter niet thuis in een architectuurdocument, maar in een programma van eisen.
Ook kunnen tegenstrijdige wensen en eisen van verschillende belanghebbenden, besluiten, wet- en regelgeving, beter op elkaar worden afgestemd in een programma van eisen.
Om een programma van eisen te kunnen maken, dienen de belangrijkste opdrachtgevers een visie te ontwikkelen met een horizon op IT-gebied en met name op kantoorautomatiserings-gebied. Hiervoor dient men een document op te stellen genaamd: IT-visiedocument. Elk overheidsorgaan in Nederland zou op dit moment een IT-Visie 2010 document dienen te hebben

8. Het onderkennen van een impact analyse
Nadat het programma van eisen is gemaakt dient eerst de haalbaarheid en wenselijkheid van de impact (omvang van verandering, tijdspad, geld, verstoring van dienstverlening) van het programma van eisen te worden beoordeeld. Hiervoor is ook al architectuurinzicht nodig (van de huidige architectuur).
NB: Daarom is het bijna ondoenlijk om een onderbouwde TO-BE architectuur te maken als er geen AS-IS-architectuur beschikbaar is om de impact te bepalen van de wensen en eisen.

9. De te onderkennen architectuurstijl-beschrijving voor een service georienteerde mid-office voor IT-omgevingen
Uit de inhoud van NORA lijkt dat men voorkeur heeft voor een service gerichte mid-office architectuur voor IT-omgevingen. De stijlen, concepten en principes voor het ontwerp en de bouw van een dergelijke IT-omgeving zouden apart in een architectuurstijl-document dienen te staan. Waarom juist nu serviceorientatie als concept gebruiken? Waarom juist nu mid-office als concept gebruiken? Dit architectuurstijl document zou hier het antwoord op kunnen geven.
Hier blijkt in mijn ogen dat NORA geen referentie architectuur is, maar een architectuurontwerp voor IT-omgevingen bij de overheid (waar nog een groot gedeelte van een programma van eisen in staat, en belangrijke architectuurbouwstenen in ontbreken).

10. Het te onderkennen architectuurontwerp voor het digitale systeem van overheidsorganen in Nederland

In een architectuurontwerp horen in mijn ogen de principes uit de architectuurstijl beschrijving te worden toegepast op de hierboven genoemde domeinen (inclusief de besturing), zodat het programma van eisen kan worden gerealiseerd en de opdrachtgevers controle hebben over de integrale kwaliteit (via kwaliteitsaspecten).

Het document dat nu NORA heet en is, zou architectuurontwerp dienen te worden genoemd.
Men heeft namelijk principes toegepast die leiden tot een constructie.

In het architectuurontwerp zou men per type overheidsorgaan een ander architectuurontwerp moeten maken.

Tenslotte
Ik verneem graag van de auteurs van NORA en van de posters in dit forum wat ze vinden van deze in mijn ogen praktische en haalbare verbeterpunten voor NORA.

Mark Paauwe " This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

Post edited by: mpaauwe, at: 2007/09/04 10:49

We hebben een boeiend onderwerp bij de staart...

Voordat ik toe ga werken naar mijn conclusie dat er heel goede ideeen worden geopperd om de NORA naar een strakker en werkbaarder niveau te krijgen. Eerst nog een wat ergerlijker mening:

Ik denk dat dhr. Rijsenbrij en Paauwe NIET een betere NORA 2.0 hadden kunnen maken. Het "richten" van de NORA, zoals beide heren duidelijk onder woorden brengen in hun posts, is intimiderend voor een (overheids)organisatie. Commitment aan een document dat echt een kaderstellende architectuur is met (zeker voor management) moeilijk inschatbare consequenties voor de bedrijfsvoering... Je roept ontwijkingsgedrag op. Inhoudelijke kwaliteit kan wel degelijk botsen met effectiviteit. Waar het woord "effectiviteit" hier vooral betekent: "in leven blijven".
Ik denk dat de NORA 2.0 de juiste sfeer heeft voor dit moment. (Nou ja, ik ben het eigenlijk wel met Rijsenbrij eens dat een journalistieke redactie geen kwaad had gedaan... Met de term "voor en door architecten" lijkt vooral te zijn bedoeld dat het document alleen door architecten leesbaar is... )

Maar het goede nieuws: ik ben er van overtuigd dat dhr. Rijsenbrij en Paauwe een geweldige bijdrage kunnen leveren aan een NORA 3.0!
En ik ben het ook helemaal eens met de oproep om het gesprek te openen. Want: politiek geschipper, OK, maar zorg altijd dat het intellectuele debat in leven blijft.

Een suggestie. Aan het eind van het LAC (speakerscorner, tweede dag, vlak voor de borrel, niet te zwaar maken dus...) hebben we misschien een goede kans om dat debat eens te vieren. Bijvoorbeeld met als thema: de drie belangrijkste stappen die de NORA moet maken op weg naar versie drie. Ik zag dat in ieder geval dhr. Rijsenbrij er is. Ik weet misschien nog wel iemand uit het ICTU/NORA kamp om te vragen om mee te doen (en jullie vast ook wel). Die speakerscorner kan ik waarschijnlijk wel regelen... Verder geen agenda (wij en ik houden ons op de achtergrond).

Laat het even weten!

This e-mail address is being protected from spam bots, you need JavaScript enabled to view it