De verantwoordelijke architect

This article is translated into English: The Responsible Architect

Dit artikel is in oorspronkelijke vorm verschenen als hoofdstuk in het boek “Pak je kansen met architectuur”, een boek dat is samengesteld uit bijdragen van sprekers op het Landelijk Architectuur Congres (LAC) 2010.
Het artikel beschrijft aspecten van de rol van architectuur in organisaties, en in het bijzonder die van de enterprise architectuur. Zoals veel artikelen op deze site is het in de loop van de tijd aangepast, en er is ook een engelse vertaling van gemaakt.

Met schuld kun je schuiven, met schaamte niet.

Freek de Jonge

Enterprise architectuur als schaduw hiërarchie

Dit artikel is een introductie van een enterprise architectuur raamwerk voor de organisatorische inbedding van architectuur geïnspireerd door de Trias Politica in het staatkundig bestel. Dit raamwerk maakt succesvol implementeren van architectuur minder afhankelijk van individuen en toeval. Het gaat om het inbedden van architectuur in de organisatie waardoor het een integraal deel wordt van de levensstroom van de organisatie, en een aanwijsbare rol speelt in het algehele succes van de organisatie als geheel in tegenstelling tot incidentele successen beperkt tot losse projecten.

Rationale

Organisaties kiezen voor het werken onder architectuur omdat ze menen daar een aantal doelen mee te bereiken. Echter, door de wijze waarop de organisatie zélf is ingericht wordt het daadwerkelijk bereiken van die doelen tegelijk onmogelijk gemaakt. IT architectuur en de vaandeldragers daarvan, de architecten, hebben mede hierdoor aan geloofwaardigheid ingeboet.

Organisaties hebben met architectuur geen historische ervaring. In de bouwwereld is hier op een bepaalde manier (die niet overal gelijk te stellen is met de rol van architectuur in organisaties en business management) wel ervaring mee, maar de focus van de architect ligt daar in verhouding meer op esthetiek, projecten, en in projecten vooral het begintraject.

Dit gebrek aan geschiedenis, en de lessen die daaruit te leren zijn, is goed te zien aan de wijze waarop organisaties het werken onder architectuur proberen in te voeren: ieder op zijn eigen manier, vaak sterk gekleurd door de individuele architect die de kar moet trekken, evenals zijn manager, die meestal een IT manager is.

Architectuur in organisaties zou daarentegen geheel verweven moeten zijn in projecten zowel als de lijn. Wanneer we architectuur proberen weg te delegeren naar projecten en techniek maken we een fundamentele fout. We zien dit bijvoorbeeld terugkomen in de problematiek rond het overdragen van project naar beheer en de moeite die het kost om de beheerorganisatie en de lijn in een vroeg stadium bij projecten te betrekken.

Organisatieontwikkeling heeft zich de afgelopen jaren, waarin bedrijfskunde zich een plek heeft veroverd, vrijwel uitsluitend gefocust op de processen in organisaties. Welke processen zijn er, en hoe kan ik die beter stroomlijnen, er meer controle op krijgen, en de risico’s managen? Dat zijn de vragen die deze benadering probeert te beantwoorden.

Vanuit het strategisch management zijn dit ook begrijpelijkerwijs de vragen die gesteld worden. De insteek op het strategisch niveau wordt minder bepaald door de inhoudelijke positie van het bedrijf. Een voorbeeld: bij een grote verzekeraar vroeg ik ooit aan een algemeen directeur wat het doel was van het bedrijf. Wat was de reden van bestaan van deze verzekeraar? Het antwoord was veelzeggend maar ook onthutsend: “Het doel van ons bedrijf is geld verdienen.” Een verzekeraar kan zich misschien naar de klant toe positioneren als een partij die helpt risico’s te managen, het gevoel van zekerheid groter te maken, of wat dan ook – de uiteindelijke drijfveer op de strategische lagen in de organisatie zijn veel meer gedreven door winst en verlies, en waarde creëren voor aandeelhouders.

Deze procesbenadering lijkt het meeste aan te sluiten bij de behoefte aan informatie op het strategische niveau.

Het doel van architectuur is echter niet de winst te maximaliseren. Dat is natuurlijk wel een nevendoel, of een impliciet doel. Uiteindelijk heeft architectuur geen reden van bestaan als het daaraan niet zichtbaar bijdraagt. Het primaire doel van architectuur wordt op veel verschillende manieren verwoordt:

• “Verbeteren van time-to-market, flexibiliteit, agility”
• “Verbeteren van de aansluiting van IT systemen op de gebruikers daarvan”
• “Verhogen van de kwaliteit van oplossingen”
• “Betere aansluiting over projecten heen van oplossingen”

De definitie van het doel van architectuur dat ik in dit artikel introduceer is:

Architectuur is een proces dat verantwoordelijk is voor het borgen en optimaal benutten van inhoudelijke competenties binnen de organisatie

Het speelt hierbij een rol die equivalent is aan de wetgevende macht. Hiermee positioneert architectuur zich dicht aan tegen het concept van de lerende organisatie. Het sluit hiermee ook aan bij een algemeen gevoelde behoefte aan een carrière groeipad dat niet automatisch hoeft uit te monden in een executieve functie.

Architectuur legt vaak de focus op kwaliteit van oplossingen, naast uniformering en consolidatie (“kaders en richtlijnen”) om kosten te reduceren. Dit kan leiden tot het beeld van de architect als een blok aan het been. Als de focus op kwaliteit te groot is, krijgen we de ivoren toren architecten voor wie het nooit goed genoeg is, en die alleen het beste (en duurste) willen. Als de focus op uniformering te groot is krijgen we de “lastige architect”, die als een dwangbuis wordt ervaren bij de uitvoering en vernieuwing en creativiteit in de weg staat. Het is sowieso erg lastig gebleken om als architect of architectuuronderdeel van een organisatie een positief imago te krijgen en te behouden. Architectuur wordt snel een last. Zodra dat het geval is kan architectuur steeds moeilijker de rol van enabler waarmaken, en is ingrijpen geboden omdat meestal architectuur zich dan al op een glijdend vlak bevindt … naar de afgrond.

Binnen organisaties is één proces meestal goed gedefinieerd, ondanks het feit dat dit proces meestal niet expliciet benoemd wordt. Dit proces noemen wij het executieve proces equivalent aan de uitvoerende macht in het staatkundig bestel.

Het executieve proces is goed gekoppeld aan rollen en verantwoordelijkheden in een executieve hiërarchie. Het is vaak nauw gekoppeld aan het zogenaamde organigram.

Binnen dit model is iedereen hiërarchisch gekoppeld aan een leidinggevende, en optioneel zelf ook weer een leidinggevende aan anderen. Deze koppeling wordt bepaald door beoordelingen en functioneringsgesprekken, en kenmerken zich door een aantal verschillende sturingsmodellen.

Het executieve proces heeft een gevestigde historie.

Dit proces begint echter meer en meer tekenen van verval te vertonen. In deze context wil ik hierop niet in detail ingaan, maar de oorzaak van het toenemende tekortschieten van dit model ligt mijns inziens in het feit dat dit model teveel het hoe (proces) loskoppelt van het wat (domein). Alsof een manager bepaalt of een organisatie succesvol is, los van de industrietak waarbinnen deze manager zijn sporen heeft verdiend. Het heeft geleidt tot een volstrekte woekering van personen die de rol van manager vervullen, en heeft de aandacht maar ook het respect voor wat daadwerkelijk door de organisatie gedaan wordt, de primaire productie, doen doodbloeden.

Het levensbloed van elke organisatie is hierdoor vervuild geraakt. Organisaties zijn gaan leiden aan hartvervetting, en proberen voortdurend buiten adem achter de feiten aan te hollen. Ik kan mij de tijd nog heugen dat het woord “manager” in Nederland met enig dedain werd uitgesproken. Het werd geassocieerd met Amerika en een merkwaardige ziekte, de zogenaamde “managers-disease”. Beiden waren in Nederland onbekend. Hoe treffend!

Trias Politica in architectuur

Om hieraan een stop toe te roepen is het concept nodig van architectuur als een schaduwhiërarchie, een inhoudelijke hiërarchie, equivalent aan de wetgevende macht in de Trias Politica.

Politiek: Wetgevende macht – Rechterlijke macht – Uitvoerende macht
Organisatorisch: Inhoudelijke hiërarchie – Stuurorganen – Executieve hiërarchie

Deze inhoudelijke hiërarchie is gekoppeld aan een eigen proces dat anders is dan het executieve proces. Dat proces is het architectuurproces, of kort gezegd: architectuur.

Voor de oplettende lezer is het duidelijk dat wij hier spreken over een variant van enterprise architectuur, waarvan IT architectuur een onderdeel vormt.

Om het primaire proces uit te voeren is expertise nodig. Inhoudelijk competente personen zijn bepalend voor succes. Iedere betrokkene bij dit primaire proces brengt zijn competentie in. Daarbij neemt deze persoon beslissingen. Bij complexe processen zoals software ontwikkeling of innovatie is het percentage architectuurbeslissingen groter dan bij eenduidiger processen zoals in de procesindustrie.

Een architectuurbeslissing is een beslissing over een vraagstelling die zich kenmerkt door een transitieve eigenschap. Dat wil zeggen dat deze beslissing gevolgen kan hebben die verder reiken dan de plek waarop de beslissing wordt genomen. Het is een soort rimpel effect, alsof je een steen in een vijver gooit die golven veroorzaakt waardoor op een willekeurige plek elders in het systeem iets kan omvallen. Anders dan een design keuze, heeft een architectuurkeuze potentieel desastreuze gevolgen, terwijl de keuze zelf misschien het probleem heeft opgelost. De operatie was succesvol, de patiënt is overleden.

Bij het inrichten van deze inhoudelijke hiërarchie zijn drie aandachtspunten van kritisch belang:

1. Aansluiting bij de executieve hiërarchie
2. Bewaking van gescheiden houden van beide hiërarchieën
3. Kritische bewaking van de kwaliteit van het architectuurproces zélf

Feitelijk gaat het hier om een scheiding van machten die equivalent is aan de Trias Politica, die soortgelijke voordelen wil behalen. Voor Montesquieu die de basis legde voor dit concept dat aan de wortel ligt van de moderne democratie vormde de inrichting van de prille Nederlandse staat en de Staten Generaal een belangrijke inspiratie.

Hiervoor dienen duidelijke afspraken over de wijze waarop deze scheiding dient te worden gehandhaafd gemaakt te worden.

Door deze afspraken kan worden voorkomen dat bijvoorbeeld architecten sturende verantwoordelijkheden krijgen (punt twee hierboven) — dat dient voorbehouden te blijven aan de executief verantwoordelijken. Binnen projecten houdt dit bijvoorbeeld in dat een afdelingsarchitect niet tegen een projectarchitect kan zeggen dat hij een architectuurbeslissing niet mag nemen, omdat die indruist tegen corporate standaarden. Hoogstens kan hij of zij pogen een compromis te sluiten (Ontwikkelen Zonder Architectuur, DYA), maar als dat niet lukt kan hij alleen maar zijn zaak verdedigen ten overstaan van binnen en rond het project executief verantwoordelijken, wat ik hierboven algemeen heb benoemd als Stuurorganen. Binnen een Prince2 structuur bijvoorbeeld is dat de stuurgroep. In een verder doorgevoerde Trias zou dit een aparte structuur zijn, equivalent aan de juridische macht.

Het volgen van corporate standaarden zou een enterprise belang moeten hebben. In de stuurgroep heeft als het goed is een persoon zitting die dat belang vertegenwoordigt. Het is zijn verantwoordelijkheid dat belang te verdedigen binnen het krachtenveld van belangen waarin de stuurgroep de keuzes moet maken.

Architecten hebben nooit zitting in een stuurgroep, wanneer wij het proces inrichten volgens dit framework – het zijn immers inhoudelijk verantwoordelijke rollen! Zij worden gehoord bij escalerende processen, equivalent aan getuigen-deskundigen in een rechtszaak.

Er is dus wel sprake van een hiërarchie in de architectuurpoot van de Trias, maar deze onderscheidt zich op een wezenlijk punt van de executieve hiërarchie: architecten “hoger” in de hiërarchie sturen niet aan! De opties die open staan in de hiërarchische architectenrelatie zijn:

1. Top-down: Herbruikbare (met de nadruk op “bruikbaar”!) standaarden en referenties aanreiken
2. Bottom-up: deze standaarden en referenties destilleren uit de praktijk
3. Pogen tot werkbare concessies te komen volgens een consensus model
4. Wanneer nodig: escaleren naar de sturende poot van de Trias

