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


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


Everyone’s an architect

You may encounter people who say: “I’m an architect.”

I usually respond with: “Everyone’s an architect.”


An architect is not a label for a specific kind of person. Well in practice it is, but it should not be. What kind of person is associated with “architect”? Well, it depends. Usually it is “expensive”, or “old” or even “obsolete”. Or it might be: “superhumanly smart” or “using esoteric vocabulary”. Sometimes it is “don’t know what to do with him, let’s make him an architect.” In agile teams, it might mean “irrelevant”, or “threat to sprint planning”. That’s what you get when you identify persons with labels, in fact any label will do the trick. We’ve seen it with “managers”. It works both ways: people will see the label, not the person. And the person (this is even worse) will not be herself, but actually (sometimes gradually but inevitably) believe she is the label.

Everyone is an architect, because it is a role, a hat you might say that you put on in certain situations. Any time you encounter a problem where you need to make a decision, and you realise that the impact of your decision reaches beyond the local sphere of influence that you inhabit or that the problem covers, you are adopting the role of an architect. You need to think about consequences, about dependencies, about ripple effects. If I decide thus, will the other team need to modify their work? Maybe not, if I decide otherwise. But then it may very well be I will shoot myself in the foot, maybe not now, but in the near future.

You may be a software tester, a software developer, even a junior on the team. You may be a project manager or a CEO. All of you are, from time to time, an architect. And all of you need to drop the role, switch hats, when needed.

Caught between a rock and a hard place? You need to adopt the architect’s stance. And suddenly you realise you have an entire battery of tools at your disposal to help you with your decision: systems theory, modelling languages, mind maps, and modelling paradigms. You are not alone out there. And you need to be acutely aware of the need for thinking outside the box, for letting go of any fixed perspective or paradigm. Often, if not always, this means you need to talk to others, to the architect in them, to help you think outside your restrictive boundaries and hobby attachments, for the best solution. And if you use this strategy you may find that the solution will surprise you and everyone involved, for its elegance and simplicity.

And you realise that back in the days when you thought you were the architect, your solutions were convoluted and complex and impossible to maintain.

Abonneer op de nieuwsbrief

%d bloggers like this: