DM-screen

The need for clarity

In the Netherlands we have this saying when we want to describe how we “translate” complex documents in esoteric language for a larger audience: “Jip en Janneke taal” (the language of Jip and Janneke). Jip and Janneke are the names of the two main protagonists in a series of  children’s novels by a great Dutch writer, Annie M.G. Schmidt. The series was written in the period between 1952 and 1957 and is still required reading for kids all over the world, since the series has been translated in a number of languages, including Chinese.

Anyway, Jip and Janneke language is the layman’s language or Plain English version. We as architects produce a lot of documents. Let a project manager, or any other role in the enterprise read those documents and they may exhibit a number of symptoms, most notably a irrepressible urge to fall asleep, or as a board member of an organisation I am involved in most eloquently cried out: “Disgusting! Really disgusting!”

The question is: do we, as architects, fall short in communication skills because of the esoteric nature of our documents?

I don’t think so. It is in the nature of our work that the models we use to get to grips with the complexity of our world are complex as well. We use special languages for them, and I for one am convinced there is no problem there, on the contrary.

I always illustrate my view of those complex models and the role they play in communication with another role I played in my youth, sometimes for days (and nights …) at an end: that of a Dungeon Master.

A Dungeon Master or DM is the game leader of a game called Dungeons and Dragons, in which characters play the roles of elves, gnomes or wizards in a mythical world. This world usually is created by the DM: he has a number of maps and a variety of tooling to create a tantalising and entertaining story. He has for example a number of dices with which stochasticity is introduced: does this monster appear now? does the wizard’s spell work? does the fighter win a fight?

The DM sits behind a screen that hides these apparels from the view of the players. He uses the representations of the complex world of the game to steer the game but the players are unaware of that. As they should be. They only know what the DM tells them their senses experience. In effect the DM constantly creates viewpoints that each character can use to visualise his or her place in the world at the particular point in time that the game is on.

This is exactly how I use my tools and models. They are never meant to communicate directly with the people I talk with (except when they are architects as well), but they help me to create the illusion to those people that I understand what they talk about, that I understand their world, their perspective, their concerns. And of course if there is a problem there, the problem lies with me, with my models with which I attempt to capture their world. Those are the viewpoints of course, and often these end up as documents or models as well. But they are not the architecture, and they should always have a prominent disclaimer that, no, this is not the architecture, this is the viewpoint for this particular stakeholder at this particular point in time. Because, yes, the architecture is much much more complex.

 

Abonneer op de nieuwsbrief

n-WORK-large570

Wat dóet een architect eigenlijk?

Ik kreeg de vraag gisteren tijdens een gesprek: wat heb je nu eigenlijk gedaan als enterprise architect bij die organisatie?

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?

Abonneer op de nieuwsbrief

Iedereen is een architect

Soms kom ik mensen tegen die zich introduceren met: “Ik ben een architect.”

Ik reageer vaak met: “Iedereen is een architect”.

Waarom?

Een architect is niet een label voor een bepaald type persoon. Nou ja, in de praktijk wel, maar dat zou niet zo moeten zijn. Wat voor soort persoon wordt gewoonlijk bedoeld met de term “architect”? Dat hangt er een beetje van af. Gewoonlijk is het “duur”, of “oud”, of zelfs “afgedaan”. Of het zou kunnen zijn: “bovenmenselijk slim” of “gebruik makend van esoterisch taalgebruik”. Soms is het “geen idee wat we met hem moeten, laten we hem een architect maken”. In agile teams zou het kunnen zijn “irrelevant” of “een bedreiging voor de sprint planning”. Dat krijg je wanneer je personen identificeert met labels, eigenlijk werkt dit met elk label. We hebben het zien gebeuren met “managers”. Het werkt trouwens twee kanten uit: mensen zien het label, niet de persoon. En de persoon (en dit is nog erger eigenlijk) ziet niet zichzelf, maar (soms langzaam maar zeker) gelooft zelf dat ze het label  is.

Iedereen is een architect, want het is een rol, een hoed zou je kunnen zeggen die je opzet in bepaalde situaties. Elke keer als je een probleem tegen het lijf loopt waar je een beslissing voor moet nemen, en waarbij je je realiseert dat de impact van jouw beslissing verder reikt dan de lokale invloedssfeer waarover jij invloed hebt of die door het probleem wordt bereikt, neem je die rol van architect op. Je moet nadenken over gevolgen, over afhankelijkheden, over rimpel effecten. Als ik zus beslis, moet het andere team dan aanpassingen doen in hun werk? Misschien niet, als ik zo beslis. Maar dan heb je kans dat ik zelf in de problemen kom, misschien niet meteen, maar in de afzienbare toekomst.

Misschien ben je een software tester, een software ontwikkelaar, of zelfs een junior in het team. Je bent misschien een project manager of een CEO. Jullie zijn allemaal, van tijd tot tijd, een architect. En jullie moeten allemaal, wanneer het nodig is, die rol weer loslaten en een andere hoed opzetten.

Zit je klem? Neem de houding aan van de architect. En dan realiseer je je plotseling dat je een hele batterij aan hulpmiddelen hebt om je te helpen met je beslissing: systeemtheorie, modelleertalen, mind maps, en modelleer paradigma’s. Je bent niet teruggeworpen op jezelf. En je moet je bovenal realiseren dat het nodig is buiten de gebaande paden te denken, en vaste perspectieven en paradigma’s los te laten. Vaak, als het niet altijd is, betekent dit dat je met anderen moet praten, met de architecten in hen, om je te helpen buiten die beperkende grenzen en comfortabele stokpaardjes te komen, zodat de beste oplossing gevonden kan worden. En als je die strategie eenmaal structureel toepast merk je dat die oplossing iedereen verrast, jezelf en anderen, door zijn elegantie en eenvoud.

En je realiseert je dat toen je nog dacht dat jij de architect was, jouw oplossingen complex en onmogelijk te onderhouden waren.



Abonneer op de nieuwsbrief

%d bloggers op de volgende wijze: