5 januari 2006: Wat ICT-architecten moeten weten

Door: Prof. Roel Wieringa, verschenen in AutomatiseringGids nr. 1

Over de competenties van ICT-architecten wordt veel gesproken, maar vooral in vage termen. De definities zijn vaak ‘impressionistisch’ en ‘onvolledig’, concludeert Roel Wieringa. Volgens hem is deze vaagheid helemaal niet nodig. Het is vrij eenvoudig een aantal competentielagen te onderscheiden.

Digitale architecturen staan binnen en buiten Nederland volop in de aandacht. In Nederland proberen organisaties zoals het Scia en Eria digitale architecten (onder verschillende namen) te certificeren, en internationaal heeft het Togaf afgelopen zomer een certificatie-initiatief gelanceerd. Recentelijk is in Automatisering Gids nog een aantal artikelen gewijd aan de competenties van enterprise-architecten. Al deze initiatieven lijden aan, zacht gezegd, een zekere mate van vaagheid. Tot zover zijn de gepubliceerde competentiedefinities impressionistisch en onvolledig, en bij sommige certificeringsinstellingen zijn ze geheel afwezig. Bovendien is de terminologie niet gestandaardiseerd, zodat gebruikersbedrijven niet weten wat ze krijgen als een consultancybedrijf ze een enterprise-architect of informatie-architect aanbiedt. Discussies over voor buitenstaanders onbegrijpelijke verschillen lopen hoog op. Is een businessarchitect nu een enterprise-architect of niet? Voor buitenstaanders komt dit over als de vraag of een fiets nu een rijwiel is of niet.

Competentie-ijsberg
Laten we eerst eens naar het competentiebegrip kijken. Onderzoek in de leerpsychologie heeft aangetoond dat competenties een ijsberg vormen (Bergenhenegouwen et al., ‘Strategisch opleiden en leren in organisaties’, 1999). Boven water is een kleine top zichtbaar, die bestaat uit ‘vakkennis en -vaardigheden’ (1). Dat zijn zaken die je in een opleiding leert, en die in een interview of test te toetsen zijn. Onder water zitten ‘intermediaire vaardigheden’ (2), zoals bijvoorbeeld projectmanagement, die bij meerdere beroepen in te zetten zijn. Deze vaardigheden kunnen niet zomaar in een examen getoetst worden. Ze worden pas over een langere periode zichtbaar en ze worden ook pas na een langere periode van ervaring geleerd. Nog verder onder water liggen normen en waarden die bepalend zijn voor de ‘cultuur’ (3) van een beroepsgroep. Die leer je pas na een lange periode van socialisatie in een groep, en ze zijn ook heel moeilijk af te leren, als dat ooit nodig mocht zijn. Het diepst onder water verborgen liggen de ‘persoonlijkheidskenmerken’ (4) die voor de uitoefening van een beroep gewenst zijn, zoals bijvoorbeeld emotionele stabiliteit of abstractievermogen. Persoonlijkheidskenmerken kunnen wijzigen, maar dat gebeurt langzaam, en het gebeurt zeker niet in een cursus. Cursussen op dit gebied hebben als doel de cursisten met hun eigen kenmerken te confronteren, niet om ze een bepaald kenmerk aan of af te leren.

Vakkennis en -vaardigheden
Wat moet een architect nu eigenlijk weten? Dat hangt af van de rol die de architect moet spelen. Infrastructuurarchitecten die op operationeel niveau werken moeten kennis hebben van besturingssystemen, netwerksoftware, middleware, opslagtechnologie, fileservers, webservers, databasemanagementsystemen, workflowmanagementsystemen, officesoftware, user-interfacetechnologie en eventueel andere infrastructuurdomeinen die relevant zijn voor een onderneming. Infrastructuurarchitecten specialiseren zich meestal op één van deze domeinen. Bovendien moet een infrastructuurarchitect de ontwerpkennis en -vaardigheden hebben om infrastructuurproducten zo samen te stellen dat aan de ondernemingsdoelen wordt voldaan.
Architecten van enterprisesoftware - applicaties en informatiesystemen - moeten kennis hebben van de markt van applicatiecomponenten, en tevens relevante ontwerpkennis en -vaardigheden bezitten. Afhankelijk van de taken van de architect varieert dat van software-ontwerpmethoden, -technieken en -gereedschappen, tot relevante talen en informatiemodelleringstechnieken. Bovendien moet een enterprisesoftware-architect kennis hebben van het bedrijfsdomein waarvoor hij applicatie- en informatiesysteemarchitecturen ontwerpt.
Voor organisatie-architecten (business architects) geldt het omgekeerde. Zij moeten in de eerste plaats thuis zijn in het bedrijfsdomein zelf, en ontwerpmethoden en -technieken zoals procesmodellering, processimulatie en administratieve organisatie beheersen. Op de tweede plaats moeten ze dan op de hoogte zijn van de onderliggende ICT met behulp waarvan dit geïmplementeerd moet worden.
Voor alle architecten geldt dat hoe strategischer hun taak is, hoe globaler de kennis van deze domeinen. Een architect die bijvoorbeeld de strategische afstemming tussen enterprisesoftware en de organisatie ontwerpt moet de landschapskaart van enterprisesoftware kennen, maar hij hoeft de details van de applicatie-architecturen niet te kennen.

Intermediaire vaardigheden
Intermediaire vaardigheden zijn breed inzetbare beroepscompetenties. Een rondgang langs ICT-architecten in het veld laat zien dat er veel verschil van mening bestaat over de vraag of een architect nu wel of niet managementvaardigheden moet bezitten (projectmanagement, veranderingsmanagement et cetera). Ook dit hangt weer af van de rol die een architect moet spelen. Een architect die een veranderingsproject moet leiden, moet daar managementvaardigheden voor hebben. Een architect die een project moet leiden, moet projectmanagementvaardigheden hebben. Maar niet alle architecten hoeven (veranderings)projecten te leiden. Ik kan mij een uitstekende architect voorstellen die dergelijke projecten niet kan managen, maar dat ook niet hoeft te doen.
Kijken we naar de kern van de architectenprofessie, wat alle architecten moeten doen, dan is dat het vertalen van organisatiedoelen, -wensen en -strategieën naar IT-oplossingen. Een enterprise-architect bijvoorbeeld moet een strategische afstemming realiseren tussen het bedrijf en enterprisesoftware, een applicatie-architect moet op operationeel niveau een applicatie afstemmen op concrete bedrijfswensen, en infrastructuurarchitecten moeten het technische infrastructuurplatform verschaffen waarop bedrijfsdoelen gerealiseerd kunnen worden.
Voor alle architecten zijn dus ontwerpcompetenties de cruciale intermediaire vaardigheden. Hiermee bedoel ik competenties zoals:

• het kunnen identificeren, definiëren en structureren van bedrijfsproblemen;
• het kunnen afwegen van ontwerpalternatieven;
• het kunnen herkennen en toepassen van algemene architectuurprincipes, zodanig dat die tot de gewenste kwaliteit van oplossingen leiden.

Het is niet moeilijk deze lijst uit te breiden met andere, generieke architectencompetenties. Deze competenties zijn nog onvoldoende in kaart gebracht. Hier moet in der nabije toekomst meer aandacht aan gegeven worden.

Cultuur
Nog dieper dan de intermediaire competenties liggen de culturele normen en waarden. Net zoals alle beroepsgroepen hebben architecten hun eigen normen en waarden. Het leren hiervan vindt plaats door enculturatie, dat wil zeggen door in de groep mee te doen en al doende deze normen en waarden te internaliseren totdat ze als de eigen normen en waarden ervaren worden.
De kernwaarde voor ICT-architecten is dat ze niet als techneuten opereren maar zich richten op de organisatie waarvoor zij werken, en op de klant van die organisatie. Hiermee doel ik niet alleen op de ‘kennis’ van de organisatie of de klant, hoewel die natuurlijk ook aanwezig moet zijn, maar ook op de ‘bereidheid’ de waarden van de organisatie en van de klant mee te nemen in adviezen over architectuur. De preferenties van de organisatie en haar klanten stijgen uit boven de waarden van harde techneuten, die het liefst het technische neusje van de zalm in huis zouden willen hebben.

Persoonlijkheidskenmerken
De meeste architecten die men naar gewenste competenties van architecten vraagt zullen persoonlijkheidskenmerken noemen. Misschien zegt de imposante lijst van eigenschappen die architecten volgens zichzelf moeten hebben (zie kader) iets over hun zelfbeeld.
Maar als ik nu slechts één eigenschap mag noemen die een architect absoluut moet hebben, welke is dat dan? Mijn keuze valt dan op communicativiteit. Architecten moeten de kloof tussen de organisatie en ICT weten te overbruggen, en een kerncompetentie hiervoor is communiceren, over de architectuur en haar implicaties, met de verschillende partijen in de business en de ICT.
En als ik er twee mag noemen? De tweede relevante eigenschap is abstractie: het vermogen om in een kluwen van organisatiedoelen en -problemen, processen en belangen de onderliggende structuren te vinden, en om die te relateren aan enkele hoofdlijnen in een complexe overdaad aan informatietechnologie. Architecten moeten niet alleen hoofdlijnen kunnen zien, ze moeten die hoofdlijnen ook zien in een complexe hoeveelheid concrete feiten.
Beide eigenschappen volgen uit de kerntaak van elke architect: het vertalen van organisatiedoelen, wensen en strategieën naar IT-oplossingen. Uit deze kerntaak volgen nog een enkele gewenste competenties, namelijk: analytisch vermogen en reflectie. Een architect moet structuren analyseren om tot oplossingen te komen, en hij moet die oplossingen dan weer kunnen analyseren op interne en externe consistentie.
Ten slotte, een goed architect blijft leren van de dingen die hij doet. Hij is nieuwsgierig en heeft nooit het laatste antwoord, hij blijft luisteren naar wat anderen proberen te zeggen en leert daarvan.

