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

Architects

Everyone’s an architect

You may 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 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

RACI for Enterprise Architecture

Companies usually have installed an executive hierarchy. This hierarchy is one that has been evolved and tested over a long period of time. We have reasonably clear ideas about what it should establish. People have one boss, who more or less decides about their roles, assesses their performance, and decides what to do when the performance is not up to standards.

A competence hierarchy is usually not so well established in a company, if it is present at all. What do I mean with a competence hierarchy? I mean a shadow hierarchy with people not in charge in an executive way, not dealing with money, functions or salaries, but one based on expertise, competence in doing the job well. The American model of organisations has been adopted in many countries, and that model seems to emphasise that management is key. To become a manager is to be successful in what you do. The natural growth path for people is forced in the direction of executive responsibilities, which we call in this article accountability. This creates a continuous drain of responsible competences. Also in most organisations the reward system is not oriented towards responsible competences. It is considered to be part of the job description to do your job well. It is completely overlooked that competent people add value to an organization that is much more than any reward system I know can cope with. A competent person is not, say, 10% more productive than an average person, but research has shown that the margin is an order of magnitude bigger, in the 100 percents. Were organizations to deal with this, it would mean that wages for responsible roles could very well be much higher than for accountable roles. I always try to make executives realize this fact, and deal with the consequences. Neglecting the value of competent people in your organization will inevitable lead to a brain drain.

In the Netherlands (and internationally) a model has been used in many organizations that expresses this rather elegantly. It is called the RACI matrix. Below you can see an example in the nautical domain.

RACI_Nautical

Example RACI matrix (nautical)

I will not enter into an explanation about the consulted and keep informed aspects but want to focus in this blog on the responsible and accountable aspects.

Responsible is what I mean with competence hierarchy. Someone is responsible because he or she has the competence to do what he does, or to say what he says. This competence can be based on experience, or on the proper education, or preferably a combination of both. The competence is not one that is exercised in an executive manner: the work being done is usually the result of an order issued by an accountable role, because persons with that role have the resources (financial or otherwise) to allocate.

Most companies have no competence hierarchy installed. People do their jobs and report the results one way or another to an executive role, an accountable role. The problem of course is twofold: both the accountable and responsible roles need to be submitted to a qualitative assessment and who is going to provide that? An accountable role is not without competence, as is a responsible role, although the latter is more clearly based on competence. If the only hierarchy installed is an executive one, there is a need for competence assessment that is only partly met by additional instruments.

Several methods exist for this. We have the 360 Degree Assessment method for example. Other methods exist, like McClelland’s and Hay Group’s competency identification process which attempts to take into account emotional factors that contribute to competence, something many existing methods do not address, perhaps simply because those factors are hard to quantify.

The responsible role is one that I envision as being played by the architect. The term “architect” would even be one that I propose as the term covering this responsibility within organizations. I would like to argue for a non-executive responsibility on the various executive levels in organizations, for ownership of competence by filling this role not with a hired consultant, but with a person that is part of the (competence-focussed) hierarchical structure of the organisation. This way we can avoid what we see very often on the higher executive levels, namely hiring consulting companies that establish a more or less structural relationship with management to fill the void of an established architecture process, thereby “outsourcing” much of the competence that should be native to the enterprise.

Abonneer op de nieuwsbrief

%d bloggers like this: