Zo kom je tot een effectief architectuurteam

Verwachtingen die niet worden waargemaakt, gesteggel over verantwoordelijkheden, twijfelen aan elkaars capaciteiten, hiaten in de totaalarchitectuur: in veel grote organisaties loopt het werken onder architectuur nog altijd niet soepel. Dit probleem is al vanuit veel invalshoeken geadresseerd. Er zijn functieprofielen opgesteld, architectuurprocessen beschreven, trainingen gevolgd. Michal Kleinhans en Marlies van Steenbergen beschouwen dit vanuit kennisperspectief. 

In grote organisaties zien we vaak dat er hiaten in de architectuurfunctie zitten, verantwoordelijkheden niet helder zijn en dat op deelgebieden sterk onder architectuur wordt gewerkt, maar de aansluiting op het grotere ecosysteem ontbreekt. Dat maakt het moeilijk om de architectuurfunctie effectief in te vullen. Belangrijke taken worden niet opgepakt, op andere vlakken doen mensen juist dubbel werk.

Om te komen tot een evenwichtig architectenteam, worden functieprofielen opgesteld. Deze geven alleen vaak nog onvoldoende houvast. Ze beschrijven wel verantwoordelijkheden, taakgebieden, verwachte kennis en vaardigheden, maar dat gebeurt of te algemeen (goed communiceren) of te specifiek (businessmodellen maken) om echt te helpen bij het opbouwen van een evenwichtig team.

Vaak wordt het antwoord op ineffectieve samenwerking gezocht in het onderling verdelen van taken, organisatieonderdelen en op te leveren architectuurproducten. Dit levert lang niet altijd het gewenste resultaat. Omdat bijvoorbeeld gedoe ontstaat over kwaliteit, inpasbaarheid of tijdigheid. Met als ultieme uitkomst gemor over elkaars competenties en wantrouwen. Dit heeft niet alleen een negatief effect op de architecten, maar ook op de positie van architectuur in de organisatie.

Een benadering die we in de praktijk nog niet zijn tegengekomen en die we in dit artikel exploreren, is vanuit het perspectief van de kennisopbouw van een architectenteam. We combineren de kennistaxonomie van Bloom met het relatiemodel van Hiemstra tot een model van typen kennis die in een architectenteam benodigd zijn. Met behulp van dit model kunnen vervolgens architectenprofielen worden gevormd die samen het hele kennisspectrum afdekken. We geloven dat dit een belangrijk missend puzzelstukje kan zijn in de vorming van een effectief architectenteam.

Taxonomie van Bloom

De taxonomie van Bloom wordt veel gebruikt in het onderwijs om leerlingen op een gestructureerde wijze cognitieve competenties van toenemende complexiteit te leren[1]. Bloom onderscheidt zes lagen van complexiteit van cognitieve kennis (figuur 1).

Deze lagen kunnen zowel op inhoudelijke kennis als op procesmatige kennis worden toegepast. Belangrijk in de theorie van Bloom is dat leren zowel top-down als bottom-up kan, of eenvoudiger gezegd: men kan beginnen met onthouden van details en zo uitbouwen naar kennis of men kan het geheel aan kennis doorgronden en vervolgens de details tot zich nemen. Als we dit toepassen op een architectenteam, zien wij architecten die meer de rol hebben het grotere geheel te overzien en architecten die juist alle details van een onderwerp kennen.

De taxonomie vormt een consistent geheel van competenties die nodig zijn om het creëren mogelijk te maken. Het team kan geen competentie overslaan. De bovenste lagen bouwen voort op de onderste. Dit betekent niet dat elke architect op alle onderwerpen alle lagen moet beheersen. Het betekent wel dat de gehele architectuurfunctie, dus alle architecten samen, de competenties in de piramide moeten beheersen, met een goede onderlinge samenwerking en goed gefaciliteerd door de organisatie.

Kan deze taxonomie helpen om in kaart te brengen of alle benodigde kennis aanwezig is in het architectenteam als geheel? Om dit te beantwoorden hebben we een extra perspectief nodig: dat van de stakeholders waarvoor de architecten werken, of, meer specifiek, de typen relaties die de architectuurfunctie onderhoudt met zijn omgeving.

Verschillende relaties

Er is al veel geschreven over het feit dat architecten verschillende stakeholders hebben en dat hun werkwijze op die stakeholders afgestemd moet zijn. De relatie met een directielid is anders dan met een ontwerper. Architect en directie werken samen aan de strategie van de organisatie. De (lead)enterprise-architect vertaalt daarbij de strategie naar architectuuruitgangspunten (creëren). Bij de ontwerper geeft de solution-architect, op basis van deze architectuuruitgangspunten, kaders voor ontwerp (toepassen). Het is belangrijk te beseffen dat de gewenste beheersingslaag kan variëren per onderwerp. Waar een solution-architect minimaal op de toe te passen laag moet zitten met betrekking tot architectuuruitgangspunten, moet-ie op creëren zitten met betrekking tot solution-architecturen.

In “Presterende gemeenten” identificeert Hiemstra rollen die een inwoner of ondernemer in contact met de gemeente kan hebben[2]. Deze rollen lijken ook heel mooi op de architectuurfunctie toepasbaar. Eigenlijk logisch, omdat een gemeente zich ook bezighoudt met structuren, overzicht en richtlijnen. Komt een inwoner voor een nieuw paspoort? Dat is een ‘klant’. Een ondernemer die aanklopt om samen met de gemeente een initiatief uit te werken, doet dat vanuit een ‘partner’-rol. Moet de inwoner een parkeerboete betalen? Dan is de rol van ‘onderdaan’ van toepassing. En bij een picknick in het park is de inwoner een ‘gebruiker’. Als we deze rollen vertalen naar de architectuurfunctie, brengt dat ons op de volgende relaties, die viewpoints vertegenwoordigen van waaruit de architect haar werk doet:

