November 1998: Artikel: Informatiekundige architecturen en informatie-architecten gepubliceerd in Informatie

Informatiekundige architecturen zijn in. Maar: wat is een informatiekundige architectuur? En wat is het niet? Vragen waarop in de afgelopen tijd heel veel antwoorden gegeven zijn. Maar is er al een goed antwoord te geven?Het komt niet zo vaak voor dat een organisatie voldoende kennis heeft van haar informatievoorziening om te weten hoe deze zal moeten veranderen. Of om er paal en perk aan te kunnen stellen. Met als gevolg dat men niet weet hoe een slechte informatievoorziening aangepakt kan of moet worden, zodat een betere ontstaat. Vaak is immers de op een moment beschikbare informatietechnologie (IT, ICT) leidend bij veranderingen. Weet men nu echt vooraf wat een technologie zal betekenen voor de organisatie? En is het in een organisatie wel handig om een bepaalde technologie in te zetten? Duidelijk is wel dat als organisaties niet voldoende blijven weten van hun informatievoorziening, er in de toekomst problemen zullen ontstaan. Wildgroei, onbeheersbare en onbeheerbare infrastructuren, mogelijk een schijnbaar niet te dempen ICT-put en misschien zelfs een gegevensinfarct.In dit artikel worden allerlei visies neergelegd en kanttekeningen geplaatst bij en rond informatiekundige architecturen. Zonder daarbij te willen dicteren hoe een en ander in elkaar zit. In het verlengde daarvan wordt ingegaan op het beroep van informatie-architect. Ook wordt aandacht besteed aan wat het Nederlands Genootschap voor Informatie Architecten (NGIA) aan dit alles doet.

Informatie hebben is weten. Het toevoegen van relevante feiten, informatie dus, aan wat iemand al weet en begrijpt; dat voegt toe aan zijn of haar kennis. Feiten die geen betekenis hebben, of die je niet nodig hebt, zijn gegevens. Misschien is er een reden om gegevens te leren begrijpen, maar vaak is het beter om te proberen dat soort feiten niet te hebben of aangeboden te krijgen.
Organisaties hebben informatie nodig, sommige meer dan andere. Welke informatie een organisatie nodig heeft, is afhankelijk van waar een organisatie zich mee bezig houdt. De grootte van een organisatie wordt mede bepaald door het aantal soorten informatie dat men wenst te verzamelen. Of als men van één (of meer) soort(en) heel veel informatie wenst te verzamelen.
Organisaties verzamelen meestal ook gegevens. Een autofabrikant bijvoorbeeld, zou kunnen bijhouden op welke dagen van de week zijn auto's verkocht worden. Het is echter de vraag of die feiten iets toevoegen aan de bedrijfsvoering. Dat een fabrikant de leeftijd van de kopers van zijn modellen bijhoudt, lijkt logischer; zo kan hij beter bepalen in welke kleuren een model het volgende seizoen het beste geleverd kan worden. Het bijhouden van de dag waarop een auto verkocht wordt, is informatie voor een autodealer, en een gegeven voor de fabrikant. Dus waarom zou een fabrikant moeite doen deze feiten te verzamelen en vast te houden? Hij kan zijn middelen (mensen, geld enzovoort) beter voor andere zaken inzetten.
De praktijk leert dat heel veel organisaties feiten verzamelen die voor hen geen informatie zijn, maar gegevens. En dat is in feite een bedreiging. Zeker met de technologie die nu voorhanden is en wat binnenkort voorhanden zal komen. Het is immers relatief simpel om vele megabytes, gigabytes of zelfs terabytes van bijvoorbeeld Internet op te halen, zowel gestructureerd (uit databases) als in de vorm van documenten. Als je bijvoorbeeld de opdracht zou geven om te zoeken naar documenten waar het woord 'ruimte' minimaal twee keer in voorkomt, dan krijg je feiten over het heelal, parkeer-ruimte, ruimte-lijke ordening, ruimte op begrotingen enzovoort. En we zochten eigenlijk naar vergader-ruimte. Door de opvraagcriteria scherper en slimmer op te stellen kan je veel uitsluiten. Maar daarmee kun je nou net dat ene document missen, waarin...
Men is dus makkelijk geneigd om veel te veel feiten binnen te halen. Natuurlijk komen er steeds betere hulpmiddelen op de markt om al meteen te zoeken naar informatie. Denk bijvoorbeeld aan document management- en text retrieval-software. Zoeken naar informatie blijft echter afhangen van hoe slim die software is en, vooral, hoe slim degene is die de software gebruikt. Men zal immers zelf precies genoeg moeten aangeven wat men hebben wil. Met de angst informatie te missen zal dan toch in veel gevallen besloten worden om alles binnen te halen. Dat resulteert in die ongebreidelde hoeveelheid feiten. Organisaties zien dan door de bomen het bos niet meer: het te vrezen gegevensinfarct.
Blijven we zo niet achter de feiten aanlopen? Zouden we niet een keer kunnen bepalen wat informatie is, en wat niet?

Informatievoorziening
Een organisatie wordt opgezet om iets te bereiken. Samen worden één of meer doelen nagestreefd, al of niet met winstoogmerk. In veel organisaties werken mensen samen: samenwerken betekent onderling communiceren. Afgezien van gesprekken over kinderen en vakantie zal men vooral communiceren over waar men voor aangenomen is. En dat is, onder meer, bezig zijn met feiten die om de een of andere reden verzameld zijn of worden.
Naar organisaties wordt op net zoveel manieren gekeken als dat er mensen bij betrokken zijn. Bij elke discipline hoort nu eenmaal een eigen manier van kijken. Een jurist ziet een organisatie nu eenmaal anders dan iemand van personeelszaken, een logistiek specialist, of iemand aan een lopende band. Ieder heeft zo zijn of haar eigen gedachten en zijn of haar eigen model van die organisatie. Om spraakverwarring te voorkomen zal getracht worden lijn te brengen in die modellen. Medewerkers van personeelszaken bijvoorbeeld, kunnen nu eenmaal niet ieder een eigen beeld hebben van de opbouw van en de verhoudingen binnen een organisatie. Datzelfde geldt voor de andere disciplines, zoals voor de modellen die informatiekundigen en automatiseerders hebben.
Een belangrijke vraag voor informatiekundigen is wat wel en wat niet tot de informatievoorziening van een organisatie hoort. Het lijkt een simpele vraag, maar het antwoord is vaak complex. Zo complex dat het in veel gevallen onmogelijk is om naar de informatievoorziening van een organisaties in zijn geheel te kijken. De volwassenheid van de organisatie speelt daarbij een grote rol. Vaak wordt dan ook naar delen van een organisatie gekeken. Die delen worden Universes of Discourse (UoD) genoemd.
Rond de term Universe of Discourse bestaat al jaren discussie. Wat wordt er nu precies mee bedoeld? En, hoe baken je zoiets af? In feite is de UoD dat deel van een organisatie dat door een informatiekundige onder handen genomen wordt. In feite is het dus een aandachts- of interessegebied.
Als een organisatie opgedeeld wordt in UoD's, zal er altijd onderlinge overlap zijn. Informatiekundigen kunnen de informatievoorziening van al de UoD's in beeld brengen. Dat zou op een zodanige manier moeten gebeuren, dat de delen perfect bij elkaar passen. De 'beelden' die de informatiekundigen van de informatievoorziening maken zouden dan samengenomen kunnen worden. Samen vormen zij een integraal beeld van de informatievoorziening voor de gehele organisatie: de informatiekundige architectuur1.
Je zou zelfs nog verder kunnen gaan en één informatiekundige architectuur kunnen opzetten voor meer organisaties. Daarmee zouden informatiekundige problemen rond bijvoorbeeld Electronic Data Interchange (EDI), Just-In-Time (JIT) enzovoort voor een groot deel uit de weg geruimd kunnen worden. Maar: hoe breder, hoe complexer.

Informatiekundige architectuur
De term Architectuur heeft volgens het Van Dale woordenboek2 drie betekenissen:

1. de kunst en de leer van het ontwerpen en uitvoeren van bouwwerken
2. bouwstijl
3. geheel van regels, protocollen en voorschriften waaraan programma's moeten voldoen om door de computer te kunnen worden begrepen.

De laatste betekenis zou door de argeloze lezer uitgelegd kunnen worden als zou het om een specificatie van computerprogramma's gaan. De praktijk leert echter, dat die regels, protocollen en voorschriften veel breder uitgelegd dienen te worden. Hoe kun je immers anders garanderen, dat een volgend computerprogramma goed aansluit bij andere?
Definitie 3 stamt, zoals de editie ook aangeeft, uit de jaren tachtig (of zelfs eerder). Tegenwoordig weten we dat we eerst breder moeten kijken dan software. We denken nu meer in termen van een bij een organisatie passende informatievoorziening. En dat beeld, de informatiekundige architectuur, is de basis voor automatiseerders om passende software te realiseren of te kopen.
Een term als architectuur heeft, los uitgelegd, te maken met termen als model, beschrijving en vormgeving. Als je de term zo uitlegt, kan hij op allerlei manieren worden gebruikt. Dat gebeurt op dit moment ook steeds vaker. Steeds meer mensen en organisaties gebruiken termen als business architectuur, software-architectuur, informatie-architectuur, systeemarchitectuur enzovoort.
Interessant in dit kader is het gebruik van de term infrastructuur. Het Van Dale Woordenboek definieert het begrip infrastructuur als 'het totaal van onroerende voorzieningen zoals wegen, bruggen, vliegvelden, havens enzovoort'.
Iets vergelijkbaars kennen we ook in automatiseringsland (ook IT en ICT). Steeds meer wordt over drie lagen gesproken:

• softwarelaag; waar de gebruikersapplicaties cq. de -objecten zich bevinden
• systeemsoftwarelaag; de laag van de operating systemen
• hardware- en netwerklaag; waar computers, bedrading, opslagmedia, modems, hubs enzovoort zich bevinden.

Tussen deze lagen kennen we een veel-op-veel afhankelijkheid: systeemsoftware kan meer soorten hardware beschikbaar maken, terwijl hardware met meer soorten systeemsoftware operationeel gesteld kan worden. Ook kan software vaak op meer systeemsoftware draaien. Dit is de feitelijke consequentie van wat met open, gedistribueerde gegevensverwerking (in het Engels ODP: Open Distributed Processing) bedoeld wordt.
Als voorbeeld: een gebruiker werkt met een applicatie. Hij vraagt daarmee bepaalde informatie op. Die informatie kan zich in principe, afhankelijk van welk netwerk men gebruikt, overal ter wereld bevinden. Vaak weet de gebruiker niet eens waar de informatie zich bevindt. Via mechanismen als brokering en trading kan uitgezocht worden op welke plaats of plaatsen men de gevraagde informatie kan vinden, ongeacht de systeemsoftware en hardware die op die plaats gebruikt wordt. Als de gebruikers daartoe gerechtigd zijn kan die informatie, vaak inclusief functionaliteit om die informatie te ontsluiten, opgehaald en 'gebruikt' worden.
Op een moment zal een organisatie de lagen op een bepaalde manier ingericht hebben. Alles wat men aan informatievoorziening heeft, kan samengevat worden onder het begrip infrastructuur.
Er bestaat nogal wat verwarring over wat het verschil is tussen een informatiekundige architectuur en een (informatiekundige) infrastructuur. Om dit duidelijk te maken gaan we uit van de 'losse' uitleg van de term architectuur: model, beschrijving, vormgeving. We kunnen nu spreken van de 'architectuur van de infrastructuur'. Daarmee wordt dan het 'beeld' van de infrastructuur bedoeld zoals die op enig moment een organisatie werkelijk ondersteunt. Het zal daarbij niet alleen gaan om het beeld van de infrastructuur, maar ook om activiteiten als technisch beheer (onder meer WAN en LAN), beveiliging, helpdesk enzovoort: veel zaken waar bijvoorbeeld ITIL naar kijkt3.
Hier is vooral ook het ontwikkelen of aankopen van software interessant. Deze 'nieuwe' software wordt immers gemaakt om een plaats te krijgen in de infrastructuur. Daarbij kan bestaande software uitfaseren of vervangen worden.
Om welke reden ontwikkelen of kopen we software? Wat moet die software allemaal gaan doen? En hoe sluit die software aan bij de software die we al hebben? Om deze vragen te beantwoorden zal je eerst moeten weten welke ondersteuning software dient te bieden aan de organisatie. De software zal dus eerst een plaats moeten krijgen binnen de informatievoorziening, binnen de informatiekundige architectuur. De informatiekundige architectuur zal dan ook onder meer een pakket eisen voor die te ontwikkelen software moeten bevatten. Die eisen zijn in termen van de organisatie beschreven, dus onafhankelijk van de technologie die op een moment beschikbaar is. Het ontwikkelen van software is zo feitelijk het 'vertalen' van de eisen in de informatiekundige architectuur naar de gekozen technologie. De inzet van een technologie, bijvoorbeeld intranet of Java, zal in principe geen wijzigingen in de informatiekundige architectuur teweegbrengen. Maar wel in de infrastructuur.
In de opsomming van activiteiten rond de infrastructuur is overigens met opzet het begrip 'functioneel beheer' niet meegenomen. Functionele aanpassingen worden immers binnen de informatiekundige architectuur uitgewerkt. En er zal onder architectuur gebouwd, gekocht of aangepast moeten worden. Functioneel beheer rond de infrastructuur komt dan in feite neer op het in stand houden van beschikbare software. Een en ander wordt in figuur 1 in beeld gebracht.
Links bevindt zich de organisatie. Deze dient gezien te worden als een samenstel van UoD's die zich laat ondersteunen door operationele informatiesystemen. Die informatiesystemen (in alle lagen) vormen samen de infrastructuur.
Rechts staan de vele modellen die van de organisatie bestaan. Eén van die modellen is de informatiekundige architectuur; het model van de informatievoorziening. Daarbij dient ernaar gestreefd te worden deze modellen zo goed mogelijk op elkaar aan te laten sluiten.
Delen van de informatiekundige architectuur zullen gebruikt worden voor het ontwerpen of kopen van software. De architectuur van de infrastructuur brengt de infrastructuur in beeld.

Het is een beeld van de beschikbare software en alles wat voor de organisatie verder nog relevant is om te weten. De architectuur van de infrastructuur moet dan ook aansluiten bij alle modellen van de organisatie. Tegelijk zal het de werkelijke ondersteuning die de infrastructuur aan de organisatie geeft duidelijk in beeld moeten brengen.

Modellen binnen een organisatie
De aansluiting tussen een informatiekundige architectuur en de andere modellen van een organisatie dient optimaal te zijn. Een informatiekundige architectuur zal daarbij, onder meer, de elementen vaststellen die in allerlei combinaties de taken en bedrijfsprocessen binnen een organisatie ondersteunen.

Figuur 1: Informatiekundige architectuur en infrastructuur

Het is een fabeltje dat het model van de bedrijfsprocessen direct afleidbaar zou zijn van een informatiekundige architectuur. Of andersom. Er bestaan krachtenvelden tussen deze modellen, en die kunnen, als ze goed opgepakt worden, tot optimale afspraken leiden. En als de 'onderhandelaars' elkaar willen begrijpen, dan voel je de synergie gewoon.
De informatiekundige architectuur dient op een voor de organisatie aansprekende manier vast te stellen wat de informatievoorziening van die organisatie is en biedt. Daarbij komen allerlei zaken aan de orde die specifiek voor de onderhanden omgeving zijn. Zo zal de cultuur van een organisatie teruggevonden moeten kunnen worden. Bijvoorbeeld in de eisen, wensen, uitgangspunten en (rand)voorwaarden die gesteld worden aan functionaliteiten als tekstverwerking, de manier waarop klantgegevens onderhouden dienen te worden, of aan hoe men financiële analyses ondersteund wil hebben, executive informatie rond personeel verkrijgt, opvragingen uit Internet doet, de wekelijkse omzetrapportage opzet, de koppeling tussen het klantensysteem en de Gemeentelijke Basis Administratie verwezenlijkt, en ga zo maar door. Zo krijg je een lange lijst met uitspraken rond dit soort afgeronde functionele eenheden (vaak logische transacties genoemd).
Het is heel goed mogelijk deze functionele eenheden naar soort onder te brengen in een beperkt aantal groepen. Die groepen kunnen dan samen het beeld vormen van de functionaliteit van de informatievoorziening. En daarmee zijn ze een belangrijk onderdeel van de informatiekundige architectuur.
De informatiekundige architectuur omvat naast dit beeld van de functionaliteit nog een reeks andere zaken. Heel belangrijk daarbij is de vaststelling wat nu informatie is en wat niet. Functionele eenheden bewerken immers informatie (of gegevens). En het resultaat kan weer door andere functionele eenheden bewerkt worden. Echter, feiten zijn feiten. Als feiten betekenis hebben voor de organisatie, is het informatie. Functionele eenheden bewerken vrijwel altijd een combinatie van feiten, en feiten kunnen op hun beurt weer door meer functionele eenheden bewerkt worden.
Als je nu per functionele eenheid te werk gaat, kom je tot de ontdekking dat je steeds weer dezelfde feiten tegenkomt. Een compleet conceptueel informatiemodel (CIM) voor een organisatie is erg belangrijk, maar vaak ook erg groot. Om daar toch overzicht in te houden, bestaan er technieken om de hoofdlijnen op enkele A4'tjes te zetten. Aan de hand van die hoofdlijnen kan dan een verdeling gemaakt worden, die per deel wel modelleerbaar is. Door dit binnen de hoofdlijnen af te stemmen ontstaat toch, uiteindelijk, een compleet CIM: een tweede belangrijk onderdeel van een informatiekundige architectuur.
Naast deze twee elementen zijn er nog legio zaken die een plaats dienen te hebben binnen een informatiekundige architectuur. Zo zijn uitspraken over het gewenste gedrag van (delen van) de informatievoorziening belangrijk. Het gaat zowel om algemene uitspraken als om meer procesmatige zaken (opstartcriteria, flows enzovoort). En dan zijn er ook nog de algemene uitspraken over bijvoorbeeld opleidingen, conversie, gebruikerstesten en performance. Al deze delen samen vormen een informatiekundige architectuur.

Het bestek
In een vergelijking met de bouwwereld vertoont het bovenstaande, vooral waar het om gestelde eisen, wensen, uitgangspunten en (rand)voorwaarden gaat, veel overeenkomst met wat een bestek genoemd wordt. In Van Dale's Woordenboek staan veel definities van het woord bestek. Voor dit artikel zijn de volgende relevant:

• Een bestek is een zo volledig mogelijk omschreven bouwplan. Men maakt iets volgens een bestek, ofwel men houdt zich aan de daarin opgegeven schaal van afmetingen.
• Een bestek is een omschrijving van de te volgen strategie. In het vervolg van deze uitleg staat dat een bestek een beschrijving is van de te nemen stappen.
• Een bestek is een bepaalde, begrensde ruimte. Als uitleg staat er, dat iets in kort bestek uiteengezet kan worden.
• Een bestek is een plan waarnaar een schrijver zijn werk uitvoert. Met als uitleg de zin: 'dit uitvoeriger te omschrijven valt buiten ons bestek.'

