Blog

NORA 3.0 Review

NORA is een van de beste initiatieven die ik ken op architectuurgebied. NORA kan een nieuw stukje identiteit worden van Nederland waarmee we ons internationaal kunnen etaleren. Maar daar moet nog wel een extra stap voor worden gezet, namelijk de juiste eerste stap: wat is de vraag?  

Het is belangrijk dat Nederland een goed geoliede e-overheid krijgt, en wel snel. Waarom is dat zo belangrijk en waarom moet dat snel?

Ten eerste: De huidige wijze waarop de overheid werkt is inefficiënt. Er gaat veel tijd, geld en kwaliteit bij het leveren van diensten verloren omdat er nog onvoldoende gebruik wordt gemaakt van informatie als productiefactor. Dat weet iedereen en onderkend bijna iedereen.

Ten tweede: Als een bedrijfstransformatie en een IT-innovatie te lang duurt, is het steeds moeilijker om er centrale sturing op uit te voeren en om ervoor te zorgen dat het een integraal, duurzaam en toekomst geheel wordt. De transformatie kan uiteenvallen in zelfstandige goedbedoelde suboptimalisaties. Alleen al daarom is voor mij NORA zo belangrijk.

We hebben nog steeds in Nederland kans op een duurzame, functionele, toekomstvaste en integrale e-overheid. Deze is er nu nog niet. Om die mooie e-overheid wel te krijgen moeten we bij NORA nog meer gaan denken en werken in vier fasen en vier mijlpalen. Er moet een eenvoudig strak omlijnd plan komen dat op 1 a4-tje past, zoals hieronder staat:

Fase 1 -(zevental-projecten): Opstellen van eisen door opdrachtgevers (bestuurders van alle overheidsorganen en belanghebbenden) in een programma van eisen (wat willen alle belanghebbenden nu nastreven in het belang van de burgers, bedrijven, economie en milieu met de overheidsorganisaties, informatievoorziening en infrastructuur in termen van kwaliteitsaspecten, uitgangspunten, bedrijfsdoelen, functionele eisen ?). In de tweedekamer moet bijvoorbeeld een overbekende IT-politicus zich met het PVE (in pamflet vorm) willen profileren.

Fase 2 -(zevental -projecten): Definitiestudie (begrippenkader) en architectuur opstellen door architecten (met welke concepten, architectuurprincipes en stijlelementen is het realiseren van bepaalde kwaliteitsaspecten voor de in het PVE genoemde elementen mogelijk?). Als nieuwerwetse oplossingen worden gebruikt in de architectuur dan kan dat alleen na voldoende proofs-of-concepts. Aan het eind van de fase hebben we nog alleen maar een architectuurontwerp document. Een hoofddocument van max tien pagina's met minimaal twee plaatjes: een blauwdruk voor over drie jaar en een artist impression van de verre toekomst. Maar architectuur kun je niet eten, dus er moet nog iets worden gemaakt in de volgende ronde (onder deze randvoorwaardelijke architectuur).

Fase 3 -(zevental -majeure projecten): Onder architectuur ontwikkelen (analyseren en ontwerpen, bouwen of realiseren) van de verschillende e-overheids stijlelementen (bouwwerken) zoals bedrijfsdelen, informatievoorzieningsdelen en infrastructuurdelen. Het architectuurdocument uit de vorige fase is het voorschrijvende en dwingende kader. Geen mits tenzij of management exception letters. Immers het PVE moet worden gerealiseerd, en daar was de architectuur randvoorwaardelijk voor. Waar ik al heel lang aan denk is bijvoorbeeld elementen zoals shared service centra waar middelgrote en kleine overheidsinstellingen voor hun ICT op kunnen in prikken. (weg met die onzin dat iedereen zijn eigen ICT-services organisatie zit te bouwen).

Fase 4 -(zevental projecten): Transformeren van overheidsorganisaties van de huidige situatie naar de toekomstige en gewenste situatie door onder andere het implementeren van de in de vorige fase gebouwde elementen. Aan het eind van deze fase zijn enkele overheidsorganisaties voor bepaalde thema's e-overheid-compliant.

De vier genoemde fasen zullen parallel moeten worden uitgevoerd voor verschillende thema's om NORA als een gecontroleerde trein van de overheid een e-overheid te maken. Als er niet voldoende gefaseerd wordt gewerkt op basis van programma's van eisen zal NORA grote kans blijven lopen teveel als technology push te worden gezien. Business cases zijn ook wel belangrijk hoor ik u zeggen, maar voor nationale infrastructurele projecten zijn volgens vele hoogleraren en bouwkundigen GEEN business case te maken. e-Overheid is een nationaal ICT-infrastructuur project. Dus ik zou daarom persoonlijk rond de 0 euro uitrekken voor business cases.

De meeste Nederlanders hebben nog nooit gehoord van NORA en heel veel weten niet wat e-overheid is of waar digitale dienstverlening van overheid uit zou moeten bestaan. Aan die vraagkant en etalering kan nog veel worden gedaan.

Wat is nu de volgende stap?

Ik ben tot nu toe nog niet het Programma Van Eisen tegengekomen waarmee je kunt onderbouwen dat NORA nodig is, nu en in deze vorm. Ik zie en hoor graag van anderen of zij ook van mening zijn dat er nu eerst een PVE moet komen, of dat er al documenten zijn die ik zo moet zien. Wat zijn bijvoorbeeld de tien grootste problemen die moeten worden opgelost en met welke kwaliteit of niveau? Welke kwaliteitskenmerken dient de e-overheid daarom vooral te hebben?

Ik denk dat wanneer er een goedgekeurd PVE is, het zinvol gaat worden om een architectuurdocument te maken voor de e-overheid.

