Lerende architecten

Architecten zijn vaak betrokken bij innovatie en vernieuwing. Er ontstaat ergens in de organisatie een idee, dit moet op allerlei manieren onderzocht worden, en alleen als het een vruchtbaar idee lijkt, tot een oplossing gebracht worden. En als het aan de architecten ligt, dan moet de oplossing natuurlijk onder architectuur gerealiseerd worden. Over wat dit precies behelst verschillen de lezingen echter.

De kwestie

Don Tapscott heeft in zijn visionaire boek “the Paradigm Shift” al in 1993 een werkmodel geschetst voor werken onder architectuur. Het bestaat uit vier stappen, te weten:

1. Reimage – het ontwikkelen van een visie

2. Restructure – het structureren van een oplossing

3. Realize – het ontwikkelen en in gebruik nemen

4. Renew – een continue verbetering

Het zal u misschien opvallen dat Tapscott zich hierbij heeft laten inspireren door de bekende Deming-cyclus (“plan-do-check-act”). Er zijn in elk geval ook vier fasen en het is beide gericht op een lerende organisatie.

In 2001 kwam Sogeti onder het kopje DYA – Dynamische Architectuur – met een eigen model. Dit bestaat uit drie stappen, te weten:

1. De Strategische Dialoog – het bepalen van de business doelen

2. Architectuur Services - het opstellen en bewaken van de architectuur

3. Ontwikkelen (z)onder architectuur – het realiseren van de business doelstellingen

De parallel tussen deze twee modellen is op zich opvallend. De strategische dialoog is bedoeld om een gemeenschappelijke visie te ontwikkelen. Architectuur Services geven structuur en kader aan de oplossingen. En de daadwerkelijke realisatie wordt onder architectuur gebracht als de rol van de architecten niet beperkt is tot het beschrijven van de architectuur. Tegelijkertijd is het kenmerkende verschil in het achterliggende denkmodel opmerkelijk. Waar Tapscott veel waarde hecht aan het leren van fouten in en het continue verbeteren van eenmaal gerealiseerde oplossingen, ontbreekt dit in het DYA denkmodel volledig. Als de oplossing gerealiseerd is, dan hebben de Dynamische Architecten hun taak naar behoren vervuld.

Gemiste kans

Het verschil tussen de modellen is wellicht te verklaren uit het feit dat Sogeti, de organisatie achter het DYA-model, een leverancier is, die het moet hebben van het uitvoeren van projectgebonden activiteiten, en betrekkelijk lastig geld kan verdienen aan de structurele activiteiten die voor continue vernieuwing nodig zijn. Het structureel analyseren en verbeteren van het bestaande applicatieportfolio is immers eerder iets voor de gecommitteerde 'insiders' binnen een bedrijf, dan voor tijdelijke 'inhuurkrachten' van buiten. Maar daarom hoeft de architectuurcommunity zich nog niet bij deze omissie neer te leggen. Er werken tenslotte ook tal van gerenommeerde architecten als 'insider' bij bedrijven en instellingen. Is continue vernieuwing een relevante activiteit voor architecten? Zou het in het architectuurproces een plaats moeten krijgen? Zo ja, hoe geeft je dat dan vorm? Of zouden alle architecten zich uit hoofde van hun functie moeten concentreren op projecten met een afgebakend doel en een beperkte looptijd?

Als het leren van de gemaakte keuzes een doel is – en waarom zouden architecten niet van praktijkervaringen kunnen leren – dan ligt het in elk geval erg voor de hand dat er na het opleveren structureel een serieuze analyse wordt gedaan van de goede en mindere aspecten van de architectuur. In hoeverre was de project-start-architectuur doelmatig? Was hij correct, volledig en niet voor misverstanden vatbaar? De antwoorden op die vragen zijn ongetwijfeld leerzaam. Een end-of-project review lijkt dus een nuttig instrument om de architectuurfunctie te verbeteren. Maar is het voldoende?

Vanuit een business perspectief is de belangrijkste vraag waarschijnlijk of de gekozen architectuur adequaat is. Met andere woorden: is het op basis van de gekozen architectuur mogelijk gebleken om de business doelstellingen daadwerkelijk te realiseren. In de praktijk zal het niet vaak voorkomen dat deze vraag al aan het einde van een project beantwoord kan worden. Immers, na het invoeren van een nieuwe IT-oplossing verloopt er doorgaans de nodige tijd voordat de business doelstelling daadwerkelijk en volledig is gerealiseerd – al was het maar omdat de impact op de organisatie (waaronder de beheerorganisatie) nog moet blijken. Dat betekent ook dat er na verloop van tijd mogelijk nog belangrijke lessen te trekken zijn uit de praktijk van het levende systeem. Echter, alleen als architecten bereid en in staat zijn om een serieuze post-project review te doen, kan er van die – ongetwijfeld weerbarstige – praktijk daadwerkelijk geleerd worden.

Maar zelfs in het geval dat de business doelstelling volledig is gerealiseerd, dan wil dat nog niet zeggen dat het denken hoeft op te houden. De wereld is continu aan het veranderen. De markt ontwikkelt in een hoog tempo en de technologische mogelijkheden nemen met de dag toe. Het kan, met andere woorden, niet zo veel kwaad om periodiek en structureel te evalueren of de bestaande oplossingen nog wel adequaat zijn in de huidige situatie. Het overleven van de concurrentiestrijd vereist een mate van fitheid die zonder een gezonde portie beweging domweg niet houdbaar is.

Natuurlijk is het niet eenvoudig om dit te organiseren. Veel architecten worden geleefd door de 'hartbeat' van projecten. En zeker in het geval van inhuur is de betrokkenheid van de architect bij de organisatie vaak van beperkte duur. Maar zolang de architectencommunity niet om te beginnen de ambitie uitspreekt om een lerende discipline te willen zijn, dan gaat het zeker niet lukken om oplossingen te vinden voor dat soort organisatorische problemen. Misschien zouden we eens een business architect moeten vragen hoe je zo'n nijpend probleem nou het best zou kunnen oplossen?

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 9^de in een reeks die op dit weblog gepubliceerd zal worden.