Informatieverkeer in publiek domein

schetsboek over architectuur en ontwikkelpaden voor de elektronische overheid

Pieter Wisse
met bijdragen van Steven Luitjens, Willem van Hees, André van Brussel en Jeroen Takkenberg

hoofdstuk 4

Integratie volgens het basismodel

Onder de documenten gewijd aan (de) elektronische overheid verdienen Architectuur Elektronische Overheid: Samenhang en Samenwerking¹ en Op weg naar de elektronische overheid bijzondere aandacht. Zij verschenen allebei in het formele kader van de zgn. coördinatie van de informatievoorziening in de openbare sector.
In het onderhavige hoofdstuk toetsen we het basismodel uit het vorige hoofdstuk aan de inrichtingsvoorstellen uit genoemde nota’s. Wat opvalt, is dat beide nota’s geen systematisch verband schetsen tussen wat ze concreet als, hier algemeen gesteld, basisvoorzieningen opsommen. Daarom volgt hier projectie van zulke voorzieningen op het basismodel. De uitslag is dat het basismodel wezenlijk nader inzicht in integratie biedt. Dat is onmisbaar voor zowel ruim bemeten ontwerp, als stapsgewijze implementatie. Vooral succesvolle implementatie vergt immers kijk op afhankelijkheden of, met een ander woord, samenhang of integratie.

Integratie van … integratiefuncties

In Architectuur Elektronische Overheid heten de basisvoorzieningen: integratiefuncties. Daarvan staan er negen opgesomd:²

1. basiscommunicatie
2. berichtenuitwisseling
3. kanaalintegratie
4. (toegang tot) registraties
5. (toegang tot) bibliotheken
6. identificatie & authenticatie
7. autorisatie
8. procescoördinatie
9. directory of verwijsindex.

Deze “negen integratiefuncties zullen alle moeten worden uitgewerkt in standaarden en eventueel gemeenschappelijke voorzieningen.” Wat de auteurs van Architectuur Elektronische Overheid trouwens bedoelen is niet dat zij de prioriteitstelling deden en/of de gedetailleerde ontwerpen presenteren, maar dat zij een manier beschrijven om zo’n ‘proces’ te verrichten. Verder beperken de auteurs zich — impliciet — tot wat wij hier met de overheid-als-deelnemer bedoelen. De voorgestelde integratiefuncties zijn echter niet aan enige organisatiegrens gebonden. Dáárom is de analyse hier ook reëel. Maar ook al wat Architectuur Elektronische Overheid tot uitwerking rekent, vergt een “pragmatische implementatiestrategie [die] is vertaald naar een concreet prioriterings- en detailontwerpproces.”³

Voor uitvoering is het problematisch dat functie-als-behoefte en functie-als-module daar door elkaar lopen. Waarom juist zulk onderscheid wezenlijk is, voert te ver hier toe te lichten. Daaraan is hoofdstuk 18, Ontwerpslag tussen behoeften en voorzieningen, gewijd voor wie zich in enige ontwerpleer wil verdiepen. Maar wanneer er dus inderdaad van verwarrende vermenging sprake is, dan is zo’n proces te simpel opgevat, te weten als de wijze waarop “de integratiefuncties één voor één kunnen worden geprioriteerd en kunnen worden uitgewerkt in samenhangende detailontwerpen.”⁴ Hoewel, “samenhangend” klinkt weer enigszins geruststellend.

Figuur 8, aan het slot van het vorige hoofdstuk, schetst samenhang tussen uitvoeringsmodulen (voorzieningen?) expliciet. Dat gebeurt daar trouwens met nog altijd sterk geaggregeerde modulen. Het gaat erom dat onontkoombare versimpeling als scharnier tussen beleid en uitvoering (zie hoofdstuk 16, Informatiearchitectuur) voldoende realiteitsgehalte behoudt. Daarmee lopen we met terugwerkende kracht de integratiefuncties eens langs. Tegen de achtergrond van figuur 8 verschaft figuur 9 het overzicht van — samenhang tussen — de integratiefuncties. Elke functie is aangeduid met het nummer volgens de opsomming, hierboven. Integratiefunctie nr. 6, identificatie & authenticatie, heeft een bijzondere positie; de reden staat verderop toegelicht.

Figuur 9: Integratiefuncties in samenhang

