Battle: Informatiearchitect vs. Informatiearchitect

In de 4 jaar dat ik als informatiearchitect werkzaam ben is gebleken dat deze functie, afhankelijk van de organisatie waarin je de functie vervult, een andere invulling heeft. Op zich is dit nog niet zo verwonderlijk, echter zou de samenwerking tussen een informatiearchitect van een leverancier en een informatiearchitect van een klant kunnen verbeteren wanneer zij beter van elkaar weten wat hun blikveld is.

Zelf ben ik werkzaam geweest als informatiearchitect voor één van de grootste software leveranciers voor de lokale overheid. Momenteel zit ik aan de andere kant van de tafel bij verschillende Nederlandse gemeenten. Dit levert erg interessante beelden op. De onderlinge strijd die toch altijd aanwezig is tussen een leverancier en zijn klant komt in de functie van informatiearchitect ook duidelijk tot uiting en leidt tot suboptimale oplossingen. Erg jammer! De informatiearchitecten kunnen juist een mooie rol spelen om de onderlinge verstandhouding tussen leverancier en klant te optimaliseren, zodat er voor de klant een optimale bedrijfsbrede informatiearchitectuur ontstaat.

Blikveld

De informatiearchitect bij de leverancier heeft een blikveld dat overeenkomt met de reikwijdte van de applicatie waarvoor de architect zijn functie vervuld, of hooguit een blikveld dat overeenkomt met de afbakening van de business unit waarin hij werkzaam is. Dit wil zeggen dat zeker niet het gehele applicatielandschap van zijn klant voor hem helder is.

Vaak kijkt een klant hier anders naar. De klant is in de veronderstelling dat een informatiearchitect van een leverancier in ieder geval het speelveld van alle applicaties van die leverancier kan overzien. Helaas is dit niet (of steeds minder) het geval. Binnen verschillende leveranciers zie je verkokering ontstaan, verschillende business units die acteren als eigen bedrijven. Dit leidt zelfs binnen een leverancier tot tegengestelde belangen tussen de business units. Deze ontwikkeling resulteert in het feit dat dat de units door een klant als zijnde afzonderlijke leveranciers benaderd moeten worden.

Een informatiearchitect bij een (kleine of middelgrote) gemeente behartigt de belangen van de gehele organisatie. Dit vereist van de informatiearchitect bij de gemeente dat hij/zij een brede kennis heeft die juist weer minder ver in detail gaat dan die van de informatiearchitect bij de leverancier. Op grote lijnen zou de informatiearchitect bij de gemeente daarom altijd een hoger woord mogen voeren dan de architect van de leverancier. Dit gebeurt echter nog zelden aangezien de architect van de leverancier zich vaak op basis van detailkennis kroont tot inhoudelijk de meest bekwame besluitvormer.

De grootste gemeenten van Nederland vormen hierin een uitzondering, aangezien de functie informatiearchitect bij hen meerdere malen voorkomt en vanuit verschillende business units wordt ingevuld. Zij beschikken dan over het algemeen wel weer over een Enterprise Architect die de samenhang voor de gehele organisatie bewaakt op alle aspecten van architectuur. Exact op dit punt ontbreekt er binnen (grote) leveranciers vaak een zeer essentiële functie.

Samenwerking

De verantwoordelijkheid om tot een optimale informatiearchitectuur bij de klant te komen ligt volledig in handen van de informatiearchitect bij de klant. Ik vind dat (met in achtneming van bovenstaande) de informatiearchitect van de klant ervoor moet zorgen dat er voldoende afstemming plaatsvindt met de informatiearchitecten van verschillende leveranciers/business units. Dit gebeurt nog veel te weinig, de klant denkt nog te vaak dat de leverancier hiervoor niet bereikbaar is. Door de dialoog juist te blijven opzoeken blijft de klant op de hoogte van wat er speelt en is daardoor in staat alle beelden samen te brengen, zodat de informatiearchitectuur optimaal ingericht kan worden.