Vorige week viel de nieuwe editie van het Od op de deurmat. Enige weken eerder had Eric Kokke, redactielid, een oproep over architectuur op LinkedIn geplaatst, waar ik op gereageerd heb. Gretig trok ik dus het plastic van het tijdschrift en bladerde gelijk door naar het artikel "Informatiearchitectuur in de praktijk" om te kijken of ik geciteerd was. En jawel, mijn ego is weer eens gestreeld en wel in een artikel dat prettig leest en een mooie doorkijk geeft in hoe verschillende organisaties omgaan met het thema 'informatiearchitectuur'. Na het lezen van het artikel bleef echter nog een vraag aan mij knagen: hebben wij wel allemaal (ongeveer) hetzelfde beeld bij wat informatiearchitectuur is? Dit is hoe ik erover denk...

Wat is het niet?

Informatiearchitectuur is niet NORA. Of GEMMA. Net zo min is het zaakgericht werken hetzelfde als het RGBZ of is archiefbeheer hetzelfde als de NEN-ISO 15489. Informatiearchitectuur is wat je doet en NORA en GEMMA zijn daar nationale standaarden in. Er zijn echter ook andere relevante standaarden.

Informatiearchitectuur is weten wat je belangrijk vindt (architectuur principes), weten wat je hebt (architectuurplaten en meer) en analyseren wat er moet veranderen (project-architectuur). NORA en GEMMA zijn (verzamelingen aan) standaarden waar je architectuur wel, niet of deels aan voldoet. Je kunt het belangrijk vinden dat je systemen aan NORA en GEMMA voldoen en dit dan ook eisen aan je leveranciers, maar dan doe je nog niet aan architectuur.

Inzicht en overzicht

Wat is informatiearchitectuur dan wel? Laat ik het eerst in een context plaatsen. Als organisatie wil je iets bereiken. Dat kan variëren van simpelweg het hoofd boven water houden tot de hele wereld veroveren. Meestal zijn er wel een aantal doelen die men wil bereiken. Dat noemen we dan de bedrijfsdoelstellingen. Om die doelstellingen te bereiken moeten (top-)managers sturen. Zij doen dat op alle facetten van de bedrijfsvoering: personeel, financiën, huisvesting, ICT en alle andere COPAFIJTH-letters. Het is daarbij belangrijk om de samenhang tussen al deze facettten te bewaken. Architectuur helpt daarbij door bij te houden wat de organisatie nu heeft en hoe dat met elkaar samenhangt. Architectuur helpt om veranderingen door te voeren, omdat er snel inzichtelijk gemaakt kan worden welke andere facetten geraakt worden bij het wijzigen van één facet.

Eenvoudig gezegd, bij architectuur worden er lijstjes bijgehouden en worden er relaties tussen die lijstjes gelegd. Denk bijvoorbeeld aan lijstjes met afdelingen, processen en applicaties. Het helpt in de communicatie om daar dan ook mooie plaatjes bij te tekenen. Dit doe je door regels uit die lijstjes als blokjes te tekenen. De relaties tussen die lijstjes teken je als lijnen en pijlen tussen die blokjes. Een vrij uitvoerige standaard hiervoor is bijvoorbeeld Archimate, maar voor de beginner raad ik vooral dit boek aan.

Architectuur in delen

In de bovenstaande uitleg heb ik het eigenlijk over de bedrijfsarchitectuur, of om de Engelse termen erbij te halen: de 'enterprise architecture' of 'business architecture'. Informatiearchitectuur is een onderdeel van de  bedrijfsarchitectuur, maar er zijn ook andere deel-architecturen. Denk dan bijvoorbeeld aan een procesarchitectuur of een technische architectuur (hardware e.d.), maar ook aan:

• De organisatiestructuur (afdelingen, teams, functies, medewerkers)
• De structuur van de boekhouding (budgetten, budgethouders)
• Huisvesting (gebouwen, verdiepingen, kamers)
• Et cetera

Een volledig en tot in detail uitgewerkte bedrijfsarchitectuur is de natte droom van elke controlfreak, maar zelden haalbaar of de investering waard. Het hangt af van wat je wilt bereiken met architectuur, welke onderdelen je gaat uitwerken. Houd er ook rekening mee dat niet iedereen in je organisatie een voorstander zal zijn van deze analytische, mechanische benadering van bedrijfsvoering.

De informatiearchitectuur wordt soms weer verder opgedeeld in een applicatie-architectuur en een data-architectuur. Een applicatie architectuur richt zich op de software. Denk aan applicaties, modules, functionaliteiten, koppelvlakken, interfaces, et cetera. Een data architectuur richt zich op de gegevens en documenten.

Aan de slag

Maar hoe doe je dan aan architectuur? Er zijn standaarden c.q. best-practices die je moeten helpen om de architectuur-functie in de organisatie in te richten, zoals DYA en TOGAF. Volgens deze standaarden begin je met afspraken te maken over wat je wilt bereiken met architectuur, om vervolgens architecturen (IST en SOLL) op te stellen en de nodige wijzigingen door te voeren. In mijn ervaring leidt een dergelijke aanpak vaak tot de volgende stappen:

1. Een lange discussie over wat architectuur nou eigenlijk is,
2. Een lange discussie over welke prachtkansen er allemaal liggen en wat men allemaal zou kunnen doen,
3. De opmerking dat het allemaal wel praktisch moet blijven,
4. Het schrijven van een plan van aanpak, dat uitgaat van "klein beginnen en dan zien we wel weer verder."

Ondertussen zijn de nodige mensen alweer afgehaakt. Mijn advies luidt dan ook: begin gewoon ergens. Hopelijk heb je een beetje in de gaten wat er om je heen gebeurt en waar de kansen liggen. Maak bijvoorbeeld eens een lijstje applicaties en relateer deze met een lijstje aan afdelingen. Daar ben je waarschijnlijk wel een paar uur zoet mee. Je ziet welke afdelingen veel applicaties gebruiken en welke afdelingen maar een paar hebben. Je ziet welke applicaties door veel afdelingen gebruikt worden en welke door maar één. Maak er een mooi plaatje bij, bespreek dat eens met je collega's en je baas en zie wat er gebeurt. En nogmaals, voor de duidelijkheid, het hangt van de context (jouw organisatie) af met welke lijstjes je moet beginnen.

Ikzelf heb inmiddels al een aantal lijstjes en tekeningen opgesteld. Ik heb deze al besproken met collega's, managers en leveranciers. Vaak wordt er dan gevraagd of zij ook de tekeningen en lijsten mogen hebben en zo niet, dan komen ze er later voor terug. Ik heb namelijk inzichtelijk gemaakt dat onze huidige inrichting door de jaren heen behoorlijk complex is geworden, maar ook dat het eenvoudiger kan (met een goed verhaal erbij wat dat dan oplevert). Zo probeer ik bottom-up de boel in beweging te krijgen om ervoor te zorgen dat wij in 2015 niet alleen nog meer functionaliteiten en koppelingen bovenop het systeem gaan gooien, maar dat er ook aandacht en capaciteit is om het een en ander op te ruimen.

Architectuur-standaarden

En NORA en GEMMA dan? Ik heb in die paar maanden dat ik informatiearchitect ben er nog vrij weinig concreets mee gedaan. Ik ben eerst begonnen met in kaart te brengen van wat we hebben. Als we immers weten wat we hebben, dan kunnen we vervolgens ook kijken of het voldoet aan de standaarden. Maar dát - lieve kijkbuiskinderen - is een hele andere architectuurplaat...