11 december 2003: Over ICT-Architect is meer te zeggen

Verschenen in Automatisering Gids nr. 50, 2003

Er is meer te zeggen over de functie van ICT-architect, schrijft Steven van ‘t Veld, naar aanleiding van de uiteenzetting van Roel Wieringa in de vorige Automatisering Gids.

Met veel interesse heb ik het artikel in Automatisering Gids van 5 december gelezen. Ik heb een paar aanvullingen. Als eerste wat over de ‘breedte’ van het werk van de architect in de informatievoorziening. In de dagen van OSI is de denk- en werkwijze rond hardware, netwerk en systeemsoftware als het ware gekanteld. Van naast elkaar staande oplossingen is men gaan denken in een geïntegreerd netwerk van componenten die samen de IT-infrastructuur vormen zoals we die tegenwoordig vaak zien en kennen. Open, gedistribueerd, beveiligd enzovoort.

Vervolgens is men gaan nadenken over het kantelen van applicaties en de opslag van gegevens. We moeten de ‘stove-pipes’ immers kwijt. Wat we dan in feite doen en willen, is een IT-infrastructuur (binnen een informatie-infrastructuur) creëren die als IT-landschap goed aansluit bij de behoeften die de organisatie heeft.

Als je de ICT-architect (SCIA noemt dit de IT-Business Architect) met een requirement engineer vergelijkt, loop je in de voorgaande notie echter klem. Een requirement engineer, ik zou hem ook business-analist of functioneel ontwerper kunnen noemen, is iemand die een probleem voorgeschoteld krijgt en dan op zoek gaat naar wat de organisatie echt bedoelt. Het is de bedoeling dat hij de requirements zodanig opzet dat IT-oplossingen bedacht kunnen worden die passen bij de organisatie.

De beperking van denken en werken van de requirement engineer ligt in de afbakening van het aangereikte probleem. Juist als deze engineer de breedte van het IT-landschap kan zien zou hij een ICT-architect/IT-Business Architect genoemd kunnen worden. Maar dan is er dus wel een essentieel verschil in de manier van kijken van de requirement engineer en die van de ICT-architect, namelijk probleemgericht versus organisatiebreed. Dan is de aansluiting/alignment tussen organisatie/business en IT voor de ICT-architect inderdaad de basis. Daar zit immers de totale effectiviteit van een geboden IT-landschap.

Een tweede aanvulling ligt op een ander systeemniveau dan waar de ICT-Architect en/of IT-Business Architect werkt. Zeg maar dat we nog een derde niveau hebben waarop het werk gekanteld kan/moet worden. Hier spreken we over informatie als productiefactor, het conceptuele niveau van denken en werken.

Laat me dit uitleggen aan de hand van een voorbeeld. Een beetje bank heeft een paar honderd bedrijfsprocessen waarin samen aan het bereiken van allerlei (sub)doelen gewerkt wordt: hypotheekverkoop, marketing, research, transactieverwerking en ga maar door. Diezelfde bank wordt ondersteund door een IT-landschap met vaak vijfduizend of meer applicaties. Er worden jaarlijks honderden miljoenen besteed om dat alles in de lucht te houden en te verbeteren. Als je nu naar de informatie kijkt die van belang is, dan zijn er in feite maar drie dingen: mensen en organisaties die bijvoorbeeld klant zijn, bankproducten en -diensten en de overeenkomsten die deze klanten afsluiten om die producten of diensten geleverd te krijgen.

En dan de fascinerende vraag: hoe kan het nu zijn dat er duizenden applicaties bestaan die in principe maar drie soorten (primaire) informatie voor ons vasthouden? Het antwoord is even simpel als verbijsterend. Als wij van tevoren in de gaten gehouden hadden dat we steeds met dezelfde of vergelijkbare informatie bezig waren, hadden we met veel minder applicaties toe gekund. Sterker nog, als je wist wat je wel of niet met de gegevens die informatie voor je organisatie zijn wilde, had je vooraf al geweten wat je requirements waren.

Met deze redenering kantel je het werk van de informatie-analist van probleemgericht naar organisatiebreed. De vraag wordt dan of je dan nog wel een requirement engineer nodig hebt. Het beheer van deze informatie-architectuur neemt de rol van wat functioneel beheer genoemd wordt over en als die basis goed bijgehouden wordt, hebben we weinig meer te doen in het voortraject van onze projecten. Hier zien we het beroep van informatie-architect ontstaan.

Je zou, als derde, ook nog rond het samenwerken in een organisatie over een architect kunnen spreken, een bedrijfsprocesarchitect misschien. Het werk van deze mensen is voor informatiekundigen en IT’ers erg belangrijk en we hebben er veel mee te maken, maar het is ons vakgebied niet. Dat blijkt steeds weer in de praktijk. Organisaties communiceren nu eenmaal niet in modellen, en directies en gebruikers UML leren lezen kunnen we echt vergeten!