Er dient gewaakt te worden voor een haantjesgedrag onder architecten.

Organisaties zijn meestal nog verre van democratisch — ze lijken vaak eerder op middeleeuwse feodale structuren. De voorgestelde scheiding der machten kan helpen om vastgelopen interne processen weer los te trekken.

Voor een succesvolle borging van het architectuurproces binnen organisaties is een effectieve en soepel verlopende samenwerking met het executieve proces (dat immers veelal leidend is) van essentieel belang. Tevens is duidelijkheid over die scheiding van groot belang. Hiervoor hebben wij een flink aantal richtlijnen verzameld.

Inhoudelijke competentie opbouw

Een architectuurproces op poten zetten is geen sinecure, om een open deur in te trappen. Het blijkt echter dat de voorgestelde inbedding in organisaties zeer goed aansluit bij organisaties die bezig zijn een omslag te maken naar grotere wendbaarheid (agile processen en meer zelfsturende teams). Het helpt bij het helderder aansturen van projecten, maar ook bij het beter aansluiten van projecten op de lijnorganisatie, bijvoorbeeld het eeuwige gevecht rond de overdracht van projecten naar beheer.

Binnen het architectuurproces is sprake van twee bewegingen, waarbij wellicht bij het opstarten van het architectuurproces de eerste belangrijker is dan de tweede:

1. Bottom-up: kennis ontstaat op de werkvloer, en het architectuurproces faciliteert de ontwikkeling en borging daarvan.
2. Top-down: richtlijnen en kaders, maar bijvoorbeeld ook referentie architecturen en showcase applicaties.

De bewakers van het architectuurproces, de architecten, dienen zich voortdurend bewust te blijven van het belang van beide bewegingen en niet te vervallen in de veel gemaakte fout zich te verliezen in de tweede.

Kwaliteitsbewaking

De kwaliteitsbewaking van het architectuurproces (punt drie hierboven) moet helpen om de voortdurende neiging van architecten tot zelfbevlekking de kop in te drukken.

Een voorbeeld is de (gelukkig nu enigszins beteugelde) explosie aan architectenrollen bij de belastingdienst, waar ik een projectarchitect hoorde verzuchten: “ze bedenken maar, we kíjken niet eens naar hun kaders en richtlijnen want die staan te ver af van de werkelijkheid …”.

Hiervoor is een proces van continue reviews (waaronder veel aandacht voor peer-reviews) nodig. Periodiek zijn ook externe audits om tunnelvisie te voorkomen heel hard nodig. Dit interne zowel als externe kwaliteitsproces moet er toe leiden dat de adviesrol die de inhoudelijke hiërarchie heeft naar de executieve hiërarchie, bijna bindend kan zijn. Er moet op vertrouwd kunnen worden. Besteedt veel aandacht aan de vrijheid van dit audit proces: het dient werkelijk onafhankelijk advies te kunnen uitbrengen.

Een gevolg van het inrichten van dit proces moet expliciet genoemd worden: het effect op de kwaliteit van executieve besluitvorming. In organisaties die het architectuurproces ontberen zijn executief verantwoordelijken chronisch te weinig of foutief geïnformeerd. Zij zijn teveel afhankelijk van informatie van de executieve laag onder hen die veelal sterk gekleurd is door politieke krachten. Een executief verantwoordelijke in organisaties met een gevestigd architectuurproces krijgt de beschikking over meer en betere informatie om zijn beslissingen mee te ondersteunen.

Op deze wijze ingericht kan enterprise architectuur van een proces dat verzandt in stroperigheid en politiek getouwtrek, worden tot een pijler van succes. En kunnen architecten eindelijk, in plaats van wanhopig hun bestaansrecht te verdedigen, eens een keer wat nuttigs gaan doen.

---

Rob heeft de missie bij te dragen aan het integreren van informatietechnologie in mens, organisatie en maatschappij. Zijn ervaringen als (enterprise) architect bij verscheidene (semi-) overheidsorganisaties w.o. de politie hebben het idee van de Trias Politica in organisaties bij hem doen wortel schieten.

---

Boekenlijst

• 

• 

Gerelateerd materiaal

• The Accountability Trap: zeer relevant en interessant artikel dat ook over het verschil tussen accountability en responsibility gaat.