Beste Peter (28/4 7:19) 
 
 
Tja, je mengt wel eens in een discussie. Het zeggen van A én B. 
 
Het is en blijft lastig om de titel architect te duiden in de informatie & IT-sector. Dat komt deels doordat de uitleg van wat architect-zijn is is en betekent. Je kunt immers de hardware van een informatievoorziening inrichten, maar ook van alle applicaties, of van één applicatie. Je kunt voor beide een lans breken, met dien verstande dat je belangrijkste stakeholder iemand (of iets als je in termen van organisaties denkt) anders is: de niet-IT-er die zich laat ondersteunen door IT en de IT-ers die een platform nodig hebben om die ondersteuning te kunnen realiseren. Het is net als met systemen, iets vergelijkbaars doen voor een ander publiek hoewel je kunt uitleggen dat je hier nog steeds over vergelijkbare systeemniveaus spreekt.  
En dan wat de IT-sector ontzettend hard nodig heeft: overzicht, inzicht en onder regie komen. Je kunt dan zowel een lans breken voor het gebruik van de titel architect, alsook tegen het gebruik van die titel. Jan en Pieter hebben het over de stedebouwkundige architect, je kunt het ook over een planoloog of een informatie strateeg hebben. Of dat architecten zijn, het heeft er veel kenmerken van, maar veel ook niet.  
En dan heb ik het nog niet over wat in de organisatie buiten haar informatievoorziening gebeurt. IT-ers claimen het vormen van bedrijfsprocessen, maar dat is feitelijk een zwaktebod van de rest van de organisatie. Feitelijk zou een organisatie die iets voorstaat, en dat zal moeten want waarom is de organisatie er anders, ook moeten bepalen hoe ze hun doel(en) cq. strategie willen bereiken. Informatie is daar maar een onderdeel van, en IT is maar één van de vele hulpmiddelen die daarvan aangeschaft en ingezet kunnen worden. 
 
Wat ik veel erger vind is dat de titel gebruikt wordt om een paar euro per uur meer te verdienen. Als je niet zegt dat je tot het Nederlandse leger van zo’n 30.000 architecten behoort ben je minder. Wat natuurlijk volle onzin is, want feitelijk zijn er maar een paar 100 echte architecten, en de rest doet waar zij goed in is en gebruikt de titel architect.  
 
Architectuur in de IT-sector (applicaties, bestanden, systeemsoftware, hardware en netwerk) is iets blauws, iets dat ingericht kan worden en hoort dus hoogstens op tactisch niveau in een organisatie. Omdat het inrichting is kan je veel structureren, en dat is precies wat TOGAF, DYA en wat al niet bedacht is doet en wil doen. Het gaat allemaal over inrichten en verrichten, en niet over het richten. Meer dan 99% van de IT-wereld is hier mee bezig: er hebben (of maken) een probleem, en zorgen voor de IT-oplossing. Ontwerp tot realisatie en testen. Te beginnen met iets dat business analyse of informatie analyse heet en wat niet meer is dan het begrijpen van het probleem door analyse, waarna je gaat ontwerpen, inrichten, en dus realiseren en testen. Er is een stuk land en daar moet een huis op komen.  
Waar zit nu de architect in de informatie & IT-sector? Informatie zelf? Applicatie/IT-business/IT-Enterprise/Alignment/ontwerp? Infrastructuur? De vergelijking met de bouwwereld gaat steeds vaker mank als je verder buiten de technologie en de toepassing daarvan zelf komt.  
 
Klopt, iemand die een concertgebouw gaat ontwerpen voert die opdracht uit. Dat is ook wat de IT-sector doet: opdrachten uitvoeren, te beginnen met weten wat de vraag eigenlijk is, gevolgd door een passend ontwerp enz. Maar dat hele proces, en dat zijn ervaringscijfers, is ongeveer 20% of minder van het budget van een organisatie. Zo’n 80% of minder is exploitatie. En dan hebben we het nog steeds over oplossingen in een geheel. Naast dit alles zal er ook nog iets moeten zijn die dat soort oplossingen richt, de noodzaak ervan vaststelt. En het budget. En dat heeft weinig met IT te maken, en dat soort zie je dan ook zelden in de IT-wereld. Logisch, want organisaties moeten zelf bepalen waar ze hun geld het beste aan kunnen besteden, dat kunnen IT-aannemers niet doen. Die krijgen een opdracht, en je mag hopen dat die goed en helder neergezet is. Business analyse is alleen nodig als die opdracht niet goed genoeg uitgewerkt is. Hopelijk dus een uitstervend beroep, want organisaties zullen zelf goed moeten weten wat ze doen met hun informatie. Daar is het werkterrein van de informatiekundige, in de vraag naar informatie in de organisatie tegenover, hopelijk in optimale samenwerking, met oplossers als IT-ers. 
 
Met je verhaal over Sydney vertel je m.i. hetzelfde als ik hier nu vertel. Je hebt het over IT-leveranciers, onze aannemers en waar ze mee bezig zijn. Je kunt daar strijden of de architect bij deze aannemers zit, of dat het om een onafhankelijk architect dient te gaan. Als het puur om het (functionele) ontwerp gaat dat voldoet aan de gestelde vraag kan ik me de combinatie ontwerper/aannemer voorstellen. Maar dan moet al wel voor houtbouw gekozen zijn, want een houtbouw aannemer zal alleen houtbouw ontwerpers willen. Dus zal de keuze voor .Net en IBM feitelijk al gemaakt moeten zijn voordat een organisatie de opdracht geeft dat concertgebouw te ontwerpen, en mogelijk bouwen. De vraag van de klant is eerst, hoe zeer je ook een betere oplossing voor die vraag wilt bieden. 
 
Wat ik wel vaak tegenkomt is dat het meer willen bieden ook letterlijk genomen wordt. Het leveren van meer en andere functionaliteit dan gevraagd wordt. Soms zelfs veel en veel meer. Vaak functionaliteit die er al is, maar dan net even anders. Met alle aansluitingsproblemen. Daarom zullen opdrachtgevers zeer precieze vragen moeten leren stellen, en zullen aannemers, IT-leveranciers, moeten leren niet meer of minder op te lossen dan gevraagd wordt. En dat zijn we absoluut niet gewend. Kijk maar eens naar de outsourcing naar landen als India. Waar gaat het fout? In de vraagstelling. India weet vaak te doen wat hen gevraagd wordt, maar als wij de juiste vragen niet (kunnen) stellen, dan zal outsourcing zeker mislukken. Voorbeelden te over, zie vooral ook de bankwereld. TOGAF probeert zoveel mogelijk werk binnen de organisatie zelf in IT te trekken: “omdat ze het in de organisatie niet doen”. Je kunt echter je hersenen, met je kennis van je informatie, als organisatie niet door derden laten doen, en dat is TOGAF wel probeert. En wat in de huidige bewegingen van organisaties niet past. Men gaat het “voortraject” echt structureel zelf doen, los van IT juist om IT onder regie te krijgen. 
 
Structuur en functie zijn 2 van de 3 kenmerken van Vitruvius. De derde, schoonheid, wordt nog nauwelijks begrepen in de IT-sector. Laat staan harmonie, een niet-Vitruviaans kenmerk. Dan gaat het niet meer om binnen de getrokken grens, maar juist ook om buiten de grens. En juist in de bouwwereld zie ik vaak objecten die niet of nauwelijks passen in hun omgeving.  
 
Jij hebt dus een keuze gemaakt voor wat architectuur voor jouw is. Misschien dat je het woord eens beter kunt vervangen door een ander woord, zoals bijvoorbeeld ontwerp, want we hebben een veelvoudig homoniem gecreëerd en we weten vakmatig dat zoiets dat ons ontzettend veel parten gaat spelen.  
 
Ik wens je veel succes met je keuze, en feliciteer je dus, zoals ik al eerder gezegd heb, met het feit dat je een keuze gemaakt hebt.  
 
 
Steven van ’t Veld 
Steven.van.t.Veld@AIM.nl