Daar zit je dan met je goede gedrag. Je hebt een duidelijke visie die aansluit bij de strategie van de organisatie. Je kan deze visie uitleggen op allerlei niveaus. Iedereen knikt en beaamt je verhaal en er is louter begrip. Goed idee, dit moeten we gaan doen, wordt je verteld. Maar waarom doet dan niemand wat je voorstelt? Waarom voel je je een politieagent die moet handhaven om zijn visie werkelijkheid te laten worden?
Vanochtend zat ik aan tafel met software-, business-, solution-, project-, domein-, infrastructuur- en enterprise-architecten. Voor mij een unicum! Nog nooit zat ik in één ruimte met zoveel ‘soorten’ architecten.
De heren architecten – op de een of andere manier ontmoet ik nooit een vrouwelijke variant – hadden het afgelopen jaar hard gewerkt aan ‘de architectuur’ van de organisatie. Dit visiestuk is vertaald naar een groot aantal kaders om de organisatie de ‘goede kant op te sturen’ of ‘de juiste koers te laten varen’, afhankelijk van of je je een schip voelt of iets met wielen. De kaders geven richting aan vragen als: hoe gaan wij als bedrijf om met integratie, security, cloud, big data, et cetera.
De heren lieten me kort zien wat ze geproduceerd hadden en ik moet eerlijk zeggen dat het er indrukwekkend uitzag. Het was het resultaat van een heel jaar lang polderen, maar nu staat er dan eindelijk een gedragen architectuur.
Alhoewel, gedragen?
De architectuur wordt gedragen door de architecten of in elk geval het deel van de architecten dat bij mij aan tafel zat. Maar goed, zij vonden dat ze hadden gedaan wat er van ze verwacht werd, namelijk kaders geven en het was nu aan de organisatie om binnen deze kaders te gaan werken. Of zoals ik het vaak omschrijf, binnen de lijntjes te gaan kleuren.
Veel workshops, presentaties en verstuurde documenten verder kleurt de organisatie nog steeds buiten de lijntjes en wordt er zelden binnen de gestelde kaders gewerkt. De oorzaak volgens de architecten? De organisatie, die de korte termijn altijd laat voorgaan op de lange. Hierdoor is er geen tijd of eigenlijk prioriteit om het in één keer goed te doen. ‘Ook ontbreekt het aan governance’, riep één van de architecten aan tafel, ‘Het niet volgen heeft geen directe consequenties voor de projecten en de teams.’
Het begint met begrip
Voor de meeste architecten is dit een herkenbaar probleem of uitdaging, net hoe je het ziet, die de essentie van organisatie verandering raakt. Hoe krijg ik een afdeling, groep of individu zover dat ze mij of in dit geval mijn visie, kaders of ideeën volgen? De oplossing hiervoor is eenvoudig: je moet hiervoor alleen je eigen doelen even in de ijskast zetten. In mijn artikel wie wil er verandering leg ik het uitgebreid uit, maar het komt neer op het volgende:
Let goed op! Het begint met begrip, maar dan niet begrip van de visie die jij hebt, maar van diegene die je wilt meenemen. Maak de architectuurkaders duidelijk vanuit het perspectief van het team of het individu. Blijf niet jouw beeld als architect herhalen, maar ga naar het team om samen oplossingen te bedenken binnen de geldende kaders. Verkoop je visie en leg deze vooral niet op. Zo creëer je een natuurlijk draagvlak voor je ideeën en neem je ze mee in de voordelen van het werken onder architectuur. Een ontzettend eenvoudige en effectieve benadering, door samenwerking creëer je draagvlak voor je eigen ideeën.
Niet enthousiast
‘Maar dat is geen onderdeel van onze rol’, riep de volgende architect aan tafel. ‘Wij geven richting en de organisatie volgt. Dat doen architecten. En we hebben het vaak genoeg uitgelegd, en nu moeten we de teams ook nog bij de hand nemen? Nee, daar zie ik niks in. We moeten de governance aanscherpen zodat er afgerekend wordt met diegene die niet doen wat wij voorschrijven.’
’Oké,’ zeg ik dan, ‘als samenwerken geen optie is, dan geven we iedere architect een bonnenboekje en politiepet.’
Nog steeds reageert niemand aan tafel enthousiast. Zowel mijn oproep om als verkoper op te treden als om politieagentje te spelen, wordt met ergernis ontvangen. Ik krijg het gevoel dat ze niet echt blij meer zijn met mijn komst. Dat is dan weer het nadeel van consultant zijn: ook ik moet mijn ideeën verkopen.
‘Vanuit waar ik sta, hebben jullie ruwweg twee opties. Of je creëert draagvlak door de samenwerking op te zoeken met de teams of je legt op. Maar aangezien jullie niet de autoriteit hebben om te handhaven, lijkt me dat laatste nogal frustrerend.’
Eén oplossing
Eigenlijk is er maar één oplossing. Ook al heb je de autoriteit om te handhaven, dan nog zou ik zeggen: verkoop je visie dusdanig dat nut en noodzaak duidelijk worden en leer de organisatie hoe ze oplossingen binnen de gestelde kaders kunnen ontwerpen door dit samen te doen.
Ik weet het, anderen begrijpen, kost energie, maar is een essentieel onderdeel van je werk als architect. Als je alleen een visie hebt die niemand volgt dan voeg je helemaal niks toe. Sterker nog, als je vervolgens ook nog de flow van werk gaat frustreren door als politieagentje op te treden, onttrek je zelfs waarde aan de organisatie.
Visionair én verkoper dus. Dat had niemand je vertelt toen je begon als architect.
Ook de nadruk die er tegenwoordig ligt op en de tijd die wordt besteed aan visievorming is te groot. Het gros van de architectuurdocumenten die ik onder ogen krijg, zijn over organisaties heen voor tachtig procent hetzelfde. De overige twintig procent kost vaak tachtig procent van de tijd omdat iedere architect weer zijn eigen voorkeur heeft. Vaak is er geen goed of fout, alleen een bepaalde voorkeur en is de organisatie meer gebaad bij een duidelijke keuze dan een lang traject om iedereen op één lijn te krijgen.
Visie verkopen
Terug naar het onderwerp van deze blog: hoe krijg ik als architect nu mijn visie verkocht?
Veel organisaties gebruiken op dit moment scrum, dus ik gebruik scrum dan ook als voorbeeld. Vooral ook omdat er binnen scrum een perfect moment is waarop architecten kunnen aanhaken. Dit moment is de refinement, het proces waarin een idee of story – zoals het in scrum heet – duidelijk genoeg wordt gemaakt zodat het team er zelfstandig in de sprint mee aan de slag kan. Onderdeel van het duidelijk of ready maken van stories is het aandragen van relevante architectuurkaders. Het team kan dit vaak niet zelf omdat ze niet de benodigde kennis hebben.
Hier heeft de it-architect een belangrijke rol door fysiek aansluiting te vinden tijdens de refinement en te begrijpen wat er van het team gevraagd wordt. Hij kan dan samen met het team binnen de kaders een oplossing uitwerken. Zo creëer je draagvlak door samenwerking en begrip. Of je koopt een politiepet, een bonnenboekje en schrijft bonnen – die niemand gaat betalen.
Het type architect wat beschreven wordt is (helaas) herkenbaar. Ik wil ze nog wel eens classificeren als “powerpoint-architect” of “ivory-tower-architect”.
Dat wat hun op papier bedenken om diverse redenen praktisch niet uitvoerbaar is, is niet hun probleem. Immers, zij zijn de architect, en weten alles beter.
In de bouw-sector is “architect” een beschermde titel, wat in zoverre kan helpen dat je weet wat je kan en mag verwachten van een architect. In de ICT mag iedereen zich architect noemen, waarbij je jezelf zelfs nog kunt opwaarderen naar senior-architect. En dan maak je kennis met zo’n architect, blijkt het een snotneus van 30 te zijn die nog maar net droog is achter zijn oren.
Maar, hij is de architect, dus hij weet het 🙁
Wat dat betreft ben ik, net als de auteur, wel gecharmeerd van de architecten die aansluiting zoeken bij de ontwikkelteams in o.a. de refinements. Het schept de ruimte voor interactie. Zeker wanneer de architect open staat voor de input vanuit het team, en probeert te begrijpen wat er speelt en waarom dingen wel/niet/anders zouden moeten dan kan er zowaar een synergie ontstaan.
Daarvoor hoeft de architect geen auto’s te verkopen, maar gewoon een stukje menselijkheid te tonen in plaats van te dicteren
Geweldig, die vergelijking met autoverkoper :
Deze visie is nog bijna niet gebruikt, draait als een zonnetje en past helemaal bij u.
Als u hier nou even tekent..
In het bedrijfsleven heeft een rol geen bevoegdheden als men vindt dat de rol niet zo belangrijk is. Geen nut en noodzaak van boven. En beneden. Een externe consultant zal dat wel duidelijk maken. Met fictieve boekjes en petten.
Architecten worden stil als ze zich dat realiseren.
En daarom bouwt de metselaar het dragende muurtje, daar waar de PL vindt dattie moet komen. Omvallen inclusief dependencies is prima, zolang het niet binnen project scope gebeurt. Dit geeft korte time-to-market, lagere kosten dus betere ROI. In computable lezen we dat bedrijven daar wel oren naar hebben.
Hoewel herkenbaar, heb ik wel wat andere beelden en ideeën hierbij.
Ten eerste; architect van wat?
Infrastructuur? Software? Netwerk? Integratie? Cloud migratie?
Eerst even wat analogie met klassieke architecten in de bouw. Daar is een architectuur altijd een project! De architect heeft veel kennis van de gebruikte materialen en is actief betrokken bij de realisatie van het project.
Logisch dus dat architecten in de IT betrokken zijn bij de uitvoering. Als het goed is heeft de architectuur ook zijn akkoord gekregen van de opdrachtgever. Wat je in de praktijk vaak ziet is dat proces niet zo gelopen is als met het bouwen van dingen, dit is daarmee dus ook een verklaring voor het fenomeen dat in het artikel beschreven wordt.
Als je als architect je architectuur (van wat dan ook) moet verkopen aan andere mensen, dan is er ergens al iets mis gegaan.
Mijn ervaring als architect is vooral op het gebied van software ontwikkeling mogelijk in samenhang met de plek waarop de software wordt gebruikt en deployed (virtuele servers, externe cloud diensten). De opdrachtgevers zijn vaak geen IT-ers dus daar hou je meer een verkooppresentatie van het idee. Maar als architect van software moet in wel echt betrokken zijn in de materie die gerealiseerd wordt. De technieken, de talen, het eco systeem en de huidige trends.
Wat ik merk in de praktijk is heel sterk het “not invented here” syndroom. Daar ben ik zelf ook debet aan. Als iemand een ander idee heeft dan ik, dan kost het me erg veel moeite om het idee van de ander te adopteren. Daarom werkt het ook niet als je een berg specificaties bij de ontwikkelaars neerlegt. En ook hier ligt een architectuur les. Je moet met je architectuur rekening houden met de bestaande cultuur en workforce (of een hecht team hebben die je door de transitie heen navigeert). Je hebt een visie en idee en samen met de uitvoerders zul je in overeenstemming moeten komen en dus ook mogelijk je eerste plan moeten laten varen of aanpassen om de opgedane inzichten.
Hoe dan ook. Als architect staat je ook met de poten in de modder te helpen het project te realiseren. Pas als je samen bouwt, samen werkt aan de successen zal het project een succes blijken.
Architectuur gebaseerd vooral op basis principes en richtlijnen is geen architectuur.
Toen ik in de jaren ’80 bij AMBI S.3 wat leerde over projectmanagement, hoorde ik dat “commitment van het management” zeer belangrijk is voor het slagen van het project. Dat is het verkoopverhaal.
In de jaren ’90 maakte ik kennis met het “reviewen” van documenten; in PRINCE2 heet zoiets een “quality review”. Het idee is dat je als auteur (hier: architect) je verhaal voorlegt aan mensen die ermee moeten werken. Deze mensen komen met opmerkingen en aanvullingen. Verwerk deze in het document en doe nog zo’n review. Als ze zien dat je al hun opmerkingen serieus hebt opgepakt en verwerkt in het nieuwe document, dan beschouwen ze het als hún document en heb je meteen commitment van de betrokkenen.
Dan doen ze uit zichzelf wat in het document staat; ze handelen in de geest ervan. Heel leuk om mee te maken.
De ergste die ik mee gemaakt heb was een ‘enterprise architect’, deze had ‘carte blanche’ binnen de organisatie (semi overheid). Wat heeft die man een schade aangericht en inderdaad niet luisteren naar de techneuten op de werkvloer. Binnen het jaar was het budget op…
Ontzettend leuk stuk en zeer herkenbaar.
Wat ik merk is dat veel architecten blijven hangen in het beschrijven van de architectuur.
Dat komt ook doordat bijna alle tools en methodieken sterk beschrijvend zijn. Het idee dat als je maar kaders, principes en richtlijnen hebt, dat het dan wel goed komt is zinloos.
Even wat reageren op de reageerders, Henri, die bouwarchitect is de architect, maar eerder een enterprise ict architect (waar dus die al die architecten inzitten). We hebben helaas naast de ICT, ook iets als Finance, HRM, primaire bedrijfsprocessen (organisatie afhankelijk), etc… Daar zitten hele werelden achter, waar ook een gemodelleerde werkelijkheid bestaat (al noemen ze dat anders), dus ook in die werelden is architectuur aanwezig. De echte enterprise architect zal op zijn minst op het hoogste niveau de missie, visie, kernwaarden, strategie, doelen van een organisatie moeten vertalen naar de rest van de organisatie, wat betreft de te hanteren principes, kaders en richtlijnen. Dus die enterprise architect (in mijn bescheiden mening) is de stads en bouwarchitect in een. De context waarin de ICT leeft is een onderdeel van het geheel. Daar moet samenhang in zitten.
Het artikel beschrijft nu juist het andere aspect van het werk van de architect. Vaak denken architecten dat alleen die kaders, richtlijnen en principes beschrijven met een landschaps tekening (soms nog met een procesarchitectuur erbij) hun werk is. Ja dat is zo, maar als je al die platen en teksten nooit gebruikt, is het zonde van je tijd. Als iemand mij vraagt om een architectuur te maken of ontwikkelen voor “iets” ga ik eerst eens in gesprek wat precies zijn vraag is (en de vraag achter zijn vraag die daarachter). Het is vaak triest als ik vraagstellers van verschillende pluimage voor me krijg die vanuit een zo’n beperkt en weinig gelaagd abstractieniveau naar hun te kleine context kijken, dat ik me soms afvraag, of de op zich goedbedoelende vraagsteller denkt dat hij alleen op de wereld leeft.
De rol die de architect nog meer heeft is architectuur bedrijven, dus uitdragen in projectvorm en integraal. Integraal omdat je de stippen op de horizon kent, maar met name in projecten, zodat als die platen en teksten een bijdrage gaan leveren voor de plek en vorm van het project. Dus niet dit project botst met principe X en richtlijn Y, maar joh, als je dit gaat doen, dan komen we in de knooi met je collega drie stoelen verder op, die ook zijn werk wil blijven doen. Daarom NOOIT communiceren met abstracte Archimate platen of een procesplaat met 8 swimminglanes. Daar gaat een gebruiker of manager vanuit de lijn nooit op reageren. Gebruik vooral platen die deze afdeling zelf kent en vertaal deze naar die Archimate platen en procesarchitectuuromgeving.
Als twee mensen elkaar willen begrijpen moeten ze elkaar “verstaan”, dat begint met taal, maar ook met houding en gedrag. En dan wordt het lastig, want volgens mijn vriendin (mag ik zeggen hoor) zijn ICT-ers complete autisten. Bij haar is iemand die 3ms dagdroomt overigens al autist. Maar goed, on topic, dat verkopen van je visie en dat zieltjes proberen te winnen is compleet 180 graden op de gemiddelde grondhouding van vele niet ICT-ers. Overigens vaak zijn de reden van weerstand, helemaal niet gelegen in de inhoud, maar hebben te maken met baanzekerheid, werkinhoud en ego/macht. Dan heeft het weinig zin te drammen met de inhoud en er nog maar eens een plaat tegenaan houden, maar juist door de kern door te dringen, wat de nader beweegt. Daar op acteren is dan de truc. Je moet dat wel kunnen. Probeer dan iemand in je umfelt te gebruiken die daar veel beter in is. Je kan beter iemand voor je laten werken, dan zelf blijven aanmodderen.
Ik merk dat ik al weer enorm architectengedrag hebt vertoond, door deze lap tekst.
Kortom: architectje spelen is architectuur beschrijven en bedrijven!
“Als je een schip wil bouwen, roep dan geen mannen bij elkaar om hout te verzamelen, het werk te verdelen en orders te geven. In plaats daarvan, leer ze verlangen naar de enorm eindeloze zee.” – Antoine de Saint-Exupéry
Er zit namelijk een verschil tussen organisatorisch draagvlak en maatschappelijk drijfvlak als je niet rekening houdt met de werkelijke kaders van Enterprise Architectuur. Voor alle duidelijkheid, met de term enterprise wordt het ondernemingsniveau bedoeld waarbij alle divisies overeengekomen doelen of principes nastreven. Het refinement dat ik nog opmerkelijk vaak mis bij alle Agile/scrum teams die niet op een hoger organisatieniveau dan één afdeling kunnen acteren gaat simpelweg om de enterprise afstemming in de keten.
En nieuwe paradigma van DevOps gaat dit niet oplossen als er geen besef komt over de metadata die nu nog altijd te vrijblijvend ingevuld wordt waardoor de ‘ruilverkaveling’ in het poldermodel tot een semantische uitdaging in het logische koppelvlak zorgt. Betreffende genoemde Paretoprincipe, Vilfredo Pareto stelde in het begin van vorige eeuw vast dat 80% van de bezittingen in handen was van 20% van de bevolking. Ondertussen is 88% van de IT geïmpelementeerd zonder enige architectuur waardoor we een probleem hebben met alle ongestructureerde data.
Een architect is dus niet een verkoper of een visionair maar een vertaler van de metadata welke meer voortschrijvend zou moeten zijn om de onderhoudbaarheid van oplossingen te verbeteren zodat we niet net als Eskimo’s en Engelsen 20 woorden voor sneeuw hebben die 80 verschillende soorten betekenissen in de vertaling kennen.
een bedrijf bouwen op verlangen naar eindeloze data.
Maar wel voortschrijvend, anders doen ze het niet. Of verkeerd.
Das enterprise architectuur volgens Ewout.
Net als bij Utopia op tv.
Het refinement van zelfsturende teams met TOGAF profielen 🙂
Bouw architecten rekenen met Newton.
IT architecten (horen te) rekenen met Murphy.
http://dilbert.com/strip/2017-07-18