• een klant is iemand die een bestaande dienst vraagt van architectuur (bijv businesslinemanager vraagt om businessprocesmodel);
• een partner werkt op strategisch niveau samen met de architect en bedenkt nieuwe richtingen met de architect (bijv strategische dialoog met de directie);
• een onderdaan wordt geacht te voldoen aan de architectuurvoorschriften (bijv ontwerper die architectuurkaders meekrijgt);
• en een gebruiker is iemand die zelfstandig gebruik maakt van de architectuurdeliverables (bijv een architect gebruikt het applicatielandschap van een collega-architect).
• De architect levert architectuurproducten die relevant zijn voor een of meerdere rollen. Daarbij kunnen architecten zich specialiseren in een onderwerp (bijvoorbeeld infrastructuur) of vakgebied (bijvoorbeeld sociaal domein). Dit betekent dat een architect niet alles over alle architectuurproducten hoeft te weten.

De architect levert architectuurproducten die relevant zijn voor een of meerdere rollen. Daarbij kunnen architecten zich specialiseren in een onderwerp (bijvoorbeeld infrastructuur) of vakgebied (bijvoorbeeld sociaal domein). Dit betekent dat een architect niet alles over alle architectuurproducten hoeft te weten.

Zijn rollen en competenties in evenwicht?

De vier rollen gecombineerd met de zes lagen van Bloom, geeft het model in figuur 2.

Dit model is op verschillende manieren te gebruiken. We kunnen inventariseren of alle kennislagen voor alle kwadranten in voldoende mate aanwezig zijn, en of de balans in de verdeling van de kennislagen over de architecten goed is. Als we witte of zwakke plekken vaststellen, kunnen we gericht werken aan het opvullen daarvan. Als we vaststellen dat meer architecten dan nodig in hetzelfde kwadrant en op dezelfde laag zitten, dan is het wellicht tijd voor verdere ontwikkeling van de architecten die dit ambiëren. Als we ontdekken dat sommige architecten zich bemoeien met zaken die niet tot hun takenpakket horen, zijn deze architecten hun functie wellicht ontgroeid en is het tijd voor nieuwe uitdaging door verbreding (vraagt nieuwe kennis ‘van een ander kwadrant’) of verdieping (vraagt kennis van een hogere laag in hetzelfde kwadrant) van hun takenpakket.

Een interessante vraag is of we het model ook kunnen gebruiken om architectenprofielen op te stellen voor de benodigde kennis.

Figuur 3 schetst een mogelijk kennisbeeld van een solution-architect: deze moet solution-architecturen kunnen opstellen (klantkwadrant), moet weten wat er speelt op strategisch niveau (partnerkwadrant), moet de enterprise- en domeinarchitecturen kunnen toepassen in specifieke verandercontexten (onderdaankwadrant) en moet voldoende met de architectuurrepository kunnen omgaan om er zelfontwikkelde architectuurproducten in te zetten en er de relevante architectuurproducten van collega-architecten uit te halen (gebruikerkwadrant).

Voor elk kwadrant geldt dat de buitenste ring die ingekleurd is, de competentie weergeeft waarop het accent ligt voor dat profiel en voor die relatie: die competentie is de hoofdverantwoordelijkheid van een architect met het betreffende profiel.

We zien in fig.3 dat de bediening van klanten van de architectuurfunctie goed is afgedekt door de solution-architect. Zolang er genoeg solution-architecten zijn met het geschetste kennisprofiel komt het goed. Maar in de andere drie kwadranten zijn nog witte vlekken. Iemand moet op strategisch niveau de architectuuruitgangspunten formuleren en de architectuurkaders opstellen. Vaak wordt dit belegd bij de lead-architect. Deze heeft ook vaak de verantwoordelijkheid voor het bepalen welke architectuurdeliverables worden gemaakt (fig.4).

Conclusie

Onze stelling is dat als een architectenteam niet goed functioneert, toepassing van Bloom in combinatie met de rollen van Hiemstra kan helpen om vast te stellen waar het wringt. Daarbij kan de volgende werkwijze gehanteerd worden: onderzoek waar het probleem zit en of de oorzaak gerelateerd kan worden aan een onbalans van competenties. Als dit het geval is, schets dan de gewenste situatie met behulp van het model en breng deze in praktijk.

Onbalans kan verschillende vormen hebben, bijvoorbeeld een benodigde competentie is niet aanwezig, een architect acteert vanuit een andere laag dan wenselijk is, of te veel architecten claimen exclusieve inzet van een bepaalde competentie.

We beseffen dat de kennisinvalshoek niet alle aspecten dekt, zo zijn ook factoren als de positie van de architectuurfunctie in de organisatie van invloed, alsmede de randvoorwaarden als tijd of geld. Met dit artikel hebben we de kennisfactor willen toelichten. Een goede balans in kennis is essentieel voor de effectiviteit en samenhang in een cognitief complexe functie als de architectuurfunctie.

[1] Huitt, W. (2011). Bloom et al.’s taxonomy of the cognitive domain. Educational psychology interactive, 22.

[2] Hiemstra, J. (2003). Presterende gemeenten: hoe gemeenten beter kunnen presteren. Kluwer.