Artikel

Waarom je geen IT-architect moet worden

Veel beheerders, ontwikkelaars en engineers zien een architectuurfunctie als een stap voorwaarts in hun carrière. Een stapje hoger op de ladder naar succes. Maar zoals er geboren leiders zijn en mensen met een geboren creatieve geest, zijn ook architecten, engineers, projectleiders en managers geboren voor hun vakgebied. In dit artikel wordt het werkveld van IT-ers in vier activiteitstypen ingedeeld. Deze activiteitstypen onderscheiden zich door verschillen in profiel van de gedragskenmerken die nodig zijn voor de succesvolle uitvoering van die activiteiten. De schrijvers betogen dat een indeling naar activiteitstypen IT-ers inzicht verschaft een juiste carrièrepad te kiezen.

Situatieschets

Marco is een ontwikkelaar die door hard werken en het volgen van diverse trainingen steeds meer in de belangstelling van zijn manager is komen te staan. Hij is zo langzamerhand het boegbeeld van de ontwikkelafdeling. Bij nieuwe projecten wordt hem steevast om zijn mening gevraagd. Het is Marco's droom op te klimmen tot Solutions Architect. Hij komt echter steeds meer tot de ontdekking dat de aansluiting met andere mensen in projectteams lastiger wordt. Voorheen kon hij altijd vertrouwen op zijn grondige kennis van zijn vakgebied, en had hij het idee dat hij hierin niet te overtreffen was. Nu hij meer en meer aan het begin van projecten wordt betrokken en geacht wordt de grote lijnen uit te zetten, gaat hij de diepgaande kennis met haar finesses missen. Marco voelt zich ongelukkig worden in zijn nieuwe rol. Het lijkt wel of hij de aansluiting niet kan vinden.

John is projectleider. Eerst van kleine projecten, maar in de loop van de tijd krijgt hij de verantwoordelijkheid over steeds grotere projecten. Het gaat John makkelijk af. Als er een vacature ontstaat als IT-manager, solliciteert John. Het is immers een grote stap voorwaarts in zijn carrière. John wordt aangenomen, maar helaas, na twee jaar is John afgebrand. Het leiden van projecten was weliswaar stressvol, maar voor hem goed vol te houden. Het managen van een afdeling blijkt toch een andere discipline. Hij voelt zich ongelukkig in zijn nieuwe rol.

Het hoe, wat en waarom van architecten

In de literatuur wordt veel gesproken en gediscussieerd over wat een architect nu eigenlijk is. Wat hijzou moeten doen en waar hij verantwoordelijk voor is.

Rijsenbrij [1] geeft een scheiding aan tussen architecten en engineers. Hij geeft aan dat er vier soorten architecten zijn, te weten: enterprise architecten, domeinarchitecten, applicatiearchitecten en werkruimtearchitecten. In zijn eerdere publicatie [2] was er ook nog sprake van technische infrastructuurarchitecten, maar hiervan heeft hij later gesteld dat deze mensen vooral engineers zijn.

Volgens Rijsenbrij volgen engineers en architecten verschillende werkwijzen. Architecten visualiseren wat de klant graag zou willen, terwijl engineers iets op een zo efficiënt mogelijke, goedkope en eenvoudige manier willen bouwen. Architecten maken het globale ontwerp, en engineers het detailontwerp.

Hoewel de taak van engineers hierbij niet onderschat wordt, wordt toch impliciet de boodschap uitgedragen dat architecten zich op een ander (hiërarchisch) niveau bevinden dan engineers.

Ook Microsoft [3] definieert meerdere architectrollen. En ook hier wordt het verschil tussen architecten en engineers vooral gezocht bij wat een architect geacht wordt te doen. Hiermee wordt de indruk gewekt dat men van een engineerrol kan doorstromen naar een architectenrol, wanneer een manier van werken wordt aangeleerd (middels trainingen en ervaring bijvoorbeeld).

In een persoonlijk gesprek met Jack Greenfield[4], Software Architect, Enterprise Tools bij Microsoft en eerste auteur van het boek Software Factories[5], blijkt dat de onoverkomelijke discussies over een indeling in soorten architecten op basis van de wat heel herkenbaar zijn. Zet een aantal architecten bij elkaar en ze worden het niet eens over wat een architect onderscheidt van een engineer.

Onze stelling

