De architectuurfunctie #3: De elementen van de architectuurfunctie

In een serie van vijf blogs neem ik je mee in onze praktijkervaringen met het inrichten en implementeren van de architectuurfunctie. Een belangrijk onderdeel om architectuur ‘te laten werken’. Onze ervaringen op dit gebied hebben we eerder gedeeld in de vorm van een webinar, dat je hier kunt terugkijken. In de tweede blog heb ik uitgelegd waarom het goed inrichten van de architectuurfunctie belangrijk is. In blog #3 behandel ik de elementen waaruit de architectuurfunctie is opgebouwd.

Een raamwerk uit de praktijk

Vanuit Solventa hebben we veel verschillende organisaties geholpen met het inrichten en/of professionaliseren van hun architectuurfunctie. Uiteenlopend van uitvoeringsorganisaties bij de overheid, een ziekenhuis, een hogeschool, diverse gemeenten tot een postbedrijf. En hoewel er uiteraard verschillen zijn te onderkennen in de inrichting van de architectuurfunctie, is uit al deze praktijkervaringen een raamwerk gevormd dat als basis dient om dit soort trajecten te structureren en sturen. Het bestaat uit vier elementen: architectuurproducten, architectuurprocessen, architectuurrollen en architectuurhulpmiddelen.

Element 1: Architectuurproducten

Architectuur kent veel verschillende doelgroepen. Denk onder andere aan bestuurders, managers, leveranciers, analisten, ontwerpers, projectleiders, portfoliomanagers en adviseurs. Elke doelgroep heeft behoefte aan een eigen scope, diepgang en perspectief van het ‘product’ architectuur, passend bij een specifiek gebruiksdoel. Eén architectuurproduct waarmee alle doelgroepen en doelen worden bediend, bestaat simpelweg niet.

De kernvraag is: welke samenstelling van architectuurproducten is het meest effectief en efficiënt? Je wilt niet te veel producten (want onbeheersbaar). Maar ook niet te weinig (want te weinig doel- en doelgroepgericht). Daarnaast wil je een duidelijke en logische verbinding tussen de producten en zo min mogelijk overlap.

Om de juiste productenmix vast te stellen, gebruiken we als hulpmiddel vaak een matrix waarin we de maximale ‘breedte’ en ‘diepte’ van architectuur weergeven en waarop de samenstelling van de architectuurproducten – letterlijk – kan worden ingetekend.

Element 2: Architectuurprocessen

Wanneer duidelijk is welke architectuurproducten worden gehanteerd, kan de slag worden gemaakt naar de architectuurprocessen. De producten komen niet zomaar tot stand, daar ligt een proces aan ten grondslag. Dat is deels een creatief en onvoorspelbaar proces, dat zich niet tot op het niveau van ‘werkinstructies’ laat beschrijven.

Een procesbeschrijving op hoofdlijnen is waardevol. Zeker als daarin, naast het proces van het opstellen van het architectuurproduct, de volgende aspecten zijn verwerkt:

• Het afstemmen van de opdracht
• Het afstemmen met stakeholders
• Het besluitvormingstraject en de rol van een architectuurboard o.i.d.
• Het verbinden met ‘aanpalende disciplines’ (bijvoorbeeld portfoliomanagement, strategievorming, informatiemanagement)
• Het gebruik van (onderdelen) van methoden (baseer je je proces op (onderdelen van) GEA, TOGAF, DYA, Novius?)

Voor een deel van de architectuurprocessen geldt dat ze deel uitmaken van een omvangrijker proces. Bijvoorbeeld het architectuurproces waarin een PSA (Project Start Architectuur) wordt gemaakt is onderdeel van het projectmanagementproces. In die gevallen is het belangrijk de relatie met dat proces (bijvoorbeeld gebaseerd op Prince2) helder te hebben en te weten in welke fase van het project welke bijdrage van de architect wordt verwacht.

Element 3: Architectuurrollen

Bij de uitvoering van de architectuurprocessen zijn verschillende rollen betrokken. Het derde element van de architectuurfunctie focust op de architectuurrollen. Welke soorten architecten kennen we en wie heeft welke verantwoordelijkheden in welk architectuurproces?

In de praktijk ervaar ik een wirwar van architectuurrollen. Elk specialisme kent zijn eigen rol: gegevensarchitect, security architect, projectarchitect, BI-architect, integratie-architect. En zo kan ik nog wel even doorgaan. Het maakt het er voor de omgeving niet eenvoudiger op. Kijk dus kritisch naar de samenstelling van architectuurrollen die je in je organisatie wilt onderscheiden. Ik wil daarbij de volgende tips meegeven:

• Maak niet van elk inhoudelijk specialisme een aparte rol. Hou de rol wat generieker (bijvoorbeeld: domeinarchitect) en onderken dat elke architect in die rol een of meerdere kennisgebieden als specialisme heeft
• Zorg voor een logische aansluiting met de architectuurproducten en architectuurprocessen.
• Maak een matrix van verantwoordelijkheden voor elk architectuurproces (bijvoorbeeld een RASCI-matrix) om de volledigheid van de onderkende rollen te checken
• Vermijd aparte rollen voor ervaringsniveaus (jr, medior, senior). Je vervult dezelfde rol, maar bent er meer of minder ervaren in.

Zijn de rollen onderkend, dan is de volgende stap het beschrijven van de taken en verantwoordelijkheden en de benodigde competenties van elke rol.

Element 4: Architectuurhulpmiddelen

Tot slot onderkennen we het element architectuurhulpmiddelen. Bij een professionele architectuurfunctie hoort de juiste gereedschapskist om het architectuurwerk effectief en efficiënt te kunnen uitvoeren. Denk bij hulpmiddelen aan:

• Financiële middelen. Voor de (interne en externe) capaciteit, maar ook voor het ondersteunen van verschillende werkvormen en communicatie-uitingen.
• Voor het gestructureerd en samenhangend vastleggen van ‘architectuurcontent’ en het kunnen uitvoeren van analyses daarop.
• In de meeste gevallen kiezen we voor Archimate, maar ook dan moet je met elkaar vaststellen hoe je dat gaat inzetten (wat gebruiken we wel of niet; welke conventies hanteren we; welke constructie kiezen we als Archimate meerdere mogelijkheden biedt).
• Dat kunnen externe opleidingen zijn, maar ook interne kennisoverdacht binnen het architectenteam.
• Sjablonen/formats. Hiermee zorg je ervoor dat de architectuurproducten eenzelfde opbouw en ‘look&feel’ krijgen.

Het inrichten van de architectuurfunctie betekent het ontwerpen en implementeren van de vier genoemde elementen. En hoewel het hier beschreven raamwerk generiek toepasbaar is, is de specifieke invulling bij elke organisatie (net wat) anders. In mijn volgende blog ga ik in op de organisatiespecifieke invulling van het raamwerk en de aspecten die daarvoor bepalend zijn.