Artikel

Architectuurrollen vervangen door domein-experts

We moeten af van zelfgecreëerde architectuurrollen. De huidige verdeling in architectuurrollen is grotendeels gebaseerd op de behoefte aan persoonlijke groei en het vergaren van macht. Er zijn bedrijven waarbij de definitie van deze rollen een officiële status hebben verkregen. Een duidelijk onderscheid tussen de verschillende soorten architecten bestaat momenteel echter niet.

Een verdeling in architectuurrollen heeft ook deels te maken met de verschillen in de omvang van het probleemgebied. Enterprise architecten kijken vooral naar het complete landschap, terwijl solution architecten werken naar een concrete oplossing (hopelijk gerealiseerd binnen een jaar).

Een ander reden voor het ontstaan van de verdeling is dat architectuurwerk niet meer slechts een middel, maar een doel op zich is geworden. Onbewust ontstaat een kunstmatige behoefte naar meer organisatorische structuren door de complexiteit die men zelf creëert. Deze complexiteit ontstaat doordat men ver in de toekomst wil kijken en “onder architectuur” ontwikkelingen wil uitvoeren. Wanneer we ontdekken dat de omgeving zich niet aan architectuur onderwerpt, dan introduceren we nog meer structuren om ook de veranderingen zelf in bedwang te houden. Mocht je organisatie veel architecten hebben die vooral met bewaking bezig zijn en strijd voeren met projecten die niet onder architectuur werken, dan heb je helaas al last van dit probleem.

Grote afstand tussen mensen

Een bijzonder vervelend effect van de verscheidenheid aan architectuurrollen is de grote afstand tussen CIO's / enterprise architecten en engineers / architecten op de werkvloer. De omgeving ervaart deze structuur vooral als ballast. Een voorbeeld is de goedkeuring van een PSA (“Project Start Architectuur” document uit DYA). Het is een document dat meestal door alle lagen goedgekeurd moet worden. De architecten in de “hogere lagen” hebben dan weinig kennis van de concrete projectdoelen en afwegingen. Toch geven ze hun goed- of afkeuring op basis van beperkte kennis. Deze goed- of afkeuring is frustrerend voor een project: bij een goedkeuring is het wijzigen een moeizaam proces en bij afkeuring worden eenzijdige argumenten gebruikt die vaak risico- en kostenverhogende gevolgen hebben.

De architect met alle kennis in huis bestaat niet

Er bestaat geen architect met de volledige kennis van alle benodigde aspecten op een bepaald niveau. In de organisatie, waar het architectuurwerk goed op orde is, spreken we eerder van domein-experts. Dit zijn mensen die kennis op één of meer gebieden afdekken. Dit kunnen technologische domeinen zijn (zoals enterprise, Java, integratie, beveiliging), functionele domeinen (processen, informatie) en organisatorische domeinen (zoals de inrichting van een ontwikkel- en architectuurproces). De typisch kennisdragende mensen hebben wit haar en een witte baard, en werken al zo lang bij het bedrijf dat zij min of meer alles weten over de bedrijfssituatie ansich :-). Welke naamgeving we voor deze mensen kiezen, is irrelevant en volledig situatieafhankelijk.

Is de architect de eigenaar van architectuur?

De bestaande architectuurrollen impliceren bepaalde verantwoordelijkheid en eigenaarschap over een bepaald architectuuraspect. Bijvoorbeeld, een informatiearchitect is eigenaar van de gegevensmodellen. De eigenaarschap over architectuur is zeer gewild gezien de zeggenschap over erg veel IT aspecten, maar zonder echte verantwoordelijkheid wanneer een project door onkunde faalt. Een IT architectuur is tegenwoordig een organisatorisch fundament die je als organisatie gezamenlijk ontwikkelt en niet aan een kleine groep mensen wil overlaten.

