Mark Paauwe "
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken
InleidingBij deze mijn beschouwing over de geformuleerde principes in NORA.
Ik heb met veel interesse het NORA-document en de bijdragen op dit forum van Daan Rijsenbrij en Danny Greefhorst gelezen. Ik wil met deze inbreng van mijn hand een constructieve bijdrage leveren aan de verbetering van principes in NORA. Dit naar aanleiding van het feit dat ik van vele kanten hoor dat men het lastig vindt om de principes van NORA te begrijpen, te gebruiken of de impact ervan in te zien.
Het beschouwen van NORA-principes leverde bij mij een beeld op van globale wensen en eisen en functionele specificaties die als principe zijn opgeschreven. Daarmee mist het NORA-document de nodige harde principes van een juist abstractieniveau.
Ook ontbreekt het in mijn ogen aan diverse categorieen voor principes. Waarmee voor deze ontbrekende categorieen geen principes zijn onderkend in NORA.
Ik geef in deze bijdrage hier allereerst mijn eigen zienswijze op principes, daarna geef ik aan wat ik in NORA over principes ben tegengekomen, ik sluit af met verbetervoorstellen voor enkele NORA-principes. Want NORA is hard nodig.
Een zienswijze op principesIn het Enterprise Architectuur-promotieonderzoek dat ik uitvoer op de Radboud Universiteit hanteer ik momenteel de volgende, in de praktijk ontwikkelde en getoetste, definitie voor principe:
Een principe is een wetmatigheid in een (mogelijk) systeem. Een principe is een constructieve waarheid of een aan zekerheid grenzende waarschijnlijkheid (P probability > 0.8) die altijd waar is binnen een bepaalde context, periode, situatie en abstractieniveau van beschouwing. Een principe duidt de fundamentele werking aan of een werkend beginsel van een (mogelijk) systeem. Een principe is altijd onderdeel van een concept of een stijl. Een principe is een kenmerk van een systeem. Een principe zelf is geen functionele specificatie, uitgangspunt, requirement, eis, wens of doelstelling. Het rekening houden met een principe of het willen implementeren van een principe binnen een bepaalde context kan wel een uitgangspunt, requirement, eis, wens of doelstelling zijn.
Waarom houden we ons eigenlijk bezig met principes? Met het waarnemen, achterhalen, onderkennen of herkennen van een principe is het mogelijk om er voldoende rekening mee te houden als we iets willen veranderen binnen een bepaalde context.
In de onderstaande tabel staan de mogelijke attributen (niet limitatief) van een principe weergegeven:
Principe attributen
(Nr, Label, Value)
1. Een unieke id -
Vanwege de miljoenen principes in een enterprise architectuur dienen principes een unieke identificatie te hebben.
2. Naam -
Een kort statement van een tot tien woorden die duidelijk maken wat de context en werking van het principe is. Bijvoorbeeld: zwaartekracht of gedigitaliseerde werkprocessen
3. Concept of stijl verwijzing -
Een principe is altijd onderdeel van een concept of stijl. Een concept is een gestructureerde, planmatige of systematische werkwijze. We maken onderscheid in concepten en stijlen voor constructie, ontwikkeling en verandering. Voorbeelden van gangbare stijlen zijn Service Orientatie, Component orientatie, Proces Orientatie, Project Orientatie, Data Orientatie, Event Orientatie, Engine Orientatie en Taakgericht werken.
4. Omschrijving of literatuur verwijzing -
De formulering van de naam en de omschrijving van een principe komen nogal nauw. De context waarbinnen het principe geldt en de periode en abstractieniveau waarin het principe geldig is, dient duidelijk te worden afgebakend.
Omdat een principe een waarheid betreft, zijn woorden zoals mogen, willen, kunnen, zouden en moeten niet gewenst in de naam of omschrijving. De formulering van een principe dient stellend te zijn. De formulering dient ultimo een oorzaak-gevolg relatie te beschrijven maar dient minimaal een volledige entiteiten-relatie te beschrijven.
De omschrijving van een principe gaat in op het mechanisme of de werking van het principe.
De omschrijving van een principe is S.M.A.R.T.
5. Situatie-type -
We maken onderscheid in vier situatie-typen principes: AS-IS principles, Plateau1-principles, TO-BE principles en Envision-principles.
Een AS-IS-principle is een principe dat zich in de huidige situatie (heden - 1 jaar) daadwerkelijk voordoet, waarmee men er verstandig aan doet er rekening mee te houden.
Een plateau 1-principle is een principe dat zich tijdelijk voordoet (1 -2 jaar).
Een TO-BE-principle is een principe dat zich in de toekomstige situatie (3-5 jaar) zal gaan voordoen, realistisch en haalbaar is, waarmee men er verstandig aan doet er in de toekomst rekening mee te houden.
Een Envision-principle is een principe dat zich in de verre toekomst zal gaan voordoen, maar voor de AS-IS, Plateau1 en TO-BE situatie onrealistisch is.
6. Effect-type -
We maken onderscheid in twee effect-type principes: true-principles en false-principles.
Een true-principle is een principe waarvan het handhavingmechanisme effectief is, en zorgt voor de handhaving van het principe.
Een false-principle is een principe waarvan het handhavingmechanisme faalt, en daarmee het principe niet wordt gehandhaafd.
7. First-principle [Ja/Nee] -
Iedere stijl en ieder concept heeft een kern (van waarheid, of waar het om draait) die door middel van een principe kan worden geformuleerd. Dit principle is het first principle. Van alle concepten en stijlen die in een architectuur worden gebruikt dient het first principle te worden geformuleerd.
8. Status -
We maken onderscheid in de volgende status-overgangen met bijbehorende status van een principe: voorstellen, kandideren, in overweging nemen, onderkennen.
9. Bron -
Voorbeelden van bronnen van principes zijn: de natuur, ervaring, een door de industrie ontwikkelde technologie, een best practice, een bewezen concept.
De bron voor een principe is nooit een wens, eis, requirement of doelstelling. Het eisen van een bepaalde kwaliteit is wel een aanleiding om een bepaalde principe te willen of te moeten implementeren.
10. Rationale -
11. Kwaliteiteisen -
De kwaliteiteisen (zie ISO 9126, Quint II) die worden gesteld door belanghebbenden van een systeem vormen de reden dat met een principe rekening gehouden moet worden of dat een principe geimplementeerd dient te worden.
12. Voordelen /nadelen -
Het voordeel of nadeel van een principe maakt dat men kan onderbouwen waarom dit principe nodig is of bijdraagt aan het realiseren van de gestelde kwaliteitseisen.
13. Handhaving-mechanisme -
Dit is nodig om het principe binnen een bepaalde context altijd te kunnen af te dwingen. Voorbeelden van handhavingmechanismen voor principes zijn: toezicht, controle, sociale druk, beloning en bestraffing en dwingende structuren.
14. Implementatie impact -
Wat dient er te worden aangepast om een principe waar te laten zijn in een context.
15. Context -
Voorbeelden van contexten waar een principe voor kan gelden zijn: systeem, systeemonderdeel, organisatie, onderneming, instelling, organisatiedomein, project, proces, productEen voorbeeld van goed geformuleerde omschrijving op basis van de zienswijze van een principe is:
Het digitaliseren van een werkproces bij een gemeente zorgt voor een hogere kwaliteit/beschikbaarheid van dienstverlening, indien de dienstverlening van het werkproces afhankelijk is.
Dit principe noemen we een: true AS-IS principle. Dit principe is namelijk waar gebleken voor deze context bij zeer veel gemeenten en zal de komende jaren ook waar blijven zijn.
Een voorbeeld een ander goed geformuleerde omschrijving van een principe is:
Alle werkprocessen bij de gemeente X zijn gedigitaliseerd in 2010.
Dit principe noemen we een false TO-BE principle, als het niet daadwerkelijk zo is in 2010. Het is dan nodig om een handhavingmechanisme in te stellen. Een principe kan dus false zijn terwijl het goed geformuleerd is. Het is dus nodig ook de andere attributen van principes, dan de omschrijving, te weten.
Een voorbeeld van een doelstelling of eis dat ten onrechte als principe wordt geformuleerd is:
Diensten moeten SMART beschreven worden.
Het probleem met dit principe is dat de formulering ervan niet stellend is. Het betreft hier geen principe maar een eis. Iemand heeft hier een keuze mogelijkheid en dat is niet goed. Beter zou zijn om het principe als volgt te formuleren:
Het SMART beschrijven van diensten geeft voordelen zoals... of Overheidinstanties beschrijven hun diensten altijd SMART.
Een ander voorbeeld van een doelstelling of eis dat ten onrechte als principe wordt geformuleerd is: De klant wordt op een persoonlijke manier benaderd.
Het probleem met dit principe is dat het niet duidelijk is wie de klant op een persoonlijke manier benaderd en wat dat als gevolg heeft, of waarom dat dit een gevolg is van iets anders (zie het attribuut omschrijving van een principe). Beter zou zijn om het principe als volgt te formuleren: Een persoonlijke benadering van de klant vergroot het adequaat en efficient vervullen van de behoefte van de klant.
NB: Het verdient aanbeveling in geval van architectuurontwikkeling eerst de constructiestijlen, ontwikkelstijlen en veranderstijlen in beeld te brengen, daarna de bijbehorende constructieconcepten, ontwikkelconcepten en veranderconcepten, en pas daarna de bijbehorende constructieprincipes, ontwikkelprincipes en veranderprincipes te achterhalen.
Het is weinig zinvol de principes los van elkaar te achterhalen (zonder ze te groeperen in concepten en stijlen), omdat er dan te weinig zicht is op volledigheid van principes.
Het is op deze wijze dan ook veel eenvoudiger om visualisaties van modellen te maken die uiting geven aan de geformuleerde principes.
Over NORADe NORA referentie architectuur bevat volgens de auteurs (inrichtings)principes en daarbij behorende modellen die kunnen worden toegepast in projecten en programma's die gericht zijn op het ontwikkelen van de hoogwaardige dienstbare overheid.
Het NORA document maakt melding van 140 'principes'. Maar wat zijn dan 'principes' volgens NORA? Men geeft helaas geen definitie.
In het document worden verschillende typen principes geintroduceerd: architectuurprincipes, inrichtingsprincipes, fundamentele principes, (detail) principes, interne principes, etc...
Het blijft echter onduidelijk wat met 'inrichting' wordt bedoeld als voorvoegsel van principe. Het lijkt erop dat men met 'inrichting' indeling of organisatie bedoelt (Van Dale, red.). En waar komende de modellen vandaan? Zijn de modellen afgeleid van de principes? Of zijn het populaire ontwerp- en bouwstijlen of "concepten die men wil toepassen?
In het document staat ook een 'status'-indeling voor principes: De jure-principe, E-overheids-principe en Intern principe.
Het wordt niet duidelijk waarom en hoe men voor de indeling heeft gekozen. Als we naar deze drie deling kijken, dan zou je in mijn ogen logischerwijs deze indeling volledig kunnen maken met:
***************************
1. Extern (Overheidsinstantie) Principe- Overheid-principe of De jure-principe
- Burger-principe
- Bedrijven-principe
- E-overheid-principe*
- E-burger-principe
- E-bedrijven-principe
2. Intern (Overheidsinstantie) Principe*- Bedrijfsvoering-principe
- Informatiehuishouding-principe
- IT-Infrastructuur-principe
***************************
Deze indeling laat in mijn ogen ook zien welke categorie van principes we missen in dit document.
De principes zijn in het NORA-document gegroepeerd conform figuur 30, het architectuurraamwerk. Echter is dit denk ik een arbitraire indeling. De gebieden die ik mis zijn bijvoorbeeld:
- Financien, Tijd, Middelen, Overheid, Burger en Bedrijven bij de business architectuur
Organisatie, Informatieproducten, Informatiediensten , - Informatieprocessen, Overheid, Burger en Bedrijven bij de informatie architectuur
- Organisatie, Overheid, Burger en Bedrijven bij de technische architectuur
Ik denk dat er voor het overheidsbedrijf, de informatievoorziening en IT-Infrastructuur generieke referentiemodellen gebruikt dienen te worden die vollediger zijn dan wat men hier heeft gebruikt. Zie bijvoorbeeld SWTA (Services Wide Technical Architecture) voor een domeinindeling van IT-Infrastructuur.
Als we vanuit deze geschetste zienswijze over principes in bovenstaande paragraaf kijken naar de principes die zijn geformuleerd in NORA, dan treffen we globale wensen en eisen aan die nog moeten worden doorvertaald naar de benodigde principes. Hiervoor ontbreken echter de noodzakelijke concrete kwaliteiteisen en kwaliteitsaspecten in het document.
De formulering van de principes laat op diverse plekken te wensen over.
De NORA-principes zou ik willen klassificeren als wens-principes of 'false Envision "principles'. Het zijn namelijk principes die nog moeten gaan gelden in de toekomst waarvan het handhavingsmechanisme nog niet 'in place' is. Waarbij ik de NORA-principes alleen in een hele verre toekomst realiseerbaar en haalbaar acht.
Uit welke ontwerpconcepten of bouwstijlen de principes (als waarheden) afkomstig zijn kan ik niet herleiden in het NORA-document.
Het is in mijn ogen verkeerd om wensen en eisen te gebruiken als uitgangspunt voor het formuleren van principes zoals NORA schrijft. Zie paragraaf 4.4 op pagina 72 in het NORA-document. Op deze pagina wordt een vreemde draai gemaakt. Een uitgangspunt is een veronderstelling die men aanneemt (Van Dale, red.), de gestelde wensen en eisen en functionele specificaties zijn dit (meetbaar) niet. Dus waarom kiest NORA voor deze aanpak?
Men gaat hierdoor voorbij aan de haalbare en realistische werkelijkheid van alle dag en de echte principes waar men bij het ontwerpen en bouwen van een systeem rekening mee moet houden.
Bijvoorbeeld: Stel dat burgers, ondernemers en politie in Nederland als hebben eis hebben dat er geen winkeldiefstal meer plaatsvindt, dan zou NORA het volgende (wens)principe formuleren: in de winkels in Nederland wordt er niet meer gestolen.
Dit k_link_t goed, maar het echte principe dat men had moeten formuleren is: zichtbaar camera's ophangen in winkels, foto's van dieven plaatsen en potentiele dieven aanspreken op hun afwijkende gedrag werkt preventief voor winkeldiefstal. Dit is namelijk een principe (wetmatigheid) dat waar is gebleken te zijn de afgelopen jaren en hoogstwaarschijnlijk ook waar zal zijn de komende jaren. Het geschetste NORA-(wens)principe is dit niet.
Verbetervoorstellen voor de NORA-principes
Hieronder staan een aantal principes van NORA voorzien van een verbetervoorstel, op basis van de geschetste zienswijze in de tweede paragraaf. De formulering van de principes die zijn gegeven is aangescherpt. De principes zijn echter nog niet allemaal op het juiste abstractieniveau. Dit komt omdat de huidige principes als vertrekpunt zijn genomen.
NORA-principe Commentaar Verbetervoorstel
De functies van overheidsorganisaties zijn inzichtelijk Dat vinden ze denk ik bij veel overheidsorganisaties een utopie. Volgens welk concept is dit een werkend beginsel of eigenschap van een mogelijk systeem?
Overzichtelijke functies van overheidsorganisaties zorgen voor...
of
Alle primaire kerntaken van de overheidsorganisaties hebben geen onnidge overlap zijn inzichtelijk als een keten voor burger, medewerker en bedrijf en overheid per 2020.
overheidsorganisaties werken binnen de e-overheid samen Hoeveel overheidsorganisaties doen al iets met NORA?
Wederom: afkomstig uit welk concept?
Vanaf 2020 werken de meeste overheidsorganisaties samen binnen de e-overheid om ....
diensten moeten SMART beschreven worden Hoe groot is de prioriteit hiervan?
Het woord moeten in een principe, haalt het principe onderuit.
Overheidsinstanties beschrijven hun diensten SMART waarmee...
Of
Per 2020 zijn de meeste diensten bij de meeste overheidsinstanties SMART beschreven.
Bij de overheid bent u nooit aan het verkeerde adres Het is volgens mij een utopie om dit te stellen.
Wat je wilt, is altijd geholpen worden, ook al ben je aan het verkeerde adres.
Alle overheidsinstanties hebben de instelling om u niet weg te sturen naar een ander loket, maar om u te helpen bij het loket waar u aanklopt, zodat u zich als burger beter geholpen voelt en vaker naar de overheid zal gaan.
Burgers krijgen een unieke, digitale identiteit met het BSN Een BSN kan een unieke identiteitsaanduiding zijn, maar je kunt als overheid geen identiteiten verstrekken.
Iedereen die in Nederland woonachtig is, verblijft, of wordt aangetroffen heeft of krijgt per 01/01/10 een (tijdelijk) BSN toegewezen ipv een Sofi nummer. Dit is bij wet geregeld.
De klant wordt op een persoonlijke manier benaderd De begeleidende tekst bij dit principe gaat niet over het gaat niet over het 'waarom', de 'werking', of het 'doel' van dit principe. Daarnaast is men bij de meeste overheidorganen niet in staat gebruik te maken van de gegevens die men al heeft van de klant. Dat probleem zit hem overigens niet in de automatisering, maar juist in de besturing van de IT.
Een persoonlijke benadering van de klant vergroot het adequaat en efficient vervullen van de behoefte van de klant.
Diensten via Internet: Organisaties in het publieke domein verlenen hun diensten aan burgers, bedrijven en maatschappelijke instellingen via het Internet (elektronisch loket) en stimuleren het gebruik van dit kanaal.
Wat is de periode? Welke diensten betreft het?
Wat is het voordeel om internet hier te noemen? Het gaat hier om digitale of elektronische dienstverlening, en daar is internet niet randvoorwaardelijk voor.
Het begrip kanaal of medium is niet gedefinieerd. Alle overheidsorganisaties bieden per 2010 een basispakket van digitale dienstverlening aan burgers aan. Dit doet men via een website op het internet, maar ook via mobiele telefonie en digitale TV. Dit zorgt voor een hogere kwaliteit van dienstverlening van de overheid.
De huidige NORA-principes gaan volgens mij over een werkelijkheid die we op de hele lange termijn wellicht ooit zullen kunnen realiseren.
Zo dienen in mijn ogen alle principes van NORA te worden getoetst tegen de richtlijnen voor het formuleren van een principe. Ook dient men een volledigere lijst te maken met categorieen voor de te achterhalen principes. Tenslotte zouden de principes in concepten en stijlen moeten worden gegroepeerd. Ook dient het abstractieniveau van de principes te worden aangepast.
Het mogen immers geen functionele specificaties zijn, maar dienen te gaan over een te hanteren stijl of concept. Bijvoorbeeld: Het aanbieden van digitale dienstverlening door de overheid aan burgers op basis van service orientatie levert hogere flexibiliteit op voor de werkprocessen. Dit is een voorbeeld van een principe op het juiste abstractieniveau die laat zien welke bouwstijl we op dit moment zien als een juist bouwstijl.
Een principe wordt (buiten de IT) vaak gehanteerd als zijnde aan automatisme, structurele werking van een systeem of wetmatigheid. Zo zijn er boeken geschreven over natuurprincipes, logistieke principes en marketing principes die laten zien hoe de wereld werkt en hoe mensen in elkaar steken. Deze boeken gaan niet over een natuurkundig plan, logistiek plan of marketingplan. Ik krijg de indruk dat NORA een plan is en nog geen verzameling van principes. Maar dat moet het wel worden.
De formulering van een principe is iets geheel anders dan de formulering van een wens of een eis.
Bestaat NORA nu uit principes of uit globale wensen en eisen en functionele specificaties?
Download mijn bijdrage hier als word-document:
http://www.markpaauwe.com/noraPost edited by: mpaauwe, at: 2007/08/31 14:24
Post edited by: mpaauwe, at: 2007/08/31 14:31
Post edited by: mpaauwe, at: 2007/08/31 14:35