In lijn met deze definities kunnen we de hardere uitspraken (eisen, wensen, uitgangspunten en (rand)voorwaarden) binnen en rond de opzet en inrichting van de informatievoorziening als een bestek zien. Zo'n bestek4 is dus de 'harde' kern van een informatiekundige architectuur.
Waarom is een bestek belangrijk? Zoals gezegd dient een informatiekundige architectuur niet alleen te passen bij de andere modellen van de organisatie, maar het zal ook de basis moeten geven voor het starten van veranderingen.
Binnen het VRI-model5, opgesteld binnen het VRI en door Jan Dietz beschreven in zijn artikel6, is het opstellen van een informatiekundige architectuur vergelijkbaar met wat binnen de werkzaamheid Architectureren valt. Volgens de beschrijving in zijn artikel resulteert deze werkzaamheid in architecturen, die verder uitgewerkt worden in de werkzaamheden Ontwikkelen en Implementeren. Beheer volgt.
In dit artikel wordt een informatiekundige architectuur breed (of breder) in de organisatie gezien.

Als een informatiekundige architectuur er eenmaal is, dient deze bijgehouden (beheerd) te worden. Maar als binnen het bestek software gemaakt of gekocht moet worden, dan volgen werkzaamheden als Ontwikkelen en Implementeren. En hier is juist het bestek heel belangrijk. De ontwikkelaar zal immers bij het inzetten van technologie (IT, ICT) aan de uitspraken van de organisatie in de informatiekundige architectuur moeten voldoen. Vooral de elementen uit het bestek zullen belangrijk zijn voor de ontwikkelaar als hij bijvoorbeeld applicaties, objecten of complete informatiesystemen gaat ontwikkelen of kopen. Het is hetzelfde traject als object georiënteerde ontwikkelmethoden en methoden als RAD, JAD, MAD, IAD enzovoort afdekken.
Daarna volgt Implementeren. Hier gaat het om het aanpassen van de bestaande infrastructuur met de nieuw ontwikkelde software. Er verandert dus iets in de werkelijke ondersteuning van de organisatie. Beheer van de software binnen de infrastructuur is de volgende stap. We spreken dan wel over technische beheeractiviteiten. Zoals gezegd zal bij het functionele beheer en het beheer van wijzigingen de informatiekundige architectuur leidend zijn.
Vertalen we dit terug naar de wereld van methoden en technieken, dan wordt een zelfde indeling neergezet in de vergelijking van methoden voor systeemontwikkeling van de NGGO7. Ook hier vinden we een indeling in de aspecten Informatie, Functie en Gedrag. De resultaten van de fasen Definitie en Analyse zijn te vergelijken met de werkzaamheid Architectureren. Deze kunnen voor een groot deel ondergebracht worden in het bestek. En ook hier volgen fasen als Ontwerp en Realisatie. Zo is een vertaling van informatiekundige architecturen naar de respectievelijke methoden en technieken voor systeemontwikkeling snel te maken.
Zoals gezegd is het bestek de harde vastlegging van wat de organisatie wil binnen en met zijn informatievoorziening. En willen we op basis van de informatiekundige architectuur ontwikkelen, implementeren en technisch beheren, dan zal het bestek een grote hoeveelheid uitspraken moeten bevatten om op een goede manier 'onder architectuur te kunnen bouwen of kopen'.

Conceptual schemas
Het ziet ernaar uit dat binnenkort een nieuwe internationale ISO-standaard van kracht wordt. Het gaat om de ISO-14481 standaard rond Conceptual Schema Modelling Facilities (CSMF)8. Deze heeft op dit moment de status Final Committee Draft.
Het interessante aan die nieuwe standaard in relatie tot informatiekundige architecturen is dat er stringente regels en definities gegeven worden ten aanzien van de inhoud en opzet van Conceptual Schemas. Een Conceptual Schema kan goed vergeleken worden met het harde deel van de informatiekundige architectuur, het bestek dus.
De CSMF-standaard identificeert en definieert, zowel formeel (met wiskunde) als in taal, de begrippen die gebruikt worden bij het opzetten van bestekken. Het doel is de in een bestek gebruikte begrippen wereldwijd te standaardiseren. Daarmee wordt een gemeenschappelijk begrippenkader neergezet voor mensen die zich met Conceptual Schemas bezig houden. In bovenstaande termen dus met bestekken binnen informatiekundige architecturen.
Voordat de normatieve begrippen in de standaard aan bod komen, wordt eerst een reeks principiële uitspraken gedaan. De volgende, met een vrije uitleg, mogen hier niet ontbreken:

• 100% principe: een Conceptual Schema dient alle regels vast te leggen die in de UoD9 gevonden kunnen worden ten aanzien van de informatievoorziening. Men streeft dus naar compleetheid.
• Conceptualisatie principe: een Conceptual Schema dient alleen conceptueel relevante aspecten, zowel structureel als gedragsmatig, te bevatten die te maken hebben met de UoD. Dus geen technologie of andere, min of meer, tijdelijke zaken.
• Helsinki principe: er kan pas gecommuniceerd worden als de deelnemende partijen dezelfde betekenis en regels hechten aan waar ze over praten. Dus: eerst afspraken maken over waar men mee bezig is. Dit gebeurt bij voorkeur al tijdens de opleiding.
• Zelfbeschrijvend: de begrippen in de standaard zijn in staat zichzelf te beschrijven. Met compleet wordt echt compleet bedoeld.

Als hoofdbegrip wordt Entity gedefinieerd: 'any concrete or abstract thing of interest'. De normatieve begrippen worden, via overerving, alle gezien als bepaalde entities. Daarnaast wordt het verschil tussen type en instance als cruciaal gezien. Populair gezegd: een type wordt gedefinieerd en een instance geeft de populatie die binnen die definitie past.
In totaal zijn er tien normatieve begrippen. Zeven daarvan worden in het verlengde van de drie overblijvende gedefinieerd. Die drie zijn:

• UoD-entity: an entity that is recognized as having real or hypothetical existence in the UoD. Een UoD-entity type is bijvoorbeeld Hotel met als instances Hilton Rotterdam en Amstel Hotel Amsterdam.
• Fact: a proposition involving one or more entities each of which plays a distinct role, and which is held to be meaningful and true. Feit dus als informatie, niet als gegeven.
• Process: a chosen set of events. Een voorbeeld van een process type is 'Persoon inboeken in Hotel' met als instances 'Jan wordt ingeboekt in Hilton Rotterdam' en 'Klaas wordt ingeboekt in Amstel Hotel Amsterdam'.

Vervolgens worden de zeven afgeleide normatieve begrippen genoemd: Constraint, Event, Trigger, Agent, Input, Output en Message. En daar blijft het bij.
Volgens deze standaard zijn er dus tien, onderling gerelateerde begrippen die samen een 100 procent complete en conceptuele specificatie opleveren van een UoD. Zo'n specificatie heet een Conceptual Schema. De overeenkomst tussen wat hier bestek genoemd wordt en een Conceptual Schema, is heel groot.

De informatie-architect
In het voorgaande wordt steeds gesproken over informatiekundige architecturen. Er zullen mensen moeten komen, die van het werken aan informatiekundige architecturen hun beroep maken. Zij worden informatie- of informatiekundige architecten10 genoemd.
Volgens Van Dale's Woordenboek is een architect iemand die de plannen voor gebouwen ontwerpt en op de uitvoering van die plannen toezicht houdt. Een informatiekundig architect werkt niet aan gebouwen. Hij brengt de informatievoorziening van een organisatie, of een deel daarvan, in beeld. Uiteindelijk zal de informatiekundig architect zicht krijgen op de gehele informatiekundige architectuur.
Een informatiekundig architect houdt zich waarschijnlijk meer bezig met planologie (de leer van de bestemming en het gebruik van de bodem, van gebieden enzovoort) dan met 'gebouwen', of hij houdt zich bezig met de toepassing van de planologie; de ruimtelijke ordening.
Anders gezegd, een informatiekundig architect houdt zich niet alleen bezig met de architectuur van informatiesystemen ('gebouwen'), hij zal breder (moeten) kijken. Een informatiekundige architectuur is dan ook beter vergelijkbaar met een bestemmingsplan waarin het geheel aan bij de organisatie passende functionaliteit voor de UoD is opgenomen. Binnen zo'n informatiekundige architectuur kunnen elementen gecombineerd worden die door automatiseerders (IT'ers ICT'ers) omgezet kunnen worden naar werkende delen in de infrastructuur.
De term informatiekundig architect wordt als verzamelnaam voor meer beroepen gebruikt. In lijn met de occupatievlakken binnen het VRI-model gaat het waarschijnlijk om:

