Tips voor een effectieve Architectuur functie

Als architect zie ik dat iedere organisatie een andere manier heeft om ‘architectuur te bedrijven’. Ik krijg ook vaak de vraag hoe de architectuur bij andere organisaties is georganiseerd en wat er te verbeteren valt aan hun aanpak.

Er is geen ‘silver bullet’, iedere organisatie heeft op architectuurvlak zijn eigen behoefte, cultuur, volwassenenheidsniveau, grootte en complexiteit. Maar natuurlijk zijn er ook een aantal zaken die je overal terug ziet komen, een soort ‘ongeschreven wetten’ die vrijwel altijd positief uitwerken.

Ik heb een aantal van mijn positieve ervaringen verzameld.

Kies een standaard architectuur framework en maak het praktisch

Kies bijvoorbeeld het TOGAF model als basis, en zorg dat er voor iedere architectuur fase beschreven is wat je minimaal nodig hebt. Het doel is om te zorgen dat de organisatie (en dus ieder team/project) voldoende besef heeft van de architectuur richting en of verandering en de daaruit volgende kaders, zodat men zich eraan kan ‘verbinden’. Deze verbinding is nodig, omdat werken onder architectuur niet alleen gaat over techniek en/of functionaliteit, maar ook over het werken aan zaken als de missie van het bedrijf, het halen van project deadlines en het maken van kosten.

Onderkennen van verschillende architectuur rollen

Iedereen kent wel het gevoel dat er aan zijn stoelpoten wordt gezaagd. Helaas is dit gevoel voor veel architecten meer dan gemiddeld aanwezig. Dit is lang niet altijd met opzet. Een architectuur rol is vaak een ‘onbegrepen rol’, een rol waar weinig mensen gevoel bij hebben. Daarnaast is het niveau en de verscheidenheid aan mensen waarmee wordt gewerkt heel divers, namelijk de beslissers op directieniveau, het middle management, het project management, inkopers, techneuten, etc. Om het nog lastiger te maken, zijn er ook nog verschillende typen architecten, ieder met een eigen beeld van zijn verantwoordelijkheid.

Er zijn een aantal architectuur rollen waarvan ik vind dat ze zeker nodig zijn. Het is noodzakelijk dat iedereen in de organisatie deze rollen kent en de noodzaak ervan begrijpt. Natuurlijk kan 1 persoon meerdere rollen invullen, of kan de rol gecombineerd worden met een andere rol. Maar het is heel belangrijk dat deze persoon zich bewust blijft van het feit dat het verschillende rollen zijn. Voorbeelden van combinaties zijn: Software Architect met Senior Developer en Solution Architect met Software Architect.

De architectuur rollen die nodig zijn:

• Enterprise Architect: Focust op de missie, visie, doel en strategie van de hele organisatie.
• Business Architect: Focust op het ondersteunen van de bedrijfsvoering, vanuit functioneel perspectief. Vaak is deze functie ingedeeld per business domein.
• IT Architect: Focust op het ondersteunen van de bedrijfsvoering, vanuit technisch perspectief (‘uit welke producten/bouwstenen bestaat mijn IT landschap?’).
• Solution Architect: Focust op het vertalen van algemene architectuur in oplossingen, in meer detail en per technologie (verdiepingsarchitectuur) of per project (architectuur voor het project, plus de regie daarop).
• Software Architect: Focust op de technische detail oplossing binnen een applicatie.

Beleg de verantwoordelijkheid binnen de juiste rol

Een architect kan alleen succesvol zijn als de organisatie om hem heen zich aan de rollen en (gedelegeerde) verantwoordelijkheden houdt. Richt de organisatie en de processen ook in naar de interactie tussen deze rollen en zorg daarbij voor bewuste en vaste communicatiemomenten (reguliere meetings, etc) tussen de rollen onderling.

Een aantal tips:

• Zorg dat de beslissers alleen beslissen en niet het werk overnemen van de architecten. Dit zie ik vaak gebeuren omdat er politieke, financiële en commerciële (zoals leveranciers) invloeden zijn waar de beslissers worden verleid om inhoudelijk (maar zonder de juiste expertise) mee te praten.
• Zorg voor de aansluiting van architecten bij de business ontwikkelingen. Binnen vrijwel ieder bedrijf is een vorm van portfolio management aanwezig, waar de bedrijfsvisie wordt omgezet in concrete initiatieven en projecten. Op basis van prioriteiten wordt een programma- of project roadmap vastgesteld, een ideale plek om deze bewust uit te lijnen met de architectuur roadmap. Dit effect wordt krachtiger als het portfolio proces iteratief is, waardoor met regelmaat kan worden bijgestuurd op basis van recente informatie.
• Laat architecten nooit onder een projectleider vallen. Vrijwel iedere moeilijke beslissing (tijd, scope, geld) zal dan in het projectbelang worden beoordeeld, en niet in het algemene (architectuur) belang. Dit ondermijnt een zuivere discussie waar project en algemeen (architectuur) belang op het juiste niveau worden besproken: niet binnen het project, maar overkoepelend.
• Zorg dat er een technisch architectuur eigenaar is, en laat die formeel samenwerken met de functioneel georiënteerde eigenaren (Product Owners/Managers). Er is een grote kans dat er vanuit de techniek oplossingen zijn die goed passen bij de (toekomstige) functionele wens. Met deze vorm van samenwerking kun je ervoor zorgen dat dit tijdig wordt onderkend. Ook worden functionele en technische belangen dan op hetzelfde niveau gewogen.
• Stel vooraf de project kaders vast, maar niet in teveel detail. Geeft het (project) team de ruimte om binnen de kaders te komen met de juiste oplossingen. De kans is namelijk vrij groot dat je vooraf niet voldoende informatie hebt om de optimale beslissingen voor het hele project te nemen. Wanneer je teveel in detail treedt, neem je mogelijkheden tot het uitwerken van (gedragen) oplossingen door het team onnodig weg. Deze benadering heeft overigens ook een positieve invloed op de doorlooptijd die nodig is voor het schrijven van een Project Solution Architectuur document.
• Laat de Solution en Software Architect werken als onderdeel van het ontwikkelteam, om de details in te vullen en om (indien nodig) de architectuur kaders en standaarden bij te stellen. Daarmee wordt een deel van het eigenaarschap gedeeld met het team, de mensen die de echte implementatie doen. Op deze wijze wordt op een ‘natuurlijke manier’ vorm gegeven aan een stuk regie (Governance) op de oplossing.