April 2000: Een informatie-architectuur is geen IT-architectuur

Een informatie-architectuur omvat alle afspraken die met een organisatie gemaakt dienen te worden over en rond de informatie van die organisatie. Gewoonlijk is dat een complexe verzameling van aan elkaar gerelateerde uitspraken die mensen in staat stelt om passende oplossingen te realiseren voor de informatiebehoefte in hun organisatie. Een IT-architectuur is het beeld van de IT-infrastructuur. De IT-infrastructuur is een onderdeel van de informatie-infrastructuur van een organisatie: het is dat deel van de informatievoorziening dat ingericht is met IT.In dit artikel wordt aangetoond dat er een groot verschil bestaat tussen een informatie-architectuur en een IT-architectuur. Dat verschil is belangrijk en dient expliciet aangehouden te worden.

Het op de juiste manier inzetten van informatietechnologie als hulpmiddel in een organisatie is bepaald geen triviale taak. Het vereist natuurlijk diepgaande kennis van de technologie. Maar dat is niet alles. Voor een effectieve inzet is ook kennis van de organisatie en van de communicatie en informatie binnen die organisatie cruciaal. Dat zijn allemaal expertises op zich, die een eigen opleiding vereisen en, zoals in de praktijk blijkt, moeilijk te combineren zijn in één persoon.
De woorden 'architect' en 'architectuur' zijn aan het einde van het vorige millennium steeds vaker in relatie gebracht met informatiekunde en automatisering. Rond de wisseling van het millennium kon zelfs van een hype gesproken worden. De zoveelste. Naast architecten in de bouwwereld, binnenhuisarchitecten, marine-architecten, stereoarchitecten en taartarchitecten bestaan er nu dus ook informatie-architecten en IT-architecten.
Zoals dat ook bij andere modeverschijnselen gaat, lijken de basisconcepten, -noties en -essenties verloren te gaan in een wolk van eigen interpretatie en verkoopgebabbel. Allerlei mensen geven een eigen interpretatie aan begrippen als architectuur en architect. Heel soms gebeurt dat omdat ze niet beter weten, vaker omdat het gewoon veel geld opbrengt. We kennen tegenwoordig in onze vakgebieden dan ook beveiligingsarchitecten, ontwikkelarchitecten, informatie-architecten, applicatie-architecturen, technische architecten, hardware-architecturen, procesarchitecten, IT-architecten en ga zo maar door. Het lijkt niet op te houden.
In dit artikel wordt geschreven over informatie-architecten en IT-architecten. Om de overeenkomsten en de verschillen op een rij te krijgen wordt het geheel eerst in perspectief gebracht in een meta-architectuur. Dit wordt gedaan om de stelling in de titel toe te lichten.

Meta-architectuur
Om over verschillen en overeenkomsten tussen respectievelijk architecten en architecturen te kunnen praten, zullen we eerst moeten achterhalen waarover we praten. In figuur 1 is daarom een architectuur van architecturen getekend: de meta-architectuur.
Het doel van een meta-architectuur is de relevante beelden van de werkelijkheid in relatie tot elkaar in beeld te brengen. In dit geval zijn informatiekunde en automatisering daarbij de invalshoeken. Zo kunnen we een plaats vinden voor wat relevant is, in een onderlinge relatie.

Figuur 1: De meta-architectuur

In de praktijk wordt een zeer uitgebreid arsenaal aan termen en concepten gebruikt. Door deze in de juiste context te plaatsen, blijken er veel synoniemen en homoniemen. Door deze goed en compleet in beeld te brengen, kan een eenduidige, veel simpeler terminologie worden uitgewerkt (zoals bijvoorbeeld gebeurd is in de ISO/IEC FCD 14481-standaard1).
In de meta-architectuur in figuur 1 staat links van de verticale lijn de werkelijkheid, en rechts staan de architecturen. Iedere architectuur geeft een beeld van die werkelijkheid vanuit een bepaalde invalshoek.
In de werkelijkheid bestaan onder meer heel veel organisaties. Vrijwel elke organisatie heeft een informatievoorziening. Tegenwoordig zijn die voor een groot deel ingericht met behulp van informatietechnologie. Dit geheel wordt de informatie-infrastructuur genoemd. Een informatie-infrastructuur kan een organisatie, een deel van een organisatie of soms zelfs meer organisaties ondersteunen. Eén gecontroleerde informatie-infrastructuur voor alle organisaties lijkt in ieder geval een utopie. Daarom kijken we ook niet naar alle organisaties tegelijk, maar naar één organisatie, een deel daarvan of eventueel naar een paar organisaties. Dit relevant geachte deel wordt de Universe of Discourse (UoD) genoemd.
Rechts in de figuur staan dus de architecturen. Elke organisatie neemt mensen in dienst om de nodige taken te vervullen. Omdat deze mensen meestal opgeleid en/of gespecialiseerd zijn, hebben zij een bepaalde, eigen kijk op de organisatie. Als meer mensen hetzelfde beroep of specialisme hebben, dan zullen ze afspraken met elkaar moeten maken over wat ze zien. Je kunt immers niet werken met 100 of 10.000 verschillende manieren van kijken naar en denken over hetzelfde onderwerp. Ze zullen samen een vergelijkbaar beeld moeten opbouwen om goed te kunnen samenwerken. Zo'n beeld is een architectuur.
Vanuit het perspectief van informatiekundigen en automatiseerders zijn diverse architecturen van een organisatie relevant. De bedrijfsprocesarchitectuur is relevant omdat bedrijfsprocessen de meeste en beste aanknopingspunten geven bij het aansluiten van de informatievoorziening. Maar we kennen ook andere beelden. De manier zoals bijvoorbeeld juristen, administrateurs, controllers en logistiek specialisten naar organisaties kijken, kan immers ook zeer relevant zijn.
Automatiseerders (IT'ers of ICT'ers) kijken vooral naar de inzet van IT in de informatie-infrastructuur en de aansluiting daarvan op de UoD. De architectuur van de informatie-infrastructuur - of in beperkter vorm: van de IT-infrastructuur - is het beeld dat de automatiseerders hebben van de informatie-infrastructuur in de werkelijkheid. Daarbij hoort ook het beeld van de aansluiting van die infrastructuur bij de UoD. Dit is de basis die nodig is voor business of strategic alignment.
Informatiekundigen hebben een ander beeld van de werkelijkheid dan automatiseerders. Zij kijken naar de informatie in de UoD en de afspraken die daarover gemaakt dienen te worden met de organisatie. Op basis daarvan kunnen veranderingen van de infrastructuur gestuurd worden. In automatiseringstermen hebben we het hier over de veranderingen die door systeemontwikkeling gerealiseerd worden. De architectuur van de informatiekundige is de informatie-architectuur.
Het is niet gemakkelijk te bepalen wat in ons vakgebied een architectuur is en wat deze dient te omvatten. Bij reeds lang bestaande disciplines zoals 'personeel' en 'juridisch' is dat makkelijker.

Daar zijn de principes bekend en nauwelijks (of in ieder geval minder) onderwerp van discussie. Het gaat in zo'n geval dus eigenlijk alleen om het in beeld brengen van een bepaalde UoD.
Bij informatiekundigen en automatiseerders gaat het niet alleen om de inhoud. Steeds weer lijkt vastgesteld te moeten worden wat de principes, concepten en termen in die omgeving zijn. Het vereist goede communicatie, soms harde onderhandelingen en standaarden als ISO 14481 om een en ander vast te stellen. Dat is de enige weg naar één manier van denken over en rond architecturen.

Architectuur van de informatie-infrastructuur
Wat zien IT-specialisten (ICT'ers, automatiseerders) als zij naar een organisatie kijken? Zij zien wat relevante delen van de informatie-infrastructuur voor een gegeven UoD kunnen doen. Meer specifiek kijken zij vooral naar de onderdelen van die informatie-infrastructuur die in zekere mate geautomatiseerd zijn. Dit deel wordt wel de IT-infrastructuur genoemd. Vormen we ons een beeld van de IT-infrastructuur, dan krijgen we de IT-architectuur. In figuur 1 vinden we beide als onderdeel van respectievelijk de informatie-infrastructuur en de architectuur van de informatie-infrastructuur.
De architectuur van de informatie-infrastructuur omvat een totaalbeeld van de ondersteuning die een UoD krijgt van een bestaande informatie-infrastructuur. De IT-architectuur daarbinnen wordt steeds belangrijker. De belangrijkste reden hiervoor is dat IT steeds vaker wordt ingezet in plaats van 'conventioneel' geachte methoden en technieken als archieven, pen en papier.
Een IT-architectuur kan opgedeeld worden in diverse, separate beelden. Het geheel kunnen we opdelen in:2

• architectuur van de applicatie-infrastructuur. Hier vinden we de applicaties, informatiesystemen, OO-objecten, componenten enzovoort die voorhanden zijn om gegevens voor gebruikers binnen de UoD vast te leggen en te bewerken.
• architectuur van de gegevensinfrastructuur. Wat mensen in de UoD werkelijk willen is informatie, geen applicaties of gegevens. Gegevens die betekenis hebben in de UoD zijn de informatie. Daarom zal de gegevensinfrastructuur in de toekomst steeds belangrijker worden. De architectuur van die gegevensinfrastructuur zal een model omvatten van de manier waarop de gegevens gestructureerd vastgelegd zijn binnen de informatie-infrastructuur. Het gaat daarbij om de structuur waarop gegevens op schijf, tape, CD, DVD enzovoort vastgelegd zijn. Relevante zaken hierbij zijn onder andere databases, datamarts, documentbases, replicatie, back-up/restore-bestanden, mirroring, duplicatie, extractie, defragmentatie, die hier dan ook een plaats zullen vinden.
• architectuur van de systeemsoftware-infrastructuur. Hier vinden we het beeld van de gebruikte operating systems als DOS, Windows 2000, Unix, Linux, Windows NT, MVS en VMS. De beweging naar open systemen, distributie, CORBA, broker/trader-functionaliteit enzovoort maakt van systeemsoftware steeds meer een separate laag. Het is voor de gebruiker immers niet relevant waar de informatie vandaan gehaald wordt en hoe het daar werkt: doorzichtigheid ('transparency') is het motto.
• architectuur van de hardware- en netwerkinfrastructuur. In dit deel wordt de technische infrastructuur in kaart gebracht. Hier zien we onder meer mainframes, PC's, hubs, routers, telefoonlijnen, encryptieapparatuur, harde schijven, back-up tapeapparatuur en glasvezel- of coax-kabels.
  Verder hoort hier nog een beeld van de manier waarop de beveiliging opgezet is, hoe een en ander onderhouden en geëxploiteerd wordt, hoe de helpdesk ingericht is, hoe probleemmanagement werkt enzovoort. Dit alles is onderdeel van de architectuur van de informatie-infrastructuur.

Bedrijfsprocesarchitectuur
Zijn we in staat om de volgende vraag te beantwoorden: hoe kunnen we de effectiviteit van de ondersteuning, die de informatie-infrastructuur aan de UoD levert, meten? En kunnen we de juiste informatie op het juiste moment, op de juiste plaats en van de juiste kwaliteit in de UoD krijgen? Belangrijke, maar op dit moment in de praktijk meestal niet beantwoorde vragen. We kunnen de vraag ook stellen zoals die in de praktijk vaak leeft: kunnen we meten hoe goed ons geld besteed wordt als we investeren in onze informatie-infrastructuur?
Laten we eens naar de basis kijken zonder in economische principes of metrics te vervallen. Organisaties zijn op een bepaalde manier en in een bepaalde mate georganiseerd. Belangrijk is dat een organisatie bestaat om één of meer doelen te halen. Deze doelen worden nagestreefd door activiteiten en taken uit te voeren. Combinaties van activiteiten en taken vormen bedrijfsprocessen. Primaire bedrijfsprocessen zijn bedoeld om de gestelde doelen zelf te bereiken. Secundaire, tertiaire en quartaire bedrijfsprocessen ondersteunen elk op een bepaalde manier en in een bepaalde mate.
Het beeld dat we van alle bedrijfsprocessen samen hebben heet de bedrijfsprocesarchitectuur. Het is een architectuur die feitelijk buiten het directe werkveld van de informatie- en de IT-specialist ligt. Voor hen is in een bedrijfsprocesarchitectuur slechts relevant:

• de beschrijving van de doelen die de organisatie wenst te halen of nastreeft, evenals de visie die men heeft, het beleid dat gevoerd wordt en mogelijke specifieke eisen, wensen, randvoorwaarden en uitgangspunten die men daarbij hanteert. We spreken hier over de organisatie zelf, over de 'business'. Binnen een bank vinden we alles over bankieren, bij een winkel vinden we alles over hoe een winkel opgezet en geleid moet worden en bij de overheid vinden we alles over hoe we een gemeente of het Rijk besturen.
• de manier waarop bedrijfsprocessen op een bepaald moment in de tijd ingericht zijn
• de wijzigingen die men wil doorvoeren in de bestaande inrichting van die bedrijfsprocessen.

informatiekundigen hebben een ander beeld van de werkelijkheid dan automatiseerders
Waarom is dit alles nu zo van belang bij het beantwoorden van vragen over de effectiviteit van de ondersteuning door de informatie-infrastructuur? We kijken hier alleen naar de IT-infrastructuur binnen de informatie-infrastructuur.

In de IT-architectuur hebben we een architectuur van zowel de applicatie-infrastructuur als de gegevensinfrastructuur onderkend. Bedrijfsprocessen kennen activiteiten (of taken). Elk van deze activiteiten is een afgeronde hoeveelheid werk die in een organisatie uitgevoerd dient te worden. Bij elke afzonderlijke activiteit kan uitgewerkt worden welke behoefte aan informatie men heeft en of deze behoefte al of niet ingedekt wordt door applicaties en/of gegevens in de informatie-infrastructuur.
Relateren we de applicaties uit de applicatie-infrastructuur aan de activiteiten van de bedrijfsprocessen, dan kunnen we zien welke ondersteuning werkelijk geleverd wordt. We kunnen zelfs naar de kwaliteit van die ondersteuning kijken, en of die compleet en op het juiste moment geleverd wordt. Er kan dus worden vastgesteld hoe 'blij' mensen zijn met de ondersteuning die ze krijgen. En langs deze weg komen we in de buurt van het 'kunnen meten van de effectiviteit' van die ondersteuning.
Een andere, scherpere mate van effectiviteit kunnen we vinden als we de in de informatie-infrastructuur beschikbare gegevens relateren aan de activiteiten binnen de bedrijfsprocessen. Mensen zitten immers niet te wachten op applicaties, maar op de informatie die ze nodig hebben om naar behoren te kunnen werken.3
Als we naar de toekomstige opzet van bedrijfsprocessen kijken, is het natuurlijk niet voldoende om alleen naar de huidige applicaties en gegevens te kijken. Dan is een gedetailleerd inzicht van welke gegevens informatie zijn en wat we moeten doen om een optimale ondersteuning van de organisatie te kunnen realiseren, noodzakelijk. Dit alles samen is wat we een informatie-architectuur noemen. Samen zal dit een beeld, een architectuur van de inrichting van de toekomstige informatie-infrastructuur, dienen op te leveren.

Informatie-architectuur
Een informatie-architectuur is dus een gedetailleerd beeld van wat informatie is en welke acties nodig zijn om een optimale ondersteuning van een UoD te kunnen krijgen. Als eerste moet daarbij worden vastgesteld welke gegevens voor de UoD informatie zijn. Dit kan alleen vastgesteld worden als we de context kennen: dat is dus de UoD. Deze context kan gestructureerd teruggevonden worden als bedrijfsprocesspecialisten een en ander in kaart hebben gebracht in een bedrijfsprocesarchitectuur.
Wat omvat een informatie-architectuur precies? In feite is het een lange reeks afspraken en uitspraken. Deze kunnen in vijf groepen ingedeeld worden:

• hoofdlijnen. Beschrijft in algemene termen wat informatie is en wat een UoD daar mee wil.
• modellen. Geeft een diepgaande beschrijving van de informatie en de functies in de vorm van conceptuele modellen.
• Algemeen. Omvat allerlei afspraken. Deze afspraken zijn vaak gebaseerd op normen en standaarden.
• toekomstige informatie-infrastructuur. Zet de uitgangspunten ten aanzien van de inzet van oplossingen in de informatie-infrastructuur op een rij en geeft een beeld van hoe de informatie-infrastructuur er in de toekomst uit moet gaan zien.
• veranderingen. Beschrijft en plant de veranderingen die in de huidige informatie-infrastructuur doorgevoerd dienen te worden.

Hoofdlijnen
In deze groep vinden we het algemene beeld dat de organisatie (de UoD) heeft op haar informatie. Het zal duidelijk zijn dat deze visie dient aan te sluiten op wat de organisatie zich tot doel stelt.
mensen zitten niet te wachten op applicaties maar op informatie om naar behoren te kunnen werken

Essentieel in deze groep is het begrip informatie. Informatie zijn die gegevens, die in de context van de organisatie betekenis hebben. Zo zal de precieze samenstelling van een bepaald medicijn niet relevant zijn voor bijvoorbeeld een energiebedrijf en zal de gedetailleerde onderhoudsstatus van een verkeersbrug niet direct relevant zijn voor een winkel. Informatie is datgene waarmee men werkt, wat men uitwisselt. Energie stoppen in gegevens is feitelijk energie verspillen, en dat kunnen organisaties zich niet veroorloven.
Binnen een vastgesteld bedrijfsbeleid kunnen afspraken gemaakt worden over de manier waarop men met informatie wenst om te gaan en hoe dit middel zich in de toekomst dient te ontwikkelen. Alle informatie samen zal de samengestelde informatiebehoefte van een organisatie af dienen te dekken. (Dus alle informatie die nodig is om bedrijfsprocessen naar behoren te laten verlopen.) Een informatievisie is dan niets meer of minder dan de manier waarop een organisatie met haar informatie wenst om te gaan. Uit zo'n informatievisie moet een informatiestrategie en een informatiebeleid afgeleid worden.
Een informatievisie is meestal alleen een hoeveelheid woorden, soms verluchtigd met wat plaatjes. Om de visie ook op te kunnen leggen, zijn de volgende vertalingen erg belangrijk:

• de architectuur van de informatiestructuur is een globaal beeld van de informatie in de UoD
  Normaal bevat zo'n architectuur tussen de drie en twaalf aan elkaar gerelateerde begrippen (in ISO 14881 entity-types genoemd) die samen de structuur van de informatie binnen de UoD in kaart brengen. Deze architectuur onderbouwt de informatievisie en geeft richting en structuur aan de informatie van een UoD. Met een korte beschrijving is het geheel meestal prima herkenbaar voor het management. Daarmee is het een krachtig stuurinstrument om de investeringen te begrijpen en in de hand te houden.
• de functionele architectuur brengt de functionaliteit globaal in beeld
  Dit wordt gewoonlijk gegroepeerd in zeven tot tien groepen. Deze architectuur dient hetzelfde doel als de in het vorige punt genoemde architectuur van de informatiestructuur.
  De onderdelen van de groep 'hoofdlijnen' geven samen grip op de informatievoorziening en de ontwikkeling daarvan.
  Modellen
  Een model is een nabootsing van de werkelijkheid. In deze groep vinden we twee conceptuele modellen die respectievelijk de informatie en de functionaliteit tot in de grootste mate van detail kunnen4 vastleggen:
• het conceptueel informatiemodel (CIM) definieert de informatie van een UoD en de structuur van die informatie in termen van begrippen (entity-types), fact-types en constraint-types.
  De praktijk wijst uit dat een compleet model van een UoD, de beschrijving en de plaatjes, in honderd tot enkele honderden bladzijden uit te werken is.
• het conceptueel functiemodel (CFM) werkt elementaire functionaliteit uit in termen van process-types, inputtypes, outputtypes, agenttypes en message-types. Per functie worden de 'business-rules' (de functionele regels, waarvan veel zich vertalen in constraint-types) binnen de UoD uitgewerkt die opgelegd worden aan de informatieverwerking.
  Een CIM is de uitwerking van de architectuur van de informatiestructuur, een CFM is de uitwerking van de functionele architectuur.
  Algemeen
  De groep 'algemeen' omvat een lange reeks afspraken en van toepassing verklaarde normen en standaards. De inzet en/of toepassing zal minimaal beschreven moeten zijn in termen van de UoD, zodat de organisatie kan begrijpen waar het om gaat.
  Zonder compleet te willen zijn, onderkennen we de volgende categorieën:
• relatie informatie-architectuur en bedrijfsprocessen
  Hier wordt de door de UoD gewenste ondersteuning, de informatiebehoefte, op een rij gezet. Er zijn minimaal twee relaties relevant:
  -tussen de begrippen uit het CIM en de (activiteiten binnen de) bedrijfsprocessen
  Belangrijk is dat aangegeven wordt wie eigenaar is van bepaalde informatie, wie informatie mag wijzigen en wie alleen informatie gebruikt.5
  -tussen functies uit het CFM en de (activiteiten binnen de) bedrijfsprocessen
  Op deze manier kan de nodige functionaliteit op een rij worden gezet.6
  Door deze relaties samen met 'bedrijfsprocesspecialisten' uit te werken, ontstaat de synergie die bijvoorbeeld bij Business Process Re-engineering (BPR) verwacht, maar vaak gemist werd.
• beheer
  Dit omvat de afspraken die gemaakt moeten worden met de organisatie rond technisch beheer, configuratiemanagement, de helpdesk en andere aan beheer gerelateerde activiteiten. Methoden als ITIL zijn hier vaak een goede start. Hier vinden we ook bijvoorbeeld de service level agreements (SLA's).
• onderhoud
  Dit zijn de afspraken rond hoe het onderhoud van de informatie-infrastructuur uitgevoerd wordt (preventief, correctief, adaptief, modificatief enzovoort).
• gedrag van de informatie-infrastructuur
  Hier vinden we de afspraken rond de manier waarop de informatie-infrastructuur zich gedraagt en dient te gedragen in de relatie met de gebruiker van die infrastructuur. Gewoonlijk vinden we hier onder meer standaarden als CUA en GUI.
• methodologiën/methodieken, methoden, technieken en hulpmiddelen
  In deze categorie staan de afspraken die gemaakt worden over de manier waarop het wijzigen van de informatie-infrastructuur 'normaal' aangepakt wordt, en welke ondersteuning daarbij verleend wordt. In het algemeen worden hier, in het kader van de informatie-architectuur, de volgende algemene onderdelen onderkend:
  -wijzigingsverzoek: dit is een uit te werken verzoek tot het veranderen van de bestaande informatie-infrastructuur.
  -toepasbaarheids- of specificatiefase: wat we al weten van wat de organisatie aan ondersteuning wenst, hoeven we niet meer uit te zoeken. Wat we weten is immers onderdeel van de informatie-architectuur. Is dat veel, dan hoeven we alleen een toepasbaarheidsanalyse uit te voeren om te kijken of het gestelde nog steeds is wat men wenst. Anders zullen we een specificatie moeten maken. Hoe we het bestek ook samenstellen, het resultaat dient volledig ingebed te worden in de informatie-architectuur. Het bestek dient van zodanige kwaliteit te zijn dat het resultaat voor eenieder helder is en dat met de inhoud de realisatie aanbesteed kan worden. Aanbesteden kan daarbij betekenen inbesteden ('zelf doen') of uitbesteden (bij een aannemer of door bijvoorbeeld software te kopen, procurement).
  -ontwerp en realisatie: hier wordt aan de nieuwe applicaties een 'gezicht' gegeven (voorheen functioneel ontwerp) en wordt een en ander gerealiseerd en klaargemaakt voor invoering. Hier vinden we methoden en technieken als Rapid Application Development (RAD), Object Oriented Analysis/Development (OOA/OOD) en Component Based Development (CBD).
  -invoering: hier gaat het erom dat de gerealiseerde acceptatie door de aanbestedende organisatie geaccepteerd wordt en dat het geheel een plaats krijgt in de informatie-infrastructuur (het operationeel stellen). Het geheel wordt hier ook overgedragen aan de technisch beheerders en de mensen die het onderhoud dienen te gaan plegen.
• testen
  Testen kosten vaak 10 tot 20 procent van de in te zetten middelen bij het doorvoeren van een verandering. Hier vinden we de afspraken die gemaakt worden rond het vaststellen van de kwaliteit van producten. Producten in deze context zijn vaak (mede) samengesteld uit software en hardware.
• kwaliteit
  Kwaliteit is een zeer breed fenomeen. In deze categorie vinden we de afspraken die gemaakt zijn rond het bepalen van de kwaliteit van processen en (kwaliteits)systemen. We zien ook hoe we een total-quality-situatie willen bereiken en behouden. De basis zijn vaak standaarden als ISO-9000 en methoden als Spider en CMM.
• invoering
  Het invoeren van nieuwe onderdelen van de informatie-infrastructuur is meestal geen sinecure. Hier vinden we de afspraken die rond dat gebeuren gemaakt zijn. Het gaat bijvoorbeeld over wie betrokken dient te worden, welke rol betrokkenen hebben, wat gedaan moet worden bij bijvoorbeeld een parallelle of een seriële invoering enzovoort.
• conversie
  Conversie kan een enorme hoeveelheid werk met zich meebrengen die vaak vooral problemen in de organisatie veroorzaakt. In deze categorie wordt op een rij gezet welke afspraken gemaakt zijn rond het omzetten van gegevens en applicaties van een oude naar een nieuwe situatie van de informatie-infrastructuur.
• beveiliging
  In een wereld waar systemen open en steeds groter zijn, is beveiliging een steeds belangrijker wordend onderwerp. In deze categorie worden een functionele definitie en beschrijving gegeven van de manier waarop de informatie-infrastructuur beveiligd is dan wel dient te zijn of worden.
• voorlichting
  De informatievoorziening van een organisatie komen we overal in die organisatie tegen. De manier waarop mensen bekend gemaakt worden met die informatievoorziening is van groot belang in verband met de acceptatie ervan door gebruikers en anderen. In deze categorie vinden we de afspraken die daarover gemaakt zijn terug.
• opleiding
  Het werken met (delen van) een informatievoorziening vereist vaak bepaalde kennis en vaardigheden, net als het aanpassen ervan. Opleiding is een zeer grote kostenpost. Hier vinden we de afspraken die gemaakt zijn rond het opleiden van mensen die te maken hebben met de informatievoorziening (informatie-architecten, IT'ers, gebruikers en anderen).
  De hoofdlijnen, de modellen en de algemene afspraken vormen samen de kern van de informatie-architectuur.
  Infrastructuur
  In deze groep vinden we de afspraken die met de UoD worden gemaakt rond de mogelijkheden om ICT in te zetten. Het gaat om:
• IT-visie
  Informatietechnologie ontwikkelt zich met een verbijsterende snelheid. En die snelheid lijkt steeds hoger te worden. Wat vandaag nieuw is, is morgen oud of 'conventioneel'. Doordat we een uitgewerkte informatievisie hebben, weten we wat de UoD wil. Door de steeds groter wordende mogelijkheden van IT kan zij steeds vaker ingezet worden om deze wensen te realiseren. Hier vinden we de visie op IT en de inzet daarvan die nodig is om de uitgewerkte informatievisie te realiseren.
• toekomstige architectuur
  Hier wordt de informatie-infrastructuur van de toekomst in beeld gebracht. Het behoeft geen betoog dat deze toekomstige architectuur het best vergelijkbaar opgezet kan worden met de architectuur van de huidige informatie-infrastructuur, zoals die eerder in dit artikel beschreven is.
• in te zetten faciliteiten en IT-standaarden
  Deze afspraak bevat een uitgewerkte lijst van in te zetten componenten, aangevuld met standaarden en normen ten aanzien van de inzet van IT.
• prestatie-eisen
  Dit is een lijst met eisen, zoals beschikbaarheid 24 uur per dag, zeven dagen per week, de maximumresponstijden enzovoort.
  Samen zijn dit alle zaken die vaststellen wat de inrichting van de informatie-infrastructuur van de toekomst zal moeten zijn.
  Veranderingen
  Dit is de laatste groep binnen het blok informatie-architectuur in figuur 1. Deze groep omvat vooral de nodige en gevraagde wijzigingen van de informatie-infrastructuur. In figuur 2 worden deze wijzigingen in de tijd geplaatst. Links staat de huidige situatie, rechts de toekomst. We zien een verandering van zowel de bedrijfsprocessen als van de informatie-infrastructuur. De in het kader van de informatievoorziening relevante wijzigingen dienen doorgevoerd te worden in de informatie-infrastructuur. Met de afspraken in de informatie-architectuur als basis kunnen deze wijzigingen gepland worden in wat wel het informatieplan wordt genoemd.
  Het is van belang dat elke verandering voorbereid wordt met het uitwerken van een wijzigingsverzoek. In zo'n verzoek kunnen bijvoorbeeld beschrijvingen van de gewenste verandering gegeven worden, kunnen consequenties aangegeven worden en kan de voortgang van het doorvoeren van de verandering vastgelegd worden. Na afronding ontstaat zo een archiveerbaar overzicht van wat de doorvoering van de beschreven verandering heeft betekend.

Ontwikkelen

Figuur 2: Van vandaag naar morgen

Gebaseerd op het informatieplan en in lijn met de inhoud van de informatie-architectuur kunnen de veranderingen in de informatie-infrastructuur gerealiseerd worden. In figuur 1 wordt dit proces weergegeven door de pijl met de naam 'ontwikkelen'. Dit is het proces van 'weten wat we willen veranderen' tot het doorvoeren van die verandering. Tijdens dit proces worden de eerder beschreven stappen 'toepasbaarheidanalyse of specificatie', 'ontwerp en realisatie' en 'invoering' uitgevoerd.
Het proces van ontwikkelen is in feite het eerste moment dat IT werkelijk een rol kan gaan spelen. Een ontwikkeling kan uitgevoerd worden door de organisatie zelf of door externe krachten. Aannemers als software- of systeemhuizen kunnen direct gevraagd worden, of kunnen bijvoorbeeld via een Europese aanbesteding uitgekozen worden. Indien een aanbesteding gebaseerd is op een goed uitgewerkte informatie-architectuur, blijken ideeën als fixed-price, fixed-time en fixed-quality bespreekbaar te zijn. In de praktijk zal de informatie-architect, degene die onder meer de inhoud van de informatie-architectuur beheert, de organisatie helpen de juiste aanbieding te krijgen om de gewenste verandering operationeel te krijgen in de juiste prijs/prestatie-verhouding.

De stelling
Tot slot kom ik terug op de stelling die tevens de titel van deze bijdrage is: 'een informatie-architectuur is geen IT-architectuur'. Dit artikel is geschreven om duidelijk te maken dat een informatie-architectuur en een IT-architectuur, een onderdeel van de architectuur van de informatie-infrastructuur, niet gelijk aan elkaar zijn, en dat een informatie-architectuur geen onderdeel is van een IT-architectuur.
Organisaties kunnen al erg lang bestaan. Zij weten dat zij niet kunnen werken of zelfs maar kunnen bestaan zonder informatie. Banken bestaan bijvoorbeeld al duizenden jaren. In die tijd hebben we leren kennen en begrijpen wat 'een bank' is en kan; we weten welke informatie daarvoor nodig is. Met moderne informatietechnologie kan die informatie sneller en beter verwerkt en beschikbaar gesteld worden. Maar daarom kan het bankieren nog niet vervangen worden door IT: informatietechnologie ondersteunt.
IT kan wel dingen mogelijk maken die voorheen niet mogelijk waren. Het was eenvoudigweg niet mogelijk om 24 uur per dag, 7 dagen per week opties of aandelen bij een bank te kopen en die transacties dan ook nog goedgekeurd te krijgen - en dat allemaal binnen enkele minuten.

IT verpakt als e-commerce lijkt dit mogelijk te maken, maar niet zomaar even uit de losse pols. Zaken als straight-through-processing van financiële transacties vereisen meer dan met IT op te lossen is.

In dit artikel is een sterke scheiding gemaakt tussen informatie en de manier waarop oplossingen ingepast kunnen worden. De reden hiervoor is dat de behoefte aan informatie al zeker zo oud is als organisaties zijn. IT is een manier om de informatievoorziening, de informatie-infrastructuur, te verbeteren. Dat staat los van wat informatie is. En dat is waar het bij een informatie-architectuur om gaat.

--------------------------------------------------------------------------------
Noten

1. Veel van de termen in dit artikel worden gedefinieerd in de nieuwe ISO/IEC-standaard FCD 14481 ten aanzien van Conceptual Schema Modeling Facilities (CSMF). Zie ook www.aim.nl/iso14481/.
2. Er zijn argumenten om deze beelden 'modellen' in plaats van architecturen te noemen. Dan zouden we dus bijvoorbeeld over een applicatiemodel spreken in plaats van over een applicatiearchitectuur. Omdat er toch meer is dan in een model te vangen is, wordt hier de term architectuur gebruikt. Overigens, de meest consequente term is 'architectuur van de applicatie-infrastructuur', en die wordt hier dan ook gebruikt.
3. Dit zijn zeer mechanisch opgezette beelden. Er zijn vele andere methoden om de effectiviteit van de informatie-infrastructuur te meten. Deze worden in de context van dit artikel niet behandeld.
4. Er kan natuurlijk altijd een mindere mate van detail afgesproken worden.
5. In feite spreken we hier onder meer over een vervolg op de Create/Use-matrices van IBM en James Martin en over een wat algemener versie van de CRUD-matrices van Oracle Corporation.
6. Er dient opgemerkt te worden dat veel van de functionaliteit al vastgesteld is door de relatie tussen de entity-types van het CIM te relateren aan de bedrijfsprocessen.