Bij elke fase voor het e-overheids-vernieuwingsprogramma onderken ik (bij wijze van spreken) zeven projecten. Hieronder staat waar ik aan denk. Elk project is een project met een tiental deelprojecten en een totaalbudget van tussen de 2 en 5 miljoen euro.

Fase 0 - Deze fase van plan en visievorming laat ik even buiten beschouwing. Dat is al goed genoeg gedaan. Er is immer het initiatief genomen voor e-overheid en NORA.

Fase 1 - Programma van Eisen - (Belanghebbenden insteek) Het opstellen van een programma van eisen moet op centraal overheid niveau gebeuren, regionaal en lokaal overheidsniveau (drie projecten), Ook dient er een burgerproject en een bedrijven projecten te zijn die programma's van eisen (of hun zienswijze daarop) dienen te maken. Ook dienen voor twee andere insteken of onderwerpen die diagonaal over overheid, burger en bedrijf heen gaan. En natuurlijk dient er een integraal/kapstok PVE te zijn/komen. Totaalkosten: +/- 10 miljoen.

Op de NUP-visie pagina van e-overheid.nl mis ik zoiets als een programma van eisen. Wat ik lees is allemaal vrijblijvender en globaler.

Fase 2 - Definitiestudie/Architectuur - (Domein/Systeem insteek) Het maken van een definitiestudie, opstellen van begrippenkader, doen van analyses van de huidige situatie en het opstellen van een architectuur kan in zeven projecten: P1 - een e-overheid structuurvisie project (wat zijn grote [sub]domeinen, [deel]systemen, [stijl]elementen, [deel]concepten en architectuurprincipes),

P2-P6 - vijf aspectvisies-projecten (deel-structuurvisies maken van en voor bijvoorbeeld e-overheid-ICT-Infrastructuur, e-overheid-informatievoorziening, ..-business, ..-besturing/keten, ..-security )

P7 - een e-overheid-blauwdrukproject. Alle structuurvisies en aspectvisies zijn hierin verenigd en per hoofddomein ook een aparte blauwdruk. De blauwdrukken zijn in feite posters van dubbel A0-formaat.

In elk project dienen verschillende scenario's te worden onderkend en per belanghebbende groep verschillende versies/zienswijzen opgetekend. Totaalkosten: +/- 20 miljoen.

De NUP infrastructuur op e-overheid.nl onderkend wat ik noem stijl-elementen. De definitiestudie en architectuur voor deze stijlelementen zou voornamelijk in het infrastructuurproject dienen te worden opgepakt. Er wordt naar mijn mening overigens al veel in producten en technologieën gedacht en te weinig in termen van concepten en echte architectuurprincipes gesproken. Dit komt ook omdat er geen programma van eisen om op terug te vallen.

Als deze fasen zo worden uitgevoerd als hier beschreven is denk ik het draagvlak hoger en is het ontwerpen, realiseren en transformeren minder moeilijk.

Bij NORA 2.0 en NORA 3.0 is er een groot probleem. Er wordt geen apart document onderkend voor het Programma van Eisen. Terwijl dit toch een best practice is van jewelste.

De vraag of NORA een programma van eisen is OF dat NORA een architectuur is kan niet eenvoudig worden beantwoord. Maar dat zou wel moeten kunnen. Want hoe gebruikers anders snappen wat NORA is?

Het kan zeker niet allebei zijn, want de rollen van opdrachtgever, architect en opdrachtnemer horen gescheiden te zijn om onafhankelijkheid en kwaliteit van het werk te kunnen waarborgen. Als NORA allebei is (PVE en architectuur), is het niet effectief genoeg.

Als ik NORA op professionele wijze review dan zie ik aanzetten van een architectuur die niet echt worden ondersteund door een goedgekeurd programma van eisen.

Ik zie in NORA ook stukjes programma van eisen (in de vorm van wensenlijstjes). Vooral de principes in NORA zijn voorbeelden van wensen en eisen, terwijl principes juist de toekomstvaste werking van concepten horen te beschrijven. In mijn ogen een hoogst ongelukkige toepassing van het 'concept' principes.

De uitgangspunten, wensen en eisen moeten van NORA worden losgetrokken als NORA een architectuur moet zijn. Eisen van belanghebbenden horen namelijk niet thuis IN een architectuur, maar moeten vooraf gaan aan een architectuur. In een architectuur zelf horen concepten, principes en stijlelementen thuis.

In een architectuurontwerp komen programma van eisen en architectuur weer samen.

Wat MOET gebeuren volgens mij is dat NORA wordt opgesplitst in een 'kandidaat programma van eisen e-Overheid' en een 'kandidaat architectuur e-Overheid'.

Dit kandidaat programma van eisen dient eerst te worden goedgekeurd en daarna kan een kandidaat architectuur worden opgesteld en worden goedgekeurd.

Door de eisen los te maken van de architectuur (NORA) wordt de kwaliteit, bruikbaarheid en kracht van NORA als architectuur vertienvoudigd.

Als NORA bedoeld is als programma van eisen en niet als architectuur, dan moet de naam worden aangepast en de principes uit NORA worden gehaald. In NORA moeten dan duidelijker de eisen, uitgangspunten en doel per groep belanghebbende worden geclassificeerd en per kwaliteitsaspect worden ingevuld.

Ik ondersteun graag bij het opsplitsen en goedgekeurd krijgen van NORA in een eOverheid_PVE.doc en eOverheid_Architectuur.doc.

Deze blog is geschreven door Mark Paauwe. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van markpaauwe
Mark Paauwe
Dragon1 Inc. - CTO

Mark is zeer actief in het enterprise architectuur vakgebied. De kans is groot dat je hem op een evenement tegenkomt en dat het gesprek al gauw over architectuurvisualisaties en architectuurprincipes gaat.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.