De architectuurfunctie #4: Een organisatiespecifieke invulling van de architectuurfunctie

Door: Rob Stovers

In een serie van vijf blogs neem ik je mee in de praktijkervaringen (van mijzelf en van mijn collega’s bij Solventa) met het inrichten en implementeren van de architectuurfunctie. Een belangrijk onderdeel om architectuur ‘te laten werken’. De ervaringen op dit gebied hebben we vanuit Solventa eerder gedeeld in de vorm van een webinar, dat je hier kunt terugkijken. In de derde blog behandelde ik de elementen waaruit de architectuurfunctie is opgebouwd. In deze vierde blog ga ik in op de organisatiespecifieke invulling van deze elementen en de aspecten die daarvoor bepalend zijn.

Een generiek raamwerk

In de vorige blog heb ik een raamwerk voor de architectuurfunctie gepresenteerd. Dit raamwerk bestaat uit vier elementen: architectuurproducten, architectuurprocessen, architectuurrollen en architectuurhulpmiddelen. Tot op heden heb ik nog geen organisatie getroffen waar dit raamwerk niet kan worden gebruikt. En tot op heden is er ook nog geen aspect van de architectuurfunctie geweest dat ik niet in het raamwerk kon plaatsen. Het nut van zo’n generiek raamwerk is dan ook dat je weet dat alle benodigde elementen van de architectuurfunctie aandacht krijgen en dat je geen element vergeet. 

Hoe specifiek is de invulling van de elementen?

Maar zo’n raamwerk is natuurlijk maar het begin. Het gaat erom de elementen voor je eigen organisatie in te vullen. Als ik kijk naar de invulling bij zeer uiteenlopende organisaties, dan zie ik verrassend veel overeenkomsten. Zo zijn er meerdere architectuurproducten die bij veel organisaties worden gehanteerd: enterprisearchitectuur, domeinarchitectuur en projectstartarchitectuur. En ook de specificatie van de inhoud van dit soort producten is voor een groot deel gelijk. Een enterprisearchitectuur zonder bedrijfsfunctiemodel, objectmodel of procesmodel kom ik zelden tegen. De invulling van de architectuurfunctie lijkt daarmee een stuk generieker dan de architectuurinhoud. Is er daarmee sprake van eenheidsworst? Dan nu ook weer niet. En juist in het onderkennen en inrichten van de organisatiespecifieke invulling c.q. accenten zit de uitdaging én het succes.

Wat bepaalt de verschillen?

Er zijn meerdere aspecten of kenmerken die de specifieke invulling van de architectuurfunctie bepalen. Ik zal de naar mijn idee belangrijkste vier hiervan behandelen.

Aspect 1: Visie op architectuur

Hoe een organisatie over architectuur denkt heeft een duidelijke invloed op de inrichting van de architectuurfunctie. Zie je architectuur vooral als een IT-discipline, dan zullen de architectuurproducten ook die focus hebben en zul je in de architectuurrollen zien dat IT-kennis en -competenties belangrijk zijn. Een ander visie-aspect is hoe sturend architectuur is of mag zijn. Gaat het om richtinggevende kaders die veel ruimte laten voor oplossingen of om uitgewerkte blauwdrukken? Ook dat heeft invloed op je productsamenstelling en op het architectuurproces, bijvoorbeeld in de mate waarin en de manier waarop architectuur wordt gehandhaafd in de realisatiefase.

Aspect 2: Kenmerken van het werkveld

Veel of weinig verschillende processen. Veel of weinig afhankelijkheden van samenwerkingspartners. Veel of weinig afhankelijkheid van informatietechnologie. Allemaal aspecten die je terugziet in de architectuurfunctie. Ter illustratie onderstaand voorbeeld aan de hand van een het werkveld van een gemeente (met dank aan Solventa-collega’s Juan Antonio de Beer en Bastiaan Zuiderhoek).

Voorbeeld

Een gemeente heeft een complexe set van (vaak wettelijke verplichte) primaire processen. Afvalverwerking, vergunningverlening, verstrekken van uitkeringen en subsidies, evenementen organiseren. Deze zijn relatief onafhankelijk en werken voor een deel met eigen voorziening. Daarnaast zijn er ook generieke voorzieningen die voor de gehele gemeente zijn ingericht. Denk aan de financiële administratie, het zaaksysteem en identity- en accesmanagement. Het zoeken naar het juiste evenwicht tussen specifiek en generiek zie je terug in de elementen van de architectuurfunctie:

• Architectuurproducten: welke scope heeft een bepaald product (bijvoorbeeld een PSA)? Kan dat volledig decentraal zijn? Of zijn er ook centrale voorziening in beeld?
• Architectuurprocessen: voor de decentrale/specifieke producten is er minder noodzaak voor een uitgebreide toetsing in meerdere gremia, bij producten waarin veel centrale voorzieningen een rol spelen is die behoefte (en het belang) groter 
• Architectuurrollen: door de grote diversiteit ontstaat bijvoorbeeld de volgende samenstelling van architectuurrollen: architecten per domein, architecten per (decentrale) organisatorische eenheid en specifieke architecten voor generieke voorzieningen
• Architectuurhulpmiddelen: een centrale repository is een noodzakelijk hulpmiddelen om verbanden te zien en overzicht te houden 

Aspect 3: Omvang van de organisatie 

Relatief kleine organisaties hebben doorgaans wel de volledige architectuurcomplexiteit, maar een kleine bezetting. Dit vraagt om keuzes in de productsamenstelling en de architectuurrollen. Het is essentieel om je te beperken tot de hoogstnoodzakelijke onderdelen en te streven naar maximaal gebruik van extern beschikbaar architectuurmateriaal (bv referentiearchitecturen). Grote organisaties hebben doorgaans ook meer architecten. Dan ontstaat veel meer behoefte aan standaardisatie en afspraken binnen de architectuurfunctie. Bijvoorbeeld over de werkwijze, metamodellen  en de wijze van communicatie. Met z’n tweeën kom je daar wel uit. Met 30 architecten zul je toch wat meer met elkaar moeten afspreken.

Aspect 4: Volwassenheid van de ‘aangrenzende disciplines’

Architectuur is geen geïsoleerde discipline. Als het goed is. Er zijn veel verbindingen met andere disciplines zoals projectmanagement, portfoliomanagement, change management, strategievorming en inkoop. Hoe volwassener deze disciplines zijn, hoe beter de aansluiting met en inbedding van de architectuurfunctie met deze disciplines kan worden geduid. Zo is het lastig om het architectuurproces binnen een project scherp te beschrijven als er geen gestandaardiseerd project(management)proces aanwezig is. En als er een onvolwassen portfoliomanagementfunctie is, dan wordt het onderbrengen van de in een architectuurproduct voorgestelde transitie een stuk lastiger.  

Deze (en meer) aspecten bepalen uiteindelijk de ‘finetuning’ van de inrichting van de architectuurfunctie. En juist deze finetuning is essentieel om succesvol architectuur te bedrijven. In de vijfde (en laatste) blog uit deze serie laat ik zien op welke manier we de ontwikkeling van de architectuurfunctie in de praktijk aanpakken.