• Uitvoerend: de informatiekundige architect zelf, die informatiekundige architectuur maakt en bijstelt, en de realisatie daarvan begeleidt.
• Adviserend: de informatiekundig adviseur. Dit is de man of vrouw die een organisatie helpt bij het opstellen van een informatiekundige architectuur.
• Onderwijzend: de informatiekundig docent. De leraar/docent die mensen leert wat informatiekundige architecturen zijn.
• Controlerend: de informatiekundig auditor. De auditor of kwaliteitsfunctionaris die controleert of een informatiekundige architectuur naar behoren in elkaar gezet is.
• Leidinggevend: de informatiekundig manager. Degene die veranderingen in de informatievoorziening managet. Het is misschien lastig om dit als een beroep neer te zetten, want managers zullen vaak breder bezig zijn.

Op een beperkt aantal plaatsen vinden we al mensen die één van deze beroepen uitvoeren. Op dit moment is het wel zo, dat het trendy is om je informatie-architect te noemen. Dat verdient kennelijk goed.
Overal, in praktijk en theorie, blijkt de behoefte aan informatiekundige architecturen en informatiekundig architecten. De ervaring binnen het Nederlands Genootschap voor Informatie Architecten (NGIA) leert dat er haast net zoveel meningen zijn over wat een informatiekundige architectuur is, als dat er mensen zijn die zich informatie-architect noemen. Dat is jammer, want zo vertroebelt het beeld van wat een informatie-architect is en doet snel. Straks is het net als bij de informatie-analist, waar zowel organisatiedeskundigen als programmeurs zich als zodanig presenteren. We zullen eraan moeten werken om het begrip zelf en de functies helder te krijgen voordat een en ander weer als hype wordt afgedaan.
De uitspraken in dit artikel en de visies die zijn neergelegd dienen vooral om de gedachten te bepalen, en niet zozeer om vast te stellen hoe het is of zou moeten zijn. Die vaststelling is overigens wel hard nodig. Daarvoor moet eerst voldoende draagvlak gecreëerd worden. En daar wordt aan gewerkt.

www.NGIA.nl Nederlands Genootschap voor Informatie Architecten

Het Nederlands Genootschap voor Informatie Architecten is in de lente van 1998 opgericht als beroepsvereniging voor informatie-architecten. De organisatie heeft zich tot doel gesteld om de beroepen rond informatiekundige architecturen op niet-commerciële basis vorm te geven. Uiteindelijk zou dan over certificatie van die beroepen gesproken kunnen worden.
NGIA is een zelfstandig onderdeel van de Nederlandse Gebruikersgroep voor Gestructureerde Ontwikkelingsmethoden (NGGO). Omdat NGIA volledig gebruik kan maken van de reeds ingerichte organisatie van de NGGO, kon een vliegende start worden gemaakt.
Een eerste peiling naar de behoefte aan een organisatie als NGIA heeft aangetoond dat er heel veel animo bestaat voor een beroepsvereniging voor informatie-architecten. Op een via e-mail gehouden peiling naar 1000 adressen heeft 30 procent geantwoord. Daarvan bleek meer dan 95 procent positief tot zeer positief te zijn. De reacties kwamen zowel van uitvoerend informatie-architecten als van adviseurs, docenten, auditors en managers. Voldoende reden om NGIA snel verder uit te bouwen.
NGIA is een zelfstandig opererende organisatie die niet wil concurreren met andere organisaties. Om die reden staat NGIA open voor contacten met andere organisaties als VRI, NGI, NOREA, SIAN, FENIT enzovoort.
Van leden van de NGIA wordt een zekere activiteit verwacht. Deelname aan kortlopende werkgroepen, lezingen, congressen, een eigen blad, bijhouden van een actieve homepage enzovoort.