Hallo Daan, 
 
Je vroeg me om als onafhankelijke architect (ik ben in dienst van het bedrijf waarin en waarvoor ik als informatiearchitect werk) op je artikel te reageren. Normaal zou ik niet zo gauw reageren op een artikel over een architectuurstandaard die ik nog niet eens heb gedownload. Ik zal mij dan in mijn reactie ook beperken tot die zaken waar ik wel wat over denk te mogen zeggen. 
Vorige week nog was ik op een presentatie van een tool voor enterprise architecten. De eerste driekwart van de presentatie ging over wat de architect eigenlijk doet, waarna er gelukkig ook nog wat tijd overbleef voor het bespreken van het tool. Dat is wat ik ook in je beschrijving van TOGAF bespeur: wat doet de architect eigenlijk en wat zou die moeten doen? Bij gebrek aan een duidelijk kader, wordt alles beschreven wat iemand met de functietitel architect zou kunnen moeten (niet moeten kunnen!) doen. Een architectuurstudent of consultant van een softwarehuis zou het idee en de ambitie kunnen krijgen dat hij al die zaken ook moet kunnen en willen doen. Met als gevolg dat hij met die instelling in de praktijk waarschijnlijk niets voor elkaar zou krijgen. Een ervaren architect pikt uit een dergelijk boekwerk hopelijk wat hij ervan denkt nodig te hebben. Ik denk er overigens zelf, op dit moment, niets uit nodig te hebben. 
 
Ik ben het met je eens dat een dik boek en een certificaat perfect past bij consultancy. Een opdrachtgever in de ICT wereld weet namelijk, bij iemand die zich architect noemt, niet wat hij in huis haalt. Met een certificaat krijgt deze in elk geval de garantie dat grote delen van een dik boek zijn gelezen. Dat het boek met hagel schiet is voor hem ook alleen maar meegenomen, want je weet nooit voor welk probleem deze een architect in huis haalt. Ook in de fysieke wereld weet je overigens niet wat het specialisme en de deskundigheid van een bouwkundig architect is. Maar je weet dan doorgaans wèl met wat voor vragen je naar hem toe moet komen. 
 
In dat laatste zit hem wat mij betreft de crux: rollen en rolverwachtingen. Natuurlijk zou het fijn zijn als in een boek in de informatievoorzieningswereld de 'architectuur' de analoge betekenis en de 'architect' de analoge rol, taken en middelen zou krijgen die in de fysieke bouwwereld aan architectuur en de architect worden toebedeeld. Het is maar goed dat er veel tijd nodig is om een organisatie goed te leren kennen, voordat je aan de constructies moet gaan sleutelen. Waar anders moet een architect namelijk een heel traject in om aan de opdrachtgever, de planner en de metselaar uit te gaan leggen wat hij komt doen? Welke betonvlechter of bouwkundig voorman zou een architect voor een installatiekundige houden of omgekeerd? Als dit soort vakmensen in onze informatiewereld hun sporen verdiend hebben, gaan we ze allemaal architect noemen. Dan vind ik het ook niet gek dat een boek, dat de ervaring van al die vakmensen meent te moeten bundelen, over architectuur meent te gaan.  
 
Ik houd me liever bezig met het vervullen van de, ook door jou zo bedoelde, rol van architect en neem het op de koop toe dat ik wekelijks een paar uurtjes (ja, echt!) kwijt ben met het uitleggen wat ik doe. Het woord architectuur neem ik zelf liever niet in mijn mond, omdat ik daarna steeds een kwartier moet uitleggen wat ik wel en wat ik niet bedoel. Wat ik voor het uitvoeren van die rol nodig heb, is vooral een goede taakverdeling met de mensen om me heen, in de strategische en tactische veranderprocessen in onze organisatie. Dat kan alleen als ik zelf een heel duidelijk beeld heb van wat ik in het veranderproces wil bijdragen en waar mijn talenten liggen. Zaken waar ik me voorheen, als externe consultant, op deze manier eigenlijk niet zo mee bezighield. Voorheen had ik wel behoefte aan een boek met zaken op basis waarvan ik me een positie als architect kon verwerven (en zelfs dan nog niet zo breed of diep als TOGAF). Nu heb ik veel eerder behoefte aan een ander soort standaardwerk. En wel één, waarin ik kan vinden hoe ik mijn rol als architect in strategische en tactische veranderprocessen het meest effectief kan invullen en hoe ik mijn rol, in verhouding met andere rollen in de organisatie, kan neerzetten. Onduidelijkheden daarin blijven echt steeds weer de kop opsteken, omdat er geen consensus over de betekenis en het belang van architectuur is. Met een standaard definitie van rol en rolverwachtingen, zouden we (architect, informatiemanagement en business management, onder andere) samen (ondersteund door technieken en methoden) het veranderproces als geheel op een kwalitatief hoog niveau moeten kunnen inrichten. Dit zou ik verstaan onder een standaard vanuit de vraagkant. En ja, zo'n standaardwerk zou ik heel graag zien verschijnen. 
 
Met vriendelijke groet, 
 
Richard Uijen