De integratiefuncties uit Architectuur Elektronische Overheid bieden complete, ordelijke dekking van het basismodel. Daaruit volgt dat het basismodel aanwijzingen verschaft voor de integratie van … de integratiefuncties. Daaraan is behoefte, omdat de veronderstelling op z’n minst te eenvoudig is dat, zoals hierboven al aangehaald, “de integratiefuncties één voor één kunnen worden geprioriteerd.”

Kort commentaar op integratiefuncties

Voorts geeft hun projectie op het basismodel aanleiding tot enig commentaar op de integratiefuncties:

+ Zo vormt basiscommunicatie (1) een voorwaarde voor berichtenuitwisseling (2). Volgens deze informatiekundige architectuurschetsen gebeurt informatieverkeer per definitie met berichten (zie verderop hoofdstuk 5). Daarom staat in figuur 8 een infrastructuur voor berichtenverkeer centraal. Prioriteit? Zonder verkeers‘voorziening’ geen enkel verkeer.
+ Kanaalintegratie (3) kan verwarring wekken. De behoefte is juist aan kanaaldifferentiatie (Engels: multi-channel), althans in de zin van erkenning van diverse soorten aansluitingen die actoren willen benutten.
Als het ware zo snel — en indien — mogelijk ‘achter’ de aansluiting moeten dergelijke verschillen vervallen; dergelijke integratie is dan de keerzijde van differentiatiebehoefte in één en hetzelfde informatiestelsel. Er is beslist niet één enkele module/voorziening die aldus uniformeert en, nota bene, in omgekeerde richting, specificeert.
+ Vooral in (toegang tot) registraties (4) en (toegang tot) bibliotheken (5) komt duidelijk tot uitdrukking hoe verleidelijk het blijkbaar is om van behoefte overhaast tot voorziening te concluderen (zie hoofdstuk 18, Ontwerpslag tussen behoeften en voorzieningen, voor onze toelichting). Bedoelde registraties en bibliotheken zijn in figuur 8 allemaal als informatie aangeduid.
+ De vertaalslag van de behoefte aan identificatie & authenticatie (6) naar een voorzieningen- annex modulenconfiguratie is hierboven reeds toegelicht. De schijn kan opgehouden blijven door voor de behoeftevervulling een virtuele voorziening te veronderstellen. ‘Virtueel’ wordt alom misbruikt als scharnierwoord. Het resultaat van een succesvolle identificatie- en authenticatiebeweging is in elk geval dat de actor toegang verkrijgt tot zijn gebruiksrecht ofwel autorisatie, enzovoort. Zo bestaat er dus een ‘virtuele voorziening’ die de actor met zijn autorisatie verbindt; dáár past de integratiefunctie het best in het overzicht.
+ Autorisatie (7) is een behoefte waarvoor figuur 8 inderdaad verbijzonderde informatieverzamelingen presenteert. Het is natuurlijk nog maar de vraag of dat niet te simplistisch is.
+ Dat geldt ook voor de behoefte aan procescoördinatie (8); in figuur 8 komen daarmee qua voorzieningen direct de verzamelingen met werkstroominformatie overeen.
+ Tenslotte staat directory of verwijsindex (9) als integratiefunctie vermeld. Daarvoor biedt figuur 8 bij wijze van uitzondering méér detaillering, te weten informatiewijzers en schakelwijzers. Het basisidee van onderscheid naar informatie, respectievelijk werkstroom is echter óók reeds nadrukkelijk in de integratiefuncties (4) en (5), respectievelijk (8) gevestigd.

Voor diverse integratiefuncties geldt dat “de ambitie […] om functies te kiezen en een naam te geven in een taal die zowel bestuurders als technologiespecialisten verstaan”⁵ ongelukkig uitpakt. Het is immers wat ingewikkelder dan dat “de [bestuurders kunnen] besluiten over elke functie [waarna de specialisten] in staat [zijn] elke functie uit te werken in realiseerbare technische specificaties.”⁶ Nota bene, zulke specificaties zijn ook maar weer een middel. Wat telt is uitvoering zèlf.

De vernauwde aandacht op afzonderlijke functies kan bestuurders slechts de schijn van beheersing schenken, terwijl de specialisten in de schijn verkeren passende voorzieningen te realiseren. Zodoende komen tegenstrijdigheden vaak pas aan het licht nadat de ‘constructie’ voor gebruik opgeleverd is, maar … onbruikbaar blijkt. Dat kost dan — heel veel — extra geld en tijd, om van schade voor motivatie niet te spreken. Verder is het zonder adequate scharnierwerking tussen beleid en uitvoering maar de vraag of de herstelpoging wèl slaagt. Doorgaans wordt slecht (ongeschikt, afbreukrisico voor primaire processen, laat beschikbaar, duur ontwikkeld, duur in beheer, onveilig enzovoort) gereedschap dan toch maar in gebruik genomen.

Een voorbeeld van onvoldoende besef van afhankelijkheden is de trage vernieuwing van de gemeentelijke basisadministratie (waarover verderop nog meer). De authentieke registratie van natuurlijke personen is helemaal geen ‘voorziening’ die slechts voorziet in ‘de’ gemeentelijke informatiebehoefte. Die vervult talloze informatiebehoeften, maar dat gebeurt in vele gevallen nog niet passend.

Vanuit architectuur als scharnierperspectief valt te ontdekken dat de beleids- en uitvoeringskant veel minder lineair, in-één-richting-van-beleid-naar-uitvoering met elkaar verbonden zijn. Dat neemt niet weg dat eerder met het aanwijzen van de integratiefuncties belangwekkend informatiekundig schetswerk geleverd is. Enigszins geretoucheerd blijken ze vergaand overeen te stemmen met de hier voorgestelde stelregels voor informatieverkeer en het daarvan afgeleide overzicht voor de elektronische overheid. In termen van de nota Architectuur Elektronische Overheid zèlf reiken ze overigens eveneens verder dan “koppelen.” Voor “kantelen” zijn ze eveneens nodig, maar dan wel vanuit stelselmatig overzicht, zoals hier figuur 9 biedt. Indien een tussenstap zoals “koppelen” in de zin van genoemde nota inderdaad nodig blijkt, is het natuurlijk optimaal wanneer dat al zoveel mogelijk stelselmatig gebeurd. Nogmaals, daarvoor moet dan wel zo’n overzicht beschikbaar zijn.

Stelselmatige ordening van betekenissen

De projectie à la figuur 9 suggereert een 10e integratiefunctie. Voorafgaand aan figuur 8 is dat — ondersteuning van — pragmatische variëteit genoemd. Met een eenvoudig voorbeeld kunnen we oproepen hoe we zulke variëteit bedoelen. Neem een woord, bijvoorbeeld ‘blok.’ Dat ene woord heeft allerlei betekenissen. Dat levert geen misverstand op, zolang een bepaalde praktijk van woordgebruik tot één enkele van die betekenissen beperkt blijft. De elektronische overheid als ruim informatiestelsel moet echter diverse gebruikspraktijken ondersteunen. Variëteit of pluriformiteit, dus. Daarbij komt dat zulke praktijken veranderlijk zijn.

Met zulke ruime grenzen schiet absolute betekenisstandaardisatie tekort voor talloze woorden e.d. Zodra één en hetzelfde informatiestelsel diverse zgn. taalspelen (tegenwoordig ook wel bekend als communities of practice) faciliteert, is eenduidige ordening van betekenisovereenkomsten èn –verschillen noodzakelijk. Dat klinkt zo compact geformuleerd niet alleen moeilijk. Dat is het ook wel. In het aanvullend deel (studies) verschaffen de hoofdstukken 20 tot en met 22 alvast wat nadere toelichting.

Nu is de behoefte aan een taalspelige infrastructuur of, scherper geformuleerd, aan die 10e integratiefunctie, pas recenter manifest, te weten sinds de praktische mogelijkheid van aansluitingen voor gevarieerde informatievoorziening aan één netwerk. Van de weeromstuit moet gebruiksvariëteit intern gereguleerd zijn, dwz. binnen de grenzen van het ene informatiestelsel. Dat lukt met ‘context’ als variabele.⁷ (En voor passende informatievariëteit hoort daar gedetailleerde tijdverbijzondering onlosmakelijk bij. Ook toelichting daarop voert voor dit schetsboek te ver.) Nogmaals, zonder zulke conceptuele ordening werkt ‘het’ niet, punt. Zie hoofdstuk 20, Stelsellogica. Vooralsnog is dit het meest onderschatte probleem in infrastructuur voor informatieverkeer. Met louter technische voorzieningen valt een conceptueel vraagstuk nooit op te lossen. Een geslaagde oplossing voor pragmatische variëteit doorkruist per definitie de traditionele verkokering in informatievoorziening per ‘toepassing,’ per organisatie(eenheid), per sector. Als dat een verticale oriëntatie is, voegt eenduidige ordening van betekenisovereenkomsten èn –verschillen er een horizontale aan toe: betekenisvolle samenhang. Hoofdstuk 21, Integratiemethode voor informatiestelsel, verduidelijkt hoe zo’n ordening fijnmaziger moet uitpakken dan volgens traditionele gebruikersgemeenschappen gebeurt.

Zo’n structuur van betekenissen in het informatiestelsel wordt op zijn beurt eveneens in informatie uitgedrukt. Dat is informatie over informatie, kortweg metainformatie of beter bekend als metadata. Metainformatie vormt aldus het ‘hart’ van de elektronische overheid.

Wat hierboven aangehaald staat als negende integratiefunctie, te weten de verwijsindex, kent nauw verband met pragmatische betekenisordening als tiende integratiefunctie. Hoofdstuk 22, Federatieve metainformatie, schetst de aanpak die (ook) opgaat voor het stelsel voor informatieverkeer in het publiek domein. Nogmaals, de opgave luidt om variëteit van betekenissen desondanks in het ene stelsel onder te brengen; zulke betekenisordening vergt extra maatregelen voor eenduidigheid.

Perspectiefwissel

In Op weg naar de elektronische overheid zijn basisvoorzieningen gepresenteerd als “zeven domeinen, die bij elkaar het model vormen van de openbare elektronische ‘informatie-infrastructuur’:”

A. elektronische toegang tot de overheid
B. elektronische authenticatie
C. éénduidige nummers voor personen en voor bedrijven
D. basisregisters
E. elektronische identificeringsmiddelen (chipcards)
F. elektronische informatie-uitwisseling
G. snelle verbindingen tussen overheidsorganisaties.

Bij nader inzien blijkt de projectie van zulke domeinen op het basismodel lastig. Wij herkennen daarin niet zozeer een probleem met basismodel en/of opsomming van domeinen. Daarentegen vatten wij het verschil op als bevestiging van informatiearchitectuur als vertaalslag van behoeften naar voorzieningen. Zie hoofdstuk 16, Informatiearchitectuur, voor toelichting op de afwijkende perspectieven met beleid en uitvoering, met daartussen architectuur als scharnierwerking.

De nota Architectuur Elektronische Overheid is vanuit uitvoeringsperspectief opgesteld, terwijl Op weg naar de elektronische overheid een beleidsnota is. Dat verklaart waarom de integratiefuncties uit de eerstgenoemde nota simpelweg het karakter van basisvoorzieningen dragen. Omdat het basismodel in het vorige hoofdstuk eveneens sterk uitvoeringsgericht (lees ook: infrastructureel) is, passen de integratiefuncties netjes. Wat in Op weg naar de elektronische overheid basisvoorzieningen annex domeinen heten, vergt echter nog de ontwerpslag naar uitvoerbaarheid. Onder de noemer van beleid zijn met de domeinen dus veeleer behoeften gesteld. Zie hoofdsstuk 18, Ontwerpslag tussen behoeften en voorzieningen, voor principiële toelichting op het verschil.

Illustratie van afwijkende oriëntaties

Indien de oriëntaties inderdaad afwijken — enerzijds beleid voor Op weg naar de elektronische overheid, anderzijds uitvoering voor Architectuur Elektronische Overheid, respectievelijk ons basismodel — heeft het geen enkele zin er een wedstrijd van te maken. Ze zijn gewoon ànders. Er bestaat domweg een kwalitatief verschil, wat juist erkenning verdient. Dat is de kortste ‘weg’ van beleid naar passende uitvoering.

Ter illustratie hebben wij toch geprobeerd de — hier inmiddels dus tien — integratiefuncties in verband te brengen met de domeinen van Op weg naar de elektronische overheid. Uitgaande van de integratiefuncties kan dat bijvoorbeeld zo:

1. basiscommunicatie
G. snelle verbindingen tussen overheidsorganisaties

2. berichtenuitwisseling
F. elektronische informatie-uitwisseling

3. kanaalintegratie
A. elektronische toegang tot de overheid

4. (toegang tot) registraties
D. basisregisters

5. (toegang tot) bibliotheken

6. identificatie & authenticatie
B. elektronische authenticatie
C. éénduidige nummers voor personen en voor bedrijven
E. elektronische identificeringsmiddelen (chipcards)

7. autorisatie

8. procescoördinatie

9. directory of verwijsindex

10. betekenisordening.

