This is the Dutch translation of the article: What is it an architect actually does?
De vraag werd gesteld door een manager van een stafafdeling die verantwoordelijk was voor architectuur, en enterprise architectuur in het bijzonder.
Ik deed mijn best uit te leggen hoe ik architectuur aanpak bij organisaties: welke mensen betrek ik er bij, hoe zorg ik ervoor dat het aansluit bij de werkvloer, bottom-up en top-down bewegingen synchroon inrichten, architectuurbewustzijn kweken op alle lagen van de organisatie en het architectuurproces inrichten.
Wellicht was dat verhaal op zich niet oninteressant maar er ontstond een groeiend onbehagen bij de andere partij. “Maar wat doe je nu concreet?”
Pas na het gesprek realiseerde ik mij waar mijn gesprekspartner behoefte aan had. Wat hij wilde horen was: ik heb die en die architectuurmodellen gemaakt, die en die workshops gehouden waar die en die documenten uit voortkwamen. Ik heb een baseline architectuur opgesteld samen met die en die stakeholders, en op basis van de strategische doelstellingen in gezamenlijkheid die en die doelarchitecturen opgesteld. Kortom: mijn gesprekspartner was wellicht wel geïnteresseerd in mijn “hoe” verhaal, maar kon het niet verankeren zonder het “wat” verhaal.
Die fout heb ik eerder gemaakt. Voor mij is immers het “hoe” zóveel belangrijker dan het “wat” dat ik soms vergeet dat voor veel mensen dat zo ongeveer is wat een architect doet: architecturen maken. Daarnaast zijn die aspecten voor mij misschien (naast dat ze secundair zijn en in mijn optiek ook zouden moeten zijn) zó vanzelfsprekend dat ik geneigd ben ze niet naar voren te brengen.
Ik wil zeker niet beweren dat ik het “wat” niet belangrijk vind, en voor mij was het wel degelijk een les dat aspect niet te onderbelichten wanneer ik de vraag een volgende keer krijg. Wat doet een architect? Hij legt de focus op het “hoe”, en gebruikt een reeks van tools voor het “wat”.
Wat denken jullie: wat doet een architect eigenlijk?
Door te proberen een antwoord te schrijven realiseer me dat dit een hele goede vraag is Rob. Misschien kunnen we het als volgt bekijken.
Als je een architect huurt om een huis voor je te bouwen ben je niet zozeer geïnteresseerd in welke middelen hij/zij gaat gebruiken maar in het resultaat – het huis zelf. Wat de architect doet om het einddoel te bereiken is o.a. jou (de klant) helpen om je doelen concreter te maken. Je bent geen bouwkundige. Je weet wel wat je van een huis verlangt en hebt waarschijnlijk enkele esthetische eisen/wensen maar hoe dat precies uit moet zien weet je niet. De schetsen die de architect maakt zijn middelen die jou helpen besluiten te nemen. De architect overlegt met specialisten (o.a. een constructeur) om a) te zorgen dat de “niet-functionele” eisen gerealiseerd kunnen worden en b) om tot een design te komen die door een aannemer uitgevoerd kan worden met de gewenste resultaat. De architect overziet het bouwproces en blijft betrokken tot je in je nieuw huis woont en het duidelijk is dat alles fungeert zoals verwacht. De architect bewaakt ook het maken van eventuele mankementen tijdens de garantie periode.
Maar die plannen en schetsen en calculaties en het bestek enz zijn niet het huis. Je huurt een architect niet in om architectuur te doen maar om jouw droom te (helpen) realiseren.
In enterprise architectuur geldt hetzelfde. “Wat” de architect doet en “hoe” hij/zij dat doet zijn niet het eindresultaat – het enterprise architectuur. In feite is “waarom” en nog belangrijker vraag omdat het antwoord hieraan is het bepalend factor voor hoe het eindresultaat eruit moet zien.
Jij en ik begrijpen dit. De klant vaak niet. We moeten dus een manier vinden om dit uit te leggen in zo’n manier dat de klant een goed gevoel krijgt dat je voor een goed eindresultaat gaat zorgen zonder dat ie dat met de “wat” verwart. Misschien begint dit door te kunnen laten zien dat je begrijpt waar de klant nu mee zit en wat hij wil bereiken.
Geen volledig antwoord. Sorry. Wel een begin.
Ik zou hier een uitgebreid antwoord op kunnen geven, maar dat doe ik niet.
Evenals Stuart helpt het om de analogie van het ontwerpen van een huis erbij te betrekken.
Zelf maak ik echter altijd gebruik van een visuele plaat waarin enterprise architectuur, zowel het “wat” als het “hoe” zichtbaar wordt.
Belangrijk hierin is dat EA ten dienste staat van de bedrijfsdoelstellingen en dat er rekening gehouden wordt met allerhande kaders. Daarbij worden ook de deliverables genoemd. Van streefarchitectuur t/m PSA.
Pingback: What is it an architect actually does? - From the Mist