Everyone’s an architect

Dit is de Engelse vertaling van het artikel: “Iedereen is een architect”.

Sometimes you encounter people who say: “I’m an architect.”

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

Why?

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 people 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. 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. 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. Furthermore, if you use this strategy you may find that the solution will surprise you and everyone involved, for its elegance and simplicity.

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