Ook Scott W. Ambler spreekt vanuit Agile optiek over een “architecture owner” als een tegenhanger van een “product owner” (SCRUM terminologie). Het probleem van deze naamgeving is dat de basis van het Agile gedachtegoed hiermee ondermijnd wordt. Het label "architecture owner" impliceert een persoon of specifieke groep mensen die zelf verantwoordelijkheid voor een architectuur dragen, zoals een “product owner” de verantwoordelijkheid voor het eindresultaat van een product of dienst draagt. De verantwoordelijkheid voor architectuur wordt op deze wijze van het team ontnomen. Hoewel Ambler niet beoogd heeft om verantwoordelijkheid te ontnemen, is het wel een effect van het label "architecture owner".

Bovendien is architectuur een belangrijke, echter slechts randvoorwaardelijke, discipline en heeft architectuur een indirecte business relevantie. Op het moment, dat we veel waarde gaan hechten aan architectuur als product door het onderkennen van een “architecture owner”, wekken we op zijn minst het gevoel dat we architectuur als eindproduct zelf moeten opleveren. Alle architectuurproducten zijn in principe “waste”, mits ze duidelijke randvoorwaardelijke waarde voor het eindproduct hebben.

Poppendieck (“Lean Software Development, An Agile Toolkit” – Tool 15: Leadership) spreekt van een “master developer”. Het is iemand met een verdiend respect gezien de hoeveelheid kennis van zowel techniek als de klantbehoefte en de leiderschapkwaliteiten. Deze persoon maakt onderdeel van het team en het team draagt nog steeds de verantwoordelijkheid voor architectuur. De typisch noodzakelijke architectuurproducten hebben allemaal met communicatie te maken. Bijvoorbeeld, een duidelijke en beknopte visie in vorm van een video-opname kan een grote toegevoegde waarde hebben.

De nieuwe architect is een facilitator / coach / master developer of domein-expert

Als we geen architectuurrollen onderkennen, wie houdt zich dan met architectuur bezig? We kennen in essentie 4 architectuur "bezigheden": initiëren, faciliteren, creëren en bewaken. De bekendste zijn het creëren en bewaken. Deze activiteiten zouden het werk van teams moeten zijn. Met teams worden hier SCRUM of projectteams bedoeld die een bruikbare eindproduct ofwel directe business value creëren. De teams worden ondersteund door de materie-experts ofwel de domein-experts zoals eerder genoemd. Deze experts kunnen ook onderdeel uitmaken van het team zelf wat de gelijkwaardigheid met de overige teamleden impliceert.

We houden dan het initiëren en faciliteren over. Het initiëren kan in principe gestart worden door iedereen die een goed idee heeft. Het faciliteren vraagt echter om wat specifieke kwaliteiten, namelijk leiderschapskwaliteiten (zie "De Dienende Architect"). In dat artikel spreken we van iemand die ervoor zorg draagt dat mensen samenwerken en aandacht hebben voor architectuur. Deze kijk op de architectrol is in lijn met Poppendieck’s visie.

Weg met de architectuurrollen

Hiermee kantelen we de structuur van de verschillende architectuurrollen naar waar het team, dat directe waarde levert, centraal staat. Domein-experts en de faciliterende architecten bieden ondersteuning aan de teams. Ieder afzonderlijk of als team levert expertise en inzicht vanuit een eigen perspectief dat situatieafhankelijk is. Deze "situatieafhankelijkheid" is cruciaal gezien de praktijk van overmatig gebruik van verschillende architectuurrollen zelfs als last worden ervaren, in plaats van waarde toevoegen. Een manier om te ontdekken of een architect overbodig is, is door het team te vragen wat zijn/haar waarde is in de levering van het eindproduct en daarmee de business waarde. De voorwaarde is wel dat de betreffende team zich committeert en echt verantwoordelijk voelt voor de kwalitatieve oplevering van het eindproduct. Er wordt hiermee onderscheid gemaakt tussen diegene die bijdrage levert in inzicht, kennis en ervaring vanuit architectuurperspectief en mensen die daadwerkelijke architectuurbesluiten nemen. Dat zijn namelijk bij voorkeur de teams zelf.

Maar, wie bewaakt de strategische ofwel ondernemingsdoelen?

In de afgelopen eeuw hebben we in de organisatiekunde ontdekt, dat een gezamenlijke besluitvorming, vanaf de werkvloer - voor zover mogelijk - veel effectiever is dan een van bovenaf opgelegde weg en besluit. Het vraagt wel een ander type leiderschap: een dienend of coachend leiderschap.

Het is dus de taak van de dienende architect om samen met alle betrokkenen zorg te dragen voor het ontstaan van een duidelijke architectuurvisie die richtingbepalend is. De praktijk wijst uit dat de visievorming vaak voorbehouden is aan de architect zelf, maar er zijn legio mogelijkheden om de visie ook gezamenlijk op te stellen ("The Product Vision Box"). Een architect met een visie inspireert teams en wint hen voor deze visie. Er is dus geen sprake van vulling van grote enterprise architectuur modellen waaruit sturing ontstaat en waarnaar iedereen zich dient te gedragen, of ze het nu begrijpen of niet.

Beste architecten, we moeten van zelfgecreëerde producten en rollen af en het vervangen met aandacht voor het eindproduct, de gebruiker en de stakeholders.

Categorie:   
Auteur(s)
afbeelding van viktorgrgic
Viktor Grgic
LeanArch b.v. - Eigenaar

Viktor Grgic is een zelfstandige Agile/Lean IT architect die in zijn werk als software architect Agile principes hanteert. Viktor heeft in zijn loopbaan als architect vele software projecten geleid. Onder andere leiding gegeven aan architectuurteam van Nieuw Handelsregister bij Kamer van Koophandel, lead SOA / integratie architectrol vervult bij ProRail en vele architecten gecoacht in hun werk. Viktor's werk kenmerkt zich door sterke focus op de mensen, eenvoud in alles, risico's onderkennen en realisme in wat met software mogelijk is. Viktor's expertise is met name service-orientatie / SOA, EAI, domein modellering, ontwikkelstraten, ontwikkelmethodieken en systeemontwikkeling van met name JEE systemen.

 
Reacties
Michael Homeijer op vrijdag 13 augustus 2010 11:03

Hoi Victor,

Dat er iets moet veranderen is wel duidelijk. Naast het veranderen van het speelveld zou je echter ook kunnen kijken hoe je in dit speelveld succesvol resultaten kan opleveren.

Zouden de rollen die je noemt alleen uit eigenbelang ontstaan zijn of zouden de verschillende architecten daadwerkelijk belangen van een organisatie vertegenwoordigen? Dat er bij mensen meer belangen blijkt onder andere uit http://www.hrpraktijk.nl/nieuws/nieuws/eigenbelang-gaat-boven-teambelang....

Architecten vertegenwoordigen verschillende belangen in een organisatie en bieden een operationele organisatie een vorm van continuïteit. Een projectteam is meer gericht op tijdelijke samenwerking en oplevering van deliverables en heeft daarin een eigen belang. Al deze belangen creëeren een speelveld waarbinnen een project een succesvol resultaat probeert bereiken.

Valkuil bij het afschaffen van de rollen die je schetst, zijn volgens mij het feit dat jij als "dienend architect" of als projectteam een deel van de belangen vertegenwoordigt en deze tegelijk ook objectief probeert af te wegen tegen andere belangen. Daarnaast kan je zoals je aangeeft niet verstand hebben van alles en zijn de verschillende architecten die je noemt erg geschikt om je visie op het eindresultaat van een project te toetsen en binnen kaders te plaatsen.

Zou je op dezelfde manier binnen een organisatie zonder projectmanagement, programmamanagement en portfolio management kunnen, omdat je een zelfsturend team hebt en de onderwerpen zelf met je omgeving kan afstemmen?

De toevoeging "dienend" is voor mij de sleutel; of het nu vanuit architectuur, projectleiding of business analyse is. Om een goed eindresultaat te bereiken moet je je ervan bewust zijn dat er belangen spelen op meerdere vlakken, niet alleen met betrekking tot architectuur, en moet je ook op die vlakken kunnen toetsen, aanvullen, belangen zichtbaar maken en eventueel ingrijpen.

Waar belangen botsen doet het pijn, zie ook http://www.automatiseringgids.nl/artikelen/2010/18/column--doet-het-pijn.... Sleutel van een succesvol project is de beleving van pijn bij de juiste personen zichtbaar te maken of te laten voelen zodat zij de keuzes en prioriteitsstelling die een project maakt begrijpen en eventueel kunnen beïnvloeden of verdedigen.

Met vriendelijke groet,
Michael Homeijer

Viktor Grgic op zaterdag 21 augustus 2010 21:20

Hey Michael, leuk een reactie van jou te lezen. Hier heb je mijn antwoord.

Het is wel interessant iets al die belangen van mensen. De belangen zijn uiteindelijk uitingen van bepaalde gevoelens en emoties die mensen hebben. Iemand vindt dat iets belangrijk is, vanuit zijn/haar perspectief voor de organisatie, maar meestal voor zichzelf als een werknemer. Ik denk dat we een onderscheid moeten maken tussen persoonlijke emotionele aspecten die wezenlijk belangrijk zijn ten opzichte van waar een organisatie echt om draait: het leveren van producten of diensten aan een klant en voor een IT-er aan de gebruiker van het systeem. Gezamenlijk creëer je de business value. Wanneer een IT-er alles vanuit de perspectief van gebruiker bekijkt, dan blijken alle andere belangen secundair. We hebben de afgelopen jaren erg veel rollen verzonnen waardoor uiteindelijke gebruiker steeds minder zichtbaar is en andere belangen krijgen bizar genoeg hogere prioriteit.

Essentie van de boodschap is dat we de weg terug naar de gebruiker moeten zien te vinden, waarbij de muren, rollen, procedures, enz. uit de weg gaan. De architectrollen is een voorbeeld, maar het geldt inderdaad ook voor project, portfolio, en programmamanagement.

Tegelijkertijd maak ik een duidelijke onderscheid tussen disciplines en rollen. Architectuur, projectmanagement, enzovoort zijn essentiële disciplines. Het probleem zijn allerlei rollen waarvan we denken dat we ze nodig hebben, maar die vaak gebaseerd zijn op bedachte concepten die in essentie hol zijn. Door de complexiteit aan rollen is ook lastig onderscheid te maken tussen essentiële disciplines en disciplines die door vele rollen zijn ontstaan. Deze vicieuze cirkel is de oorzaak van ontstaan van complexe miljoenen verslinderende IT organisaties die bitter weinig opleveren en systemen nauwelijks in beheer kunnen houden. Deze organisaties hebben inderdaad een enorme speelveld aan belangen waarbij architect, net zoals projectmanager en heleboel anderen, in het midden proberen te staan. Tegenwoordig zegt ieder IT-er dat hij/zij tussen de business en IT staat; ofwel in de weg. Ze zijn vaak zelf een onnodige belanghebbende geworden.

We hebben geen mensen nodig die iemands belangen verdedigen, we hebben mensen nodig die met elkaar samenwerken om IT-producten aan de gebruikers te brengen en beheren. Daarvoor hoeven we geen ingewikkelde belangenspel te spelen, maar simpelweg elkaar helpen met echte kennis. Ik heb namelijk geen ontwikkelaar gevonden die kennis van een expert niet op prijs stelt. Het probleem zit in de mensen die in de naam van een rol van alles mogen opleggen (in de naam van andere belanghebbende) wat ontwikkelaars niet begrijpen.

Een psychologische bezigheid van belangen, emoties ofwel ego's is belangrijk, maar er zijn ook shortcuts te nemen zonder verdwaald te raken in het spel. Deze heten teamgeest, gelijkwaardigheid, gezamenlijke besluitvorming en dienstbaarheid.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.