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