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

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 op de volgende wijze: