11 September 2006: Originele reactie op artikelen Martin van den Berg

Reactie op de volgende artikelen:

• Martin van den Berg: IT-Architect: bijna onmogelijke combinatie
• Martin van den Berg: Ngi promoveert architecten tot afdeling
• Op 28 september 2006 in AutomatiseringsGids gepubliceerde tekst van de reactie

In de artikelen “NGI promoveert architecten tot afdeling” en “IT-Architect: bijna onmogelijke combinatie” uit de Computable nr 36 van 8 september 2006 wordt de mening van Martin van den Berg (voorzitter NGI-afdeling Architectuur, Capgemini/Sogeti) gegeven over “de IT-architect”. Martin maakt in de inhoud een paar stappen die ik in de wereld van de IT-aanbieders nog niet gezien heb. Hulde daarvoor! Daarmee zet hij de deur naar een betere en constructiever discussie over het architect-zijn inderdaad weer goed open.

Martin ziet het goed als hij spreekt over het ontstaan van een vraag- (demand) en aanbod-(supply)-kant in de markt. Aan de aanbodkant zien we, zowel externe als interne, IT-aanbieders. Zij leveren producten en verlenen diensten rond IT als hulpmiddel. Softwarehuizen, systeemhuizen en IT-adviesbureaus, zoals Capgemini, Getronics, IBM, VKA, Axioma, Ordina, Sogeti, HP enz., zijn IT-aanbieders.

Aan de vraagkant zien we organisaties die behoefte hebben aan informatie. Zij dienen zelf kennis van en ervaring met de informatie die ze nodig hebben om hun organisatie naar behoren te laten functioneren op te bouwen en te beheren. Met die kennis en ervaring raken zij in staat om pro-actief hulpmiddelen als bijvoorbeeld IT aan te schaffen om die behoefte aan informatie ook inderdaad op de juiste manier in te dekken.

Dit alles heeft trouwens, ondanks de brug die Martin slaat, op zich weinig met outsourcing te maken. Ongeacht de manier waarop IT “gesourced” wordt zal de vraag goed bekend moeten zijn; alleen met die kennis kan de juiste IT-ondersteuning beschikbaar komen. Feitelijk ongeacht of dat via insourcing, outsourcing of zelfs offshoring gerealiseerd wordt. Dat komt omdat al die voor deeloplossingen gekozen manieren samen de totale IT-infrastructuur voor een organisatie vormen. En die zal pro-actief gecontroleerd (vgl. functioneel beheer) moeten (kunnen) worden door die organisatie, en daarvoor is de genoemde kennis van informatie onontbeerlijk.

Martin heeft gelijk als hij zegt dat bij het aanschaffen (procurement) van IT geen keiharde IT-architectuur in de aanvraag opgenomen moet zijn. Sterker nog, elke uitspraak die de inrichting van de technologie zelf beperkt kan geld kosten. Natuurlijk zal een organisatie precies moeten vragen welke informatie zij op welke plaats, op welke tijd en van welke kwaliteit beschikbaar willen krijgen. Maar zodra je je gaat bemoeien met de manier waarop de applicaties geprogrammeerd worden, de databases gestructureerd zijn, de systeemsoftware werkt, het netwerk in elkaar zit, welke hardware er moet komen enz. beperk je de IT-aanbieder in hun mogelijkheden. En daarmee ga je voorbij aan de ervaring van die IT-aanbieder en aan wat ze al hebben en mogelijk opnieuw kunnen gebruiken.
Natuurlijk moet het geheel straks bij elkaar passen omdat het één IT-infrastructuur moet vormen voor de organisatie, maar als je je bij de functionele vraag houdt en zo min mogelijk rond het hulpmiddel en de inrichting daarvan eist mag je verwachten dat de leverancier sneller, goedkoper en met hogere kwaliteit passende oplossingen kunnen bieden. Vergelijk het maar met vervoer: waarom zou je eisen dat je een automatische 6-versnellingsbak wilt hebben in een SUV als je functionele vraag is dat je regelmatig kleine groepen medewerkers moet vervoeren van Utrecht naar Rotterdam? Tenzij de organisatie echte redenen heeft om een automatische versnelling te willen hebben is de eis op zich irrelevant, en zeker als je dan ook nog om een 6-bak in een SUV vraagt. Daarmee kan die luxe, ideale en vooral goedkope 7-persoonsbus bijvoorbeeld niet aangeboden worden.

En natuurlijk zijn IT-aanbieders (supply-organisaties) bezig om zoveel mogelijk geld aan hun klanten te verdienen; bijvoorbeeld door zo weinig mogelijk kosten te maken. En dat is op zich ook niet erg, het is het normale vraag & aanbod spel. Als vragende organisatie zal je er goed voor moeten zorgen dat je precies vaststelt en afspreekt wat je af te nemen services zijn. De kwaliteit daarvan zal uiteindelijk bepalen welke prijs ervoor betaald moet worden, en dan zal je als vragende organisatie zelf zo slim moeten zijn om vast te stellen of de geboden prijs/kwaliteitsverhouding acceptabel is. Je zult daarbij natuurlijk ook altijd een marge aan leveranciers moeten gunnen omdat zij het anders niet overleven; en dan heb je een probleem omdat je dan zonder IT-services zit.

Grappig in het vraag- en aanbod-denken is dat de functie van architect ineens heel helder wordt. Als we architecten zien als de meest ervaren mensen die het overzicht hebben en die weten waar het naartoe gaat, dan is het geheel dus een kleine groep van de zwaarste mensen die we in de informatie- & IT-sector hebben. Bij de IT-aanbieders zien we de IT-architect (de mensen die weten hoe je een IT-infrastructuur inricht) en de Enterprise-(IT-)Architect (de mensen die bij de organisatie passende IT-oplossingen (alignment) in het geheel van het IT-landschap weten in te passen).
Aan de vraagkant spreken we over informatie, niet over IT. Degene die daar de kennis en ervaring van opbouwt wordt de informatiearchitect genoemd. Het is de informatiearchitect die de organisatie kan helpen als die vraagt om IT-aanbiedingen. Je ziet in de praktijk dat de informatiearchitect de discussie met, meestal, de Enterprise Architect van de IT-aanbieder aangaat om te zien hoe het aangebodene het beste past bij de vraag van de organisatie. Een expliciete invulling van het aanschaf/procurement traject, dus, waarbij de discussie tussen beide architecten de aanbieding van services door de IT-aanbieder inhoud geeft.

Martin heeft het over “van buiten naar binnen denken” en over “met de eindgebruiker samenwerken”. Dit is in feite een dubbel idee. Zeker, als we het over de diensten van IT-aanbieders en hun Enterprise- en IT-architecten denken, dan klopt dit volledig. Maar dit werkt heel anders voor de informatiearchitect.
Informatiearchitect (een informatiekundige, geen IT-er) is een functie die in de organisatie zelf vervuld zal moeten worden. Als daar geen kennis en ervaring voor in huis is, dan kan natuurlijk ad-interim iemand ingehuurd worden. Deze interim-mensen zullen dan wel ingezet worden om het expliciete eigendom van de informatie van een organisatie voor die organisatie te beheren. De kennis van die informatie is immers de enige manier waarop die organisatie echt zelf kan bepalen en controleren wat ze aan hulpmiddelen willen hebben, en uitgeven. Het beheer en gebruik van die kennis en ervaring kan je dan ook onmogelijk outsourcen (= de verantwoordelijkheid in handen van derden geven).

In die lijn betekent het ook, dat interim-mensen die de rol van informatiearchitect op zich nemen niet voor IT-aanbieders kunnen/mogen werken (of in welke mate dan ook aan IT-aanbieders verbonden mogen zijn). Je huurt toch ook geen autoverkoper in om je vervoersproblematiek in kaart te brengen. Of een kantooreigenaar om je optimale huur van je kantorengebouwen vast te stellen. Om diezelfde reden huur je ook geen IT-er/IT-aanbieder in om je informatie behoefte vast te stellen en te beheren.
En daarmee is onafhankelijkheid een cruciaal begrip geworden. We spreken hier over informatiekundigen die ongebonden/onafhankelijk van IT-aanbieders aan de vraagkant de kennis van de informatie van een organisatie opbouwen en beheren.
Organisaties die dit aanbieden bestaan trouwens nog vrijwel niet in de markt, Vrijwel iedereen heeft zich, expliciet of impliciet, openlijk of stiekem, wel aan een IT-aanbieder ge-/ver-bonden. En als ze er al zijn, dan zijn het eenlingen of heel kleine organisaties die zo werken.

Dat past ook bij het preferred-supplier cq. shortlist syndroom waar we in Nederland anno 2006 zwaar aan lijden. Als je als organisatie je tijdelijk in te huren personeel via een paar gekozen IT-aanbieders laat lopen, dan ga je met de informatiearchitect (en de manager) griezelig de fout in. Want denkt u nu echt dat u een onafhankelijk interim-medewerker via een softwarehuis of IT-tussenpersoon kunt inhuren? Denkt u niet dat hier gefilterd wordt, vooral als het om de functies van manager en architect gaat? Natuurlijk gebeurt dat, al is het alleen al omdat onafhankelijken op voorhand niet geselecteerd worden voor de functies waar ze echt inbreng hebben in de organisatie.
Nederland zal echt uit deze verstikkende wurggreep van de shortlist los moeten komen als het om managers en architecten gaat die aan de vraagkant opereren (dus meestal niet projectmanagement). Die mensen huur je ook echt niet in voor €.60,- of €.80,- per uur. Dat kan namelijk niet omdat het om hoog risico, echt veel ervaring en veel permanente educatie gaat. Maar dat soort mensen geven, als ze het goed doen, ook wel echt waar voor hun geld. Bedenk, bijvoorbeeld, dat de besparingen die zij voorstellen vooral uit de omzet van de IT-aanbieder zal komen. Simpeler, beter, goedkoper moet immers ergens vandaan komen, en dat weten de IT-aanbieders heel precies.
En daarom is het dus alleszins begrijpelijk dat zij groot voorstander zijn van shortlists. Daar hebben ze op zich ook groot gelijk in, want die mogelijkheid wordt hen geboden door de vraagkant en waarom zou je daar niet van profiteren. Dit is één van de redenen waarom IT-aanbieders in de markt ongelofelijk conservatief optreden. Jawel, conservatieve veranderaars; het is wat de markt laat zien.

Martin heeft wederom gelijk als hij zegt dat een topman niet als eerste een (IT-)architect zal bellen. Zoals gezegd is IT een hulpmiddel, en de ervaring leert dat je het beheer en exploitatie van hulpmiddelen hoogstens op tactisch niveau mag verwachten in een organisatie, vergelijkbaar met het beheer en de exploitatie van auto’s, kantoren enz. Op strategisch niveau in een organisatie zie je dat de topmensen naar informatie (en communicatie) als bedrijfsmiddel kijken, in aansluiting op de standaard bedrijfsmiddelen/productiefactoren Mens, Natuur en Kapitaal(goed).
Daarom blijkt in de praktijk de samenspraak met de informatiearchitect als adviseur tussen strategisch en tactisch niveau uitstekend te werken. Het blijkt voor hoger management een verademing te zijn om over hun informatie te kunnen praten zonder dat IT daarbij betrokken wordt. De inhoud van die gesprekken zijn namelijk vrijwel altijd simpel en direct te relateren aan hun taken in de organisatie. Dus zeker, de topmens zal de (Enterprise- of) IT-architect niet bellen, maar de ervaring is iedere keer dat zij/hij de Informatiearchitect wel belt. Al is het alleen maar om beslissingen te onderbouwen om de gegroeide chaos aan oplossingen (in IT-taal: legacy) verder op orde te brengen, of om een due diligence uit te voeren.
Het is dan ook niet de IT-/Enterprise-architect die, in retrospectief, aan het einde van de 21e eeuw de belangrijkste architect zal blijken te zijn. Misschien dat de informatiearchitect zich uiteindelijk in een vergelijkbare positie met de “bouw”-architect/bouwmeester mag verheugen, waarbij het verschil in het aandachtsgebied zit. Ontwerpers van auto’s, huizen, organisaties enz. zijn immers ook onderschikt aan de mensen die zich met (ruimtelijke enz.) ordening bezighouden. Daarom kan het ook niet zo zijn dat we een IT-professional als Digitaal Rijksbouwmeester, of dat we een IT-minister krijgen. Er is toch ook geen Ministerie van Auto’s maar een Ministerie van Verkeer & Waterstaat. Het strategische belang van IT als hulpmiddel is en blijft helder, maar de aanbodkant kan de vraagkant niet domineren. En aan die vraagkant ligt nog een enorme hoeveelheid werk die gedaan moet worden.

Architecten zijn, zoals Martin hier laat optekenen, overigens geen mensen die managementposities gemist hebben. Architecten dienen zich namelijk met inhoud bezig te houden, en in mindere mate met het leiden van organisaties en mensen. In de ruim 5 jaar dat wij ons nu met het certificeren van architecten bezig houden blijkt steeds weer dat de architect een adviseur is, geen manager. Het is iemand die ooit de keuze voor inhoud gemaakt heeft, en niet voor management. De echt goede, seniore architect is daarbij wel een adviseur die ontzettend veel goed en kwaad kan doen vanuit die inhoud. Daar ligt een enorme verantwoordelijkheid.
Je mag dus verwachten dat de manager en de architect op een moment functies zullen zijn die, hoewel de één adviseur en de ander manager is, toch in waardering naast elkaar zullen staan. Het Amerikaanse model, dus. Het Nederlandse model laat mensen “doorgroeien” van uitvoerende- via analyse, advies- naar management-posities en dat werkt hier gewoon niet. Daarom lopen we in de praktijk ook zo vaak tegen het Peter Principle aan: mensen die net één niveau hoger doorgegroeid zijn dan ze kunnen, en dus feitelijk incompetent zijn voor hun functie. De keuze voor inhoud of management, de geschiktheid voor de één of de ander en het niet moeten doorgroeien van architect/adviseur naar manager als je verder wil komen is daarbij ontzettend belangrijk. Dit wordt nog veel te weinig expliciet gedaan.

Managementgoeroe Stephen Covey zei het al: je zult als mens/organisatie uit de cirkel van betrokkenheid naar de cirkel van invloed moeten; van reactief naar pro-actief. Dat betekent dat je als organisatie de verantwoording moet (willen en kunnen) nemen voor je informatie als bedrijfsmiddel. Je kunt niet meer aan de zijlijn staan en IT “laten gebeuren”, zoals het nu al decennia gebeurt. Je zult het moeten laten gebeuren, er zelf de verantwoording voor moeten nemen. En wel op de manier die je organisatie nodig heeft om haar doel te bereiken. En daarbij is IT een hulpmiddel. Strategisch, jazeker, maar te managen op tactisch niveau (of lager). En in de hand te houden door goedbeheerde kennis van informatie als bedrijfsmiddel.

Zoals gezegd denk ik dat de denkwijze die Martin hier neerzet inderdaad bij kan dragen aan de vorming van het beroep van architect in de informatie- & IT-sector. Ik denk echter niet dat er al duizenden architecten zijn. Verwacht wordt dat in Nederland alleen al binnenkort 30.000 IT-ers zich architect in de informatievoorziening zullen noemen. Noemen, want zijn is iets heel anders. 20 of meer jaren vakervaring tover je nu eenmaal niet in een paar maanden of jaren in je functioneren, en dan spreek ik nog niet over je kennis, je aanleg en wie je bent als persoon. Pas als dat allemaal goed in orde is kan een certificering van betekenis worden voor zowel de mens als voor de markt; we kunnen dan immers echt laten zien wat we kunnen en wie we zijn. Certificering is dan ook geen diploma halen (zoals in de Verenigde Staten enz.), of, en dan wordt het echt gevaarlijk, een persoonlijkheidstest afleggen.
Maar ook hier heeft Martin wel gelijk: zo lang iedereen zijn eigen invulling kan geven aan de titel architect en er nieuwe voorvoegsels bij kan verzinnen lijken we nog niet rijp voor het aantonen van de betekenis van de beroepsgroep. Maar dan wordt het dus ook vrijwel onmogelijk om een positiever imago van de Informatie-, Enterprise en IT-architect te geven. Want wat de ene goed doet, daar maakt de volgende weer een chaos van. Ach, er is nog veel te doen.