Toegegeven, deze poging tot matching weerspiegelt op details willekeur. Maar hoe dan ook rijzen er onvermijdelijk vragen of eigenlijk al wel voldoende duidelijk is welke lading een bepaalde ‘vlag’ moet dekken. En uitgaande van de redelijke dekking door de integratiefuncties, laten de domeinen wezenlijke onderdelen van de elektronische overheid ònontwikkeld. Met andere woorden, met de basisvoorzieningen volgens beleidsmatig perspectief resulteert nog geen heus stelsel. Gegéven zo’n beleidsoriëntatie kan de ontwerpslag ermee beginnen, ter borging van stelselmatigheid, zulke ‘lege plekken’ alsnog voor actie te agenderen. Er moet immers een andere uitvoeringsruimte worden gerealiseerd. Wanneer de beleidsmatige opsomming daarentegen één-op-één doorgetrokken wordt naar feitelijke (basis)voorzieningen, wijst het basismodel erop dat ze niet nodig èn voldoende zijn — zo heet dat nu eenmaal formeel — voor een werkelijk stelsel voor informatieverkeer.

Veel onduidelijkheid verdwijnt overigens door de toelichtingen die Op weg naar de elektronische overheid bevat op de respectievelijke domeinen. Het voert hier te ver die hier te uitvoerig herhalen. Maar domein A, toegang tot de elektronische overheid, blijkt dan op “het elektronisch beschikbaar stellen van informatie over documenten, diensten en producten van de overheid” betrekking te hebben. Dat valt dus eigenlijk te vertalen naar integratiefunctie 5, (toegang tot) bibliotheken, plus een begin met integratiefunctie 8, procescoördinatie. In een volgende poging tot matching verdwijnen daar weliswaar de lege plekken, maar lijkt integratiefunctie 3, kanaalintegratie, niet langer aangesproken. De toelichting op domein B, elektronische authenticatie, stelt echter, weliswaar wat terzijde: “Bij elektronische afhandeling […]verlangen burgers en bedrijven logischerwijze dat zij op een en dezelfde manier toegang kunnen krijgen tot welke overheidsorganisatie dan ook[.]” Dat smaakt weer naar kanaalintegratie.

Een andersoortig verschil in opvattingen ‘achter’ enerzijds integratiefuncties, anderzijds domeinen zou het volgende kunnen zijn. Met integratiefuncties, zeker de oorspronkelijk voorgestelde negen, ligt het accent toch vooral op, zeg maar, informatie- en communicatietechnologie. Domeinen omvatten alweer meer andere aspecten. Ze zijn in dàt opzicht wat geïntegreerder, zij het in Op weg naar de elektronische overheid overwegend impliciet. Diezelfde nota behandelt voorts aspecten zoals organisatie, financiering en wet- en regelgeving zelfs expliciet ná vermelding van de zeven domeinen. Vanuit het consequente stelselperspectief dat wij met dit schetsboek voorstellen, zijn dat eigenlijk allemaal óók integratiefuncties.

Orde in rapportages

Het onderscheid tussen enerzijds behoeftestelling, anderzijds voorzieningenontwerp kan tevens helpen orde te scheppen in (voortgangs)rapportages. Verwarring ontstaat onvermijdelijk wanneer uitvoerders hun rapportage in termen van voorzieningen opstellen, terwijl beleidsmakers inzicht in termen van behoeften verwachten. In die richting past dus eveneens een vertaalslag. Omdat falende rapportages draagvlak ondermijnen, en dus vroeg of laat realisatie zèlf, besteden we er zo nadrukkelijk aandacht aan.

Een opsomming van wat neerkomt op een informele inventarisatie van behoeften heeft niets weg van een bestek of een, zoals het op z’n Engels heet, work breakdown structure. Let wel, dit is allerminst een diskwalificatie. Behoeftestelling is juist wezenlijk voor de koers van complexe veranderingsprocessen. Maar er moeten vervolgens wèl vertalingen komen, heen èn weer, van overzichten in termen van doelen, respectievelijk van middelen. De Tweede Kamer heeft in Op weg naar de elektronische overheid primair over bedoelingen kunnen lezen. Zelfs grofweg over hoe het tijdpad voor àflevering eruit ziet. Of dat tijdpad enigszins realistisch is, valt overigens (nog) niet te toetsen. Daarvoor is immers, zoals wij hierboven betoogden, een redelijk betrouwbare ontwerpslag naar feitelijke, nota bene samenhangende voorzieningen onontbeerlijk. Want wat is er werkelijk nodig om zulke resultaten te realiseren? Hoe zit het (tijd)schema voor de daadwerkelijke ‘productie’ in elkaar?