Rollen
Tot zover heb ik over architecten in het algemeen gesproken. Bedrijven gebruiken echter allerlei verschillende benamingen voor architecten, die in verschillende domeinen werken, verschillende specialisaties hebben, en op verschillende strategische niveaus werken. In het bedrijfsdomein komen we businessarchitecten (ook domeinarchitecten), procesarchitecten en informatiearchitecten tegen. In het enterprisesoftwaredomein komen we applicatie- en integratie-architecten tegen. En op infrastructuurniveau komen we de infrastructuurarchitect tegen (ook technisch architect), die zich in een of ander infrastructuurdomein kan specialiseren. En boven al deze architectuurdisciplines, op strategisch niveau, staat de enterprise-architect, die voor afstemming zorgt tussen het bedrijf en de ICT. Voor de helderheid van communicatie in de markt is het wenselijk dat we op dit gebied in de toekomst, in elk geval in Nederland, tot een uniforme terminologie komen.
Lastiger is het om de positie van de architect in een organisatie te bepalen. Wat is de relatie tussen een X-architect (vul voor X één van bovenstaande disciplines in) en een projectmanager? Of een programmamanager? Of een businessunitmanager? Of tussen de architecten onderling? Verschillende bedrijven hanteren verschillende structuren. Het Nederlands architectuurforum moet hier mijns inziens in de eerste plaats inventariserend optreden, zodat elk individueel bedrijf zijn eigen structuur kan plaatsen ten opzichte van die van andere. Mijn indruk is dat er geen unieke ‘juiste’ inbedding van een architect in een organisatie is, maar dat die inbedding afhangt van bijvoorbeeld het volwassenheidsniveau van de ICT-organisatie en van de bedrijfscultuur. Een sterk gepolitiseerde organisatie zal een andere inbedding kiezen dan een strak georganiseerde bureaucratische organisatie. Toekomstig onderzoek moet uitwijzen op welke manier architecten in organisaties ingebed kunnen worden.

Mist
Met deze analyse is de mist in architectenland hopelijk voldoende opgetrokken. Veel van die mist hangt rond de persoonlijkheidskenmerken van de architect, en ik denk dat we hier een te hooggespannen beeld hebben van de eigenschappen die een architect allemaal moet hebben. Enkele van die eigenschappen zijn cruciaal, andere zijn nice-to-have maar niet essentieel.
De mist blijft echter nog hangen rond de rollen die architecten in een organisatie kunnen spelen. Het hangt van deze rollen af wat een architect nog meer in huis moet hebben dan de minimale verzameling competenties.

Roel Wieringa is hoogleraar Informatiesystemen aan de Afdeling Informatica van de Universiteit Twente. Hij is lid van het bestuur van het Nederlands architectuurforum voor de digitale wereld (www.naf.nl) en voorzitter van de NAF-werkgroep Professionalisering van de Digitale Architect. Dit artikel is gebaseerd op een onderzoek dat in opdracht van het NAF is uitgevoerd door Erik Proper (Radboud Universiteit Nijmegen) en Pascal van Eck, Claudia Steghuis en Koen Voermans (Universiteit Twente).

Persoonlijkheidskenmerken van de architect
Wanneer men architecten in de praktijk vraagt naar de gewenste competenties, dan noemt hij meestal persoonskenmerken. In de psychologie worden persoonlijkheidskenmerken in vijf groepen verdeeld, die bekend staan als de ‘Big Five-factorstructuur’ (Goldberg, "An Alternative ‘Description of Personality’: The Big-Five Factor Structure", Journal of Personality and Social Psychology, 1990). Classificeren we de meest genoemde persoonlijkheidskenmerken in deze big five, dan ontstaat het volgende beeld.

1. Extravertie communicatief;

initiatiefrijk

2. Aangenaamheid teamplayer;

empathisch (andermans standpunt kunnen invoelen); luistervaardig

3. Betrouwbaarheid analytisch;

georganiseerd, systematisch en ordelijk; besluitvaardig; resultaatgericht

4. Emotionele stabiliteit

zelfstandig

5. Intellect (reflectie)

   creatief /innovatief; abstractievermogen; zichzelf blijven ontwikkelen
   De volledige lijst is veel langer. Maar deze is al lang genoeg om ons af te vragen welke architect dat toch is die al deze eigenschappen heeft. Ik ken in elk geval niemand die ze allemaal heeft. Wel kan ik enkele herkenbare types uit deze lijst afleiden. Twee contrasterende architecten die sommige (niet alle) van deze persoonskenmerken hebben, zijn:

   • de masculiene architect: resultaatgericht, besluitvaardig, met overtuigingskracht;
   • de feminiene architect: een sensitieve teamplayer die goed luistert.

Twee andere types zijn de artiest en de boekhouder:

• de artiest is iemand die op hoog abstractieniveau creatieve oplossingen voorstelt.
• de analyticus is iemand die nauwgezet en systematisch problemen analyseert en oplossingen uitwerkt.