We hebben het standpunt dat het belangrijkste kenmerk van een architecten, engineers, projectleiders en managers is wie hij is. Kennis kun je leren, ervaring bouw je op, maar gedrag is slechts in beperkte mate bij te stellen2 . Het zit bij wijze van spreken al in de genen van mensen in welke functie ze zich het gelukkigst zullen voelen.

We kennen allemaal wel iemand van onze basisschool van wie als kind al duidelijk was dat hij later een leidinggevende functie zou krijgen. Ook waren er duidelijk mensen te herkennen met oog voor detail. Als men deze kinderen later op bijvoorbeeld een reünie weer tegenkomt, blijken ze vaak een beroep te hebben gekozen dat aansluit bij de persoonlijkheidskenmerken die ze als kind al hadden.

Mensen die geboren architecten zijn, pakken zaken van nature anders aan dan mensen die bijvoorbeeld geboren engineers zijn. Dit geldt ook voor het verschil tussen managers en projectleiders. Bij allemaal is de natuurlijke aanpak van groot belang voor hun succes.

In dit artikel onderkennen we vier type activiteiten op basis van het profiel van gedragskenmerken. Om de essentie van dit artikel goed over te brengen is het belangrijk even stil te staan bij de verschillen tussen personen, rollen, functies en de respectievelijke kenmerken. Waar we in de inleidende delen van dit artikel ‘engineer’ schreven (de rol) maar eigenlijk ‘engineering’ bedoelden, zullen we in het vervolg zorgvuldig met de verschillen omgaan.

Achtereenvolgens zullen we starten met de activiteitstypen, waarna we ingaan op rollen en daarna functies.


Figuur 1: Vier type activiteiten

We onderscheiden vier typen activiteiten: maken of organiseren, met een gerichtheid op de inhoud of op het proces. Een overzicht laat zich dan grafisch vertalen in bovenstaand figuur. We hanteren de labels engineering, projectvoering, architecting en managen.

Mensen zijn in hun werkwijze te onderscheiden in diegenen die organiseren en diegenen die maken. Er zijn natuurlijk managers met een grote inhoudelijke kennis. Dit is niet in tegenstelling met onze beleving. Het is waarschijnlijk dat we hier te maken hebben met personen met een natuurlijke activiteitstype architecting in een managementfunctie.

Als we de verschillen tussen de makende - en de organiserende activiteitstypen nader uitwerken komen we in eerste instantie tot de onderstaande tabel, gebaseerd op ervaringen uit het veld.

Maken (Engineering / Project voering)
Organiseren (Architecting / Managen)
Werken met zekerheden vooraf. Zekerheden gaandeweg tegen komen, graag willen werken in een onzekere omgeving; vertalen van richting en doelen naar structuur.
Werken vanuit beproefde structuren. Herkennen van structuren en gaandeweg structuren aan brengen.
Efficiënt werken. Effectief werken.
Oplossingsgericht denken. Conceptueel denken.
Maken, produceren. Organiseren & structureren.
Levert geld op. Kost geld, maar bij afwezigheid kost het meer geld.
Zorgen dat de dingen goed (conform opdracht) gedaan worden. Zorgen dat de goede dingen worden gedaan.
Tijd verdelen over alle problemen. 80% van de tijd besteden aan de top 10% van de problemen.
Werken met gefaseerde aanpakken. Viewpoint hopping toepassen.
Leggen hun expertise consistent en consequent uit. Verschillende viewpoints gebruiken om het verhaal naar verschillende stakeholders te brengen.
Helderheid en duidelijkheid is belangrijk zodat de resultaten van het werk bijdragen aan de te halen doelen. Ruimte en vrijheid is belangrijk, dat is het speelveld wat wordt ingevuld.
Planmatig tijd indelen. Gebruiken van inspiratiemomenten.
Zonder engineering werkt het niet of niet goed. Zonder architecting heb je er niets aan.
Zonder project voering komt het er niet of veel te laat. Zonder managing krijg je iets waar niemand om gevraagd heeft.

Tabel 1

Wat is er nu zo anders aan het bekijken van de IT-er aan de hand van zijn gedragsprofiel?
In de meeste modellen wordt een typering gehanteerd naar kennis en ervaring, het wat. De bovenstaande activiteitstypen geven echter een typering op basis van gedragskenmerken, het hoe

Veel mensen zien een managementfunctie als een carrièrestap na een projectleiderfunctie, of een functie als architect als dé groei vanuit een engineeringfunctie. Voor mensen met als dominant activiteitstype engineering of projectvoering kan dit slecht uitpakken.

Groei en carrièreperspectief zit wat ons betreft vooral in de mate van verantwoordelijkheid die men in een bepaalde rol heeft. Het is dan wel zaak om de beoordelingscriteria af te stemmen op de activiteitstypen. Belangrijk is te constateren dat ook mensen met engineeringactiviteiten opereren op verschillende niveaus en tot op het hoogste niveau kunnen doorgroeien zonder zichzelf geweld aan te doen in onnatuurlijke rollen3.

In gangbare modellen kunnen meerdere rollen door één persoon worden ingevuld. Wij stellen de vraag: “wat is het belangrijkste activiteitstype dat nodig is voor de rollen?” Als de rollen een verschillend activiteitstype vereisen, dan voorzien we grote problemen bij het vervullen door één en dezelfde persoon.

Bestaande modellen die kijken naar persoonlijkheidstypen zijn de Big Five [7,8] en de Myers-Briggs Type Indicator [9]. In de Big Five en de MBTI herkennen we echter geen sterke correlatie met de IT-rollen en IT-functies. De Big Five helpt ons dus niet in het onderscheid maken tussen b.v. engineering en architecting.

We herkennen wel het Forer effect[10]4  en mede daarom hebben we gezocht naar een typering waarvan het ene eind van de schaal ‘net zo mooi’ is als het andere eind. Bij het maken van de bovenstaande tabel is zorgvuldig rekening gehouden waardeoordelen te voorkomen. De kenmerken aan de linkerkant zijn net zo belangrijk en waardevol als die aan de rechterkant.

We beseffen dat we ons op het werkgebied van de Arbeids- en organisatiepsychologie (meer in het bijzonder Personeelspsychologie) begeven. Voor diegenen die op deze gebieden kundig zijn moet dit artikel gezien worden als een uitnodiging vanuit de praktijk om aansluiting te zoeken.

Wat onze typering duidelijk maakt is dat geen van de vier activiteitstypen kunnen ontbreken in een organisatie of project. Dit wordt geïllustreerd door de laatste kenmerken uit bovenstaande tabel: het werkt dan niet, het komt dan niet op tijd, je hebt er niets aan of niemand heeft er om gevraagd.

Ook in de gangbare modellen wordt geadviseerd rekening te houden met verschillende persoonlijkheidstypen in een team, bijvoorbeeld de Belbin [11] teamrollen5. We zien de toepassing van deze Belbin rollen nauwelijks in de praktijk en ervaren dat de vier activiteitstypen veel beter aansluiten bij de praktijk.

Misschien wel het belangrijkste voordeel van een indeling op basis van activiteitstypen is dat mensen zich als vanzelf thuis voelen in één van de vier typen en er geen autoriteit nodig is om te vertellen wie het predicaat ‘manager’ of ‘architect’ verdient. Wat ons betreft mag je jezelf architect noemen als je de kenmerken behorend bij het activiteitstype architecting bezit. We hebben het dan niet over de senioriteit, het activiteitstype kan zowel passen bij een aspiring architect (geen ervaring) als bij een senior enterprise architect.

Iemand met een engineeringprofiel die begrijpt dat een rol als manager, projectleider of architect niet alleen andere kennis en ervaring vereist maar ook bijbehorende activiteitstypen, zal ook begrijpen dat een verandering van rol voor hem geen promotie zal betekenen maar een onnatuurlijke en ongelukkige carrièrestap. We willen de lezer bewust maken dat het slecht functioneren van een medewerker niet alleen hoeft te worden veroorzaakt door het ontbreken van kennis en kunde, maar ook dat de functie niet bij zijn persoonlijke aanpak kan passen.

Rollen

De activiteitstypen geven aan dat situaties op verschillende manieren aangepakt worden. De typen zijn niet alleen te zien als een eigenschap van personen, maar ook als de gedragskenmerken van rollen.

Een titel van een rol dekt niet altijd de (activiteiten)lading. Neem bijvoorbeeld de opdracht om een project te leiden waarvan de requirements en het doel niet helder of zelfs onbekend zijn. Mensen die makende activiteitstypen als hun dominante natuur hebben zullen verzuchten dat het een onmogelijk project is. Daarentegen zullen mensen die organiserende activiteitstypen als hun dominante natuur hebben als het ware gelukkig worden van zo’n opdracht omdat het veel ruimte geeft en de creativiteit aanspreekt. Met andere woorden, er wordt weliswaar gevraagd om een projectleidersrol, maar de context vereist een organiserend activiteitstype.

