Oktober 2000: Architect en Organisatie

Het Genootschap voor Informatie Architecten (GIA) is samen met de overheid bezig vast te stellen wie de 'stakeholders' zijn rond het beroep van informatiearchitect. Om die reden wordt contact gezocht met groepen organisaties zoals gemeenten, banken, verzekeringsmaatschappijen, ziekenhuizen, transportbedrijven, productiebedrijven enzovoort. In gesprekken met deze organisaties komt steeds eenzelfde opvatting naar voren. Deze opvatting heeft de volgende stelling opgeleverd:

---

De informatiearchitect is er voor de organisatie die behoefte aan informatie heeft en niet in eerste instantie voor de inzet van ICT

---

Deze stelling is juist, en dat heeft grote consequenties. Omdat deze consequenties nauwelijks door lijken te dringen, wordt er in deze discussie aandacht aan geschonken.

Een informatiearchitect is iemand die zich bezighoudt met de informatie in een bepaalde omgeving. Zo'n omgeving is vaak een combinatie van één of meer organisaties. Het is erg belangrijk dat het om een vastgestelde omgeving gaat, omdat informatie een relatief begrip is. Informatie zijn namelijk die gegevens die betekenis hebben in die omgeving. Als we weten wat informatie is, kunnen we er ook allerlei uitspraken over doen in de vorm van eisen, wensen, uitgangspunten en randvoorwaarden. Het beeld dat zo van de informatie ontstaat, inclusief alles wat daarover gezegd en gedacht wordt of moet worden, heet de informatiearchitectuur. De informatiearchitect zorgt ervoor dat deze er komt en wordt beheerd.

Wat betekent het voor een omgeving als een informatiearchitect in de arm wordt genomen? Nou, de informatiearchitect stelt zoals gezegd vast wat informatie is en wat een omgeving daarmee wil. Vaak heeft een organisatie al van alles en nog wat uitgewerkt. Een initiële scan dient dan ook om de architect inzicht te geven in wat een omgeving al heeft. Je zou het kunnen vergelijken met wat bijvoorbeeld CMM doet: hoe ver is men, waar zitten de gaten, wat is er goed uitgewerkt en wat niet, en ga zo maar door. En met dat beeld, de informatiearchitectuur, kan de architect de omgeving beargumenteerd adviseren waaraan eerst gewerkt moet worden, en wat nog kan wachten.

De consequenties

Deze manier van werken heeft belangrijke consequenties. Zo is het van groot belang dat een informatiearchitect goed contact heeft met de mensen die verantwoordelijk zijn voor de informatie. Immers, alleen met hen kan de architect vaststellen welke gegevens informatie zijn. Omdat organisaties altijd meer dan één verantwoordelijke hebben, is onderlinge afstemming van het grootste belang. Dit wordt meestal een soort 'spel van kampioenen'. Met als doel eenduidigheid te brengen in een totaalbeeld, dat anno 2000 vrijwel altijd zeer diffuus is. De basis voor de informatiearchitectuur, dus.

Zodra er in enige mate een invulling van een informatiearchitectuur bestaat, kan een organisatie er iets mee doen. Immers, als je weet wat je informatie is en daaraan toevoegt hoe effectief (zie de discussie rond alignment in stelling 10) die informatie ter beschikking is, kun je gaan sturen. Zo kan een onderbouwde visie op informatie worden ontwikkeld, met een strategie, een beleid en een plan voor het doorvoeren van de nodige veranderingen. De informatiearchitect kan daarbij aangeven wat de consequenties van die veranderingen zijn. Dus zowel bij het invoeren van een documentmanagementsysteem als van kantoorautomatisering of van ERP-software. En wat te denken van de overgang van een productgerichte insteek naar een klantgerichte? Of van de introductie van e-commerce?

Een organisatie kan met een goede informatiearchitectuur de verantwoording gaan dragen voor haar informatie. In goede samenspraak met de eigenaren van die informatie zou dat de taak van een Chief Information Officer (CIO) zijn. Inhoudelijk ondersteund door zijn informatiearchitect kan hij de productiefactor informatie gaan managen. En dat zie je ook al mondjesmaat in organisaties gebeuren. In informatie-intensieve organisaties krijgt de CIO af en toe zelfs al een plaats in de directie.

Merk op dat er nog steeds met geen woord over welke technologie dan ook is gesproken. Het belang van de inzet van IT en andere technologieën wordt met de inzet van een informatiearchitect ook duidelijk teruggedrongen naar het gemiddeld redelijke belang dat het feitelijk heeft. In feite houden we rond de inzet van technologie maar twee hoofdtaken over:

• het realiseren van oplossingen
• het (technisch) beheren van bestaande oplossingen.

Reden hiervoor is dat we met de informatie-architectuur weten wat de organisatie wil. Lange trajecten om oplossingen te specificeren zullen dan ook steeds minder nodig zijn. Het 'voortraject' wordt daarmee uiteindelijk teruggebracht tot een soort onderzoek naar de toepasbaarheid van wat we al weten en willen. Met het resultaat dienen de juiste objecten en applicaties ontwikkeld of gekocht te worden. Ongeacht of het inbesteed of uitbesteed wordt of outsourced is.

Het bedoelde beheer kan beperkt blijven tot het beheer van de informatie-infrastructuur; van de bestaande oplossingen, dus. Wat we tot nu functioneel beheer genoemd hebben is immers wat de informatiearchitect en de CIO doen. De informatiearchitect brengt het belang van de inzet van IT terug in proportie

De mening dat technologie bepalend zal zijn voor de manier waarop een organisatie in de toekomst ingericht wordt, is slechts beperkt waar. Natuurlijk zullen de mogelijkheden van de technologie omarmd worden door organisaties. Maar dan wel ingestuurd vanuit de organisatie zelf. De organisatie zal immers zelf willen blijven bepalen welke activiteiten ze ontplooit. De rol van de informatiearchitect is van groot belang omdat hij immers weet wat de organisatie wil en kan zien of een nieuwe technologie daaraan iets toevoegt. Zijn adviezen kunnen door de CIO gebalanceerd ingebracht worden, zodat niet de hele organisatie belast wordt met technische vraagstukken die ze vaak toch nauwelijks begrijpt, laat staan op kan lossen.

Een informatiearchitect staat, net als een bouwarchitect, de organisatie terzijde. Hij zal, net als in de bouwwereld, de onderhandelingen voeren met aannemers: softwarehuizen, leveranciers enzovoort. En net als in de bouwwereld werken architecten niet voor aannemers. Zij moeten immers de handen vrij hebben om het beste voor een organisatie te kunnen realiseren.