Een complicerende factor alleen al voor het bestek — dat stáát voor de logica van de constructie — is dat de meest … complexe middelen van andere dan strikt informatietechnische aard zijn. Aan het slot van de voorgaande paragraaf wezen wij daar al kort op. In de delen III tot en met V staan niet voor niets diverse aspecten vermeld, van proces tot en met internationalisering. En ook daarvoor geldt op hun beurt dat het minder vaktechnische dan verandercomplexiteit betreft. Zoiets als het bestek moet dus óók en vooral de planning & monitoring van ontwikkeling van, zeg maar, bekostigingsmethode(n) tot en met stelselregie omvatten èn integreren.

In de ICA Enterprise Architecture Study Group Survey⁸ komt de volgende vraag voor: Do you follow a specific EA framework? De afkorting EA staat voor enterprise architecture. Mogelijke antwoorden zijn ja of nee. Wie met ja antwoordt, kan bij de volgende vraag kiezen uit een lijstje zgn. frameworks. Geïnspireerd door de vergelijking met het fysieke verkeersstelsel blijken dergelijke frameworks echter (te) eenzijdig gericht op ict. Daarom geven we het volgende commentaar:

EA frameworks such as the question “Do you follow a specific EA framework?” suggests, are too narrowly limited to deployment of information and communication technology. As — the next version of — eGovernment increasingly incorporates process redesign, i.e. aligning previously (more) autonomous units/actors into coordinated performance, other than ict issues become especially critical. Legal aspects, budgeting, operations etc. all require a different, that is a system-wide, approach. So, contrary to traditional enterprise architecture, eGovernment does not limit itself to a single organization. What may remain secondary issues when lines of authority are (relatively) unambiguous, are primary, mission-critical issues for a networked society of actors (including, please note, not just government organizations but also, and especially so, citizens and companies). How once-treated-as-secondary-now-turned-primary aspects of eGovernment are perceived, can be dealt with etc. seems, to a significant extent, culturally determined. For example, our national experience is that participants (also read: actors) will start to join ict-related efforts only after they feel certain about, and fairly treated by, future budget allocations. In important ways, therefore, a framework suited for an enterprise-as-a-dynamic-network-of-actors should both explicitly address more aspects (than traditional ict frameworks do) and readjust their weights.

Nota bene, dat aspectprioriteiten als het ware òmdraaien door de verbreding van ‘single enterprise’ naar de elektronische overheid als zeer gevarieerd stelsel, is ook weer exemplarisch voor de noodzaak van een kwalitatief àndere aanpak.

We komen terug om de concrete gevolgen voor ordelijke rapportages, bijvoorbeeld voor planning & monitoring. Het spreekt eigenlijk vanzelf dat er verschillende varianten moeten bestaan, te weten overeenkomstig doelgroepen met hun karakteristieke perspectief op de elektronische overheid. De varianten moeten uiteraard onderling consistent zijn. Wat constructeurs volgens het bestek daadwerkelijk ‘bouwen,’ komt dan tenminste controleerbaar overeen met wat het beleidsschema — of zijn het zelfs diverse (soorten) beleidsschema’s, dwz. afhankelijk van doelgroep? — aan verwachtingen wekt bij politici, bestuurders enzovoort.

noten

1. Architectuur Elektronische Overheid: Samenhang en Samenwerking (november 2002), een zgn. architectuurstudie opgesteld in opdracht van de directie Informatievoorziening Openbare Sector (tegenwoordig: directie Innovatie & Informatiebeleid Openbare Sector) van het ministerie van Binnenlandse Zaken en Koninkrijksrelaties.
2. Ibid, p.3.
3. Ibid, p. 4.
4. Ibid, p. 7.
5. Ibid, p. 27.
6. Ibid.
7. Metapattern: context and time in information models, P. E. Wisse, Addison-Wesley, 2001. Zie van Wisse met S.B. Luitjens De klacht van de Keten (Stroomlijning Basisgegevens, handomdraai #4, 2003) als beknopte inleiding.
8. Juli 2004, opgesteld door de ICA Enterprise Architecture Study Group van de International Council for Information Technology in Government Administration (ICA).

inhoudsopgave, vorige hoofdstuk, volgende hoofdstuk.

2004 (1e druk: 27 september 2004; 2e druk: 13 december 2004) © programma Architectuur Elektronische Overheid (Ictu) en afzonderlijke auteurs; webeditie 2007 © Pieter Wisse

Zie ook de complete nota als enkel pdf-bestand.