Geconfronteerd met een probleem dat moet worden opgelost, zal elk persoon de eigen aanpak als meest natuurlijk ervaren. Van belang is dus dat bij het inrichten van een organisatie gekozen wordt voor een juist kiezen van de functie-rol mapping (geen rollen met tegenstrijdige vereiste activiteitstypen samenbrengen in één functie); en voor een juist specificeren van de vereiste kwalificaties van functies.

Dit is de reden dat de vier gedragsprofielen niet één op één zijn te mappen op rollen. Zo is Programmamanagement iets heel anders dan projectmanagement. Voor programmamanagement is het activiteitstype managing relevanter dan het activiteitstype project voering.

Stofberg en Trienekens [12] beschrijven architectenactiviteiten als facilitating, formalizing and controlling. Hierin wordt gesteld dat de controlling architect relatief dicht bij de engineer staat en de facilitating architect relatief dicht bij de manager. Alhoewel dit vreemd kan overkomen is dit goed te verklaren doordat het activiteitstype engineering belangrijk is bij controlling architects en het activiteitstype managing belangrijk is bij facilitating architects.

Het zou dan ook te eenvoudig zijn om een IT-functiehuis in vier delen op te delen op basis van de vier activiteitstypen.

Willen mensen voldoening hebben in hun werk dan moeten ze acteren in hun natuurlijke rol. Voor leidinggevenden is het inzicht in activiteitstypen belangrijk om mensen die van nature een architecting activiteitstype hebben een groeipad richting architectuur te bieden, ook al blijkt dat niet uit hun werkverleden. In plaats dat we terugkoppelen wat mensen slecht doen, onderkennen we dat de persoon in een tegennatuurlijke rol werkt en juist sterke eigenschappen voor een andere rol heeft.

Groei…

Mensen groeien het best in functies en rollen die een activiteitstype vereisen die aansluit bij hun natuurlijke activiteitstype.

…horizontaal op je plek komen,

Weinigen starten hun carrière in de rol of functie projectleider, manager of architect maar veelal in een engineeringrol. Voor mensen met een engineeringprofiel is dit een natuurlijke rol, maar voor de overige mensen is het een ‘vreemde’ rol. Voor die mensen met een architectingprofiel is een overstap van een engineeringrol naar een architectenrol niet zozeer een groeipad, maar moet eigenlijk beschouwd worden als een ‘thuiskomen waar je hoort.’

…of horizontaal om alle activiteitstypen te ervaren.

Dé manier om te groeien naar een ‘completere’ IT-er is om tijdelijk rollen te vervullen die persoonsvreemde activiteitstypen vereisen. Zo kan door het succes uitvoeren van een architectenfunctie nuttig zijn om een tijdje een projectleidersrol op zich te nemen om zijn projectmatige kwaliteiten op peil te brengen. Voor mensen aan het begin van hun carrière die nog op zoek zijn naar hun carrièrepad kan een onorthodoxe aanpak als projectleider een signaal zijn voor erkenning van een architect in spe.

In principe geldt voor alle functies dat een tijdelijk uitoefenen van rollen met andere activiteitstypen enorm helpt bij het begrijpen van mensen die zo’n ander activiteitstype als natuur hebben. De ervaring in de andere rol moet dan ook worden gezien als een verrijking van de persoon die de kwaliteit van de communicatie met de ‘andere kant’ verbetert.

Als het aangeboren activiteitstype niet onderkend wordt ontstaat er een onjuiste veronderstelling dat projectleiders, managers of architecten ‘beter’ zouden zijn. Een engineer wordt dan ‘slechts’ als startfunctie gezien. Alle vier de activiteitstypen zijn echter nodig in een project of bedrijf.

Dat IT-carrières starten in de rol engineer verklaart het feit dat startsalarissen voor engineering rollen lager zijn dan die voor niet-engineering rollen. Dat betekent echter niet dat de eindsalarissen ook zouden moeten verschillen. Wij vinden dat in alle rollen voldoende groeiperspectief mogelijk moet zijn. Het zou in ieder geval onverstandig zijn op basis van (een perceptie van) een succesvoller carrièrepad een tegennatuurlijke functie te ambiëren. We zijn van mening dat het rekening houden met de natuurlijke aanleg van mensen en een bewuste situationele inzet van mensen in rollen, er voor zorgt dat mensen beter op hun persoonlijke kwaliteiten worden beoordeeld die ze wél hebben dan op de verwachte rol kwaliteiten die ze niét hebben.

Vervolg

Wij stellen dat het activiteitstype van een persoon moeilijk tot niet te veranderen is, hoewel dit niet wetenschappelijk gestaafd is. Feedback hierop en liefst verwijzingen naar bestaand onderzoek wordt door ons hoog op prijs gesteld.

Dit artikel mag ook worden gezien als een uitnodiging aan de professionele wereld van gedragswetenschappen en certificeringinstanties om te reageren.

Uitbreidingen van het model moedigen wij aan. Mogelijke uitbreidingen van het model kunnen zijn:

  • Het model toepassen op een grotere groep mensen voor het vergroten van de toepasbaarheid.
  • Aanvullende gedragskenmerken voor verbetering van het model.
  • Een ‘Viva-test’ waarmee met behulp van een vragenlijst bepaald kan worden welke de meest belangrijke persoonskenmerken zijn van iemand, en in welke rol hij zich dus waarschijnlijk het meest thuis zal voelen.
  • Een mapping van de vier gedragsprofielen op andere bestaande modellen om te kijken of er al iets vergelijkbaars is beschreven.
  • Onderzoek om bijvoorbeeld te kijken hoe de verdeling is in aantallen per gedragsprofiel.

Ten slotte

Hoewel de in dit artikel gepresenteerde activiteitstypen zich concentreren op het wie een architect, engineer, projectleider of manager eigenlijk zijn, blijkt dat veel engineers voor zichzelf een groeipad richting architectuur zien.

Schoolverlaters krijgen over het algemeen geen architecten functie, omdat de ervaring hiervoor ontbreekt. Of mensen uiteindelijk architect moeten worden hangt vooral af van de manier waarop ze zaken aanpakken en de gedragskenmerken zoals in dit artikel zijn beschreven. Geboren architecten zullen daarom vanzelf komen bovendrijven.

Als men de benodigde architectkenmerken niet heeft, dan zou het veel beter zijn te excelleren als engineer, en eventueel te specialiseren op een bepaald aspect hiervan. Engineers die architecten worden, maar er niet voor zijn geboren, zullen naar onze mening ongelukkig worden in de uitoefening van hun professie.

Dit artikel is eerder gepubliceerd in TIEM nr. 21

1Waar in dit artikel gesproken wordt over “hij” wordt bedoeld “hij/zij”.
2Ervaring is het resultaat van de juiste kennis en gedrag toepassen in voorkomende situaties.
3Met nadruk willen we aangeven dat we hier niet de indruk willen wekken “wie als een dubbeltje geboren wordt, wordt nooit een kwartje”. Dat zou immers veronderstellen dat engineers dubbeltjes zijn hetgeen we bestrijden.
4Het Forer-effect, ook Barnum-effect genoemd, is afkomstig uit de psychologie en betreft de neiging van mensen om vage en algemeen geldende uitspraken over de eigen persoon te accepteren als rake, typerende omschrijving, zonder zich te realiseren dat diezelfde omschrijving voor bijna iedereen opgaat.
5Voorzitter, vormgever, plant, waarschuwer, bedrijfsman, brononderzoeker, groepswerker, afmaker.

Categorie:   
Auteur(s)
afbeelding van sjaaklaan
Sjaak Laan
Logica - Principal IT Architect

Sjaak Laan (1964) werkt bij Logica als Principal IT Architect en heeft 22 jaar IT ervaring. Sjaak is een specialist op het gebied van architectuur, security en infrastructuur en heeft veel kennis van bedrijfsprocessen en systeemintegratie. Hij wordt vaak gevraagd als lead architect of adviseur in complexe projecten. Hij is ITAC Master Certified IT Architect, CISSP (Certified Information Systems Security Professional) en TOGAF certified. Sjaak publiceert regelmatig over zijn vakgebied, onder andere via Computable en via zijn sites www.sjaaklaan.nl en www.sjaaklaan.com.

afbeelding van ronvandenburg
Ron van den Burg
Logica - Principal IT Architect

Ron van den Burg (1965) is een senior IT consultant met meer dan twintig jaar ervaring in het beheer, ontwerp, projectmanagement en architectuur van IT. Zijn ervaring strekt zich uit tot vele marktsectoren, in het bijzonder Industry, Distribution and Transport. Hij staat bekend om zijn analytisch vermogen en zijn troubleshooting capaciteiten. Zijn specialiteiten zijn leadership development en business continuity management. Zijn passie is werken aan 'alle dingen die belangrijk zijn maar niet urgent'.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.