Ik ben het grotendeels eens met het bovenstaande, maar ik mis een belangrijk begrip: dienst (of service; en dan niet in de enge SOA-zin van het woord). Architectuur moet m.i. beginnen met de vraag wat een organisatie(onderdeel), proces of applicatie voor de klant ervan doet. Informatie is daarbij "slechts" een middel. Een van de redenen dat architecten zo slecht door de business worden gehoord, is dat "informatie" vaak wordt geassocieerd met IT, en dus met die zacht zoemende machines in de kelder in plaats van met de klant aan de balie. Ook architecten zelf hebben nog wel eens de neiging de informatielogistiek en het berichtenverkeer in plaats van de dienstverlening leidend te laten zijn.

Ik had eigenlijk gehoopt hier een poging tot omschrijving van het vakgebied architectuur te vinden, waarmee in één oogopslag duidelijk wordt wie zich wel en wie zich niet met architectuur bezighoudt. Dat mensen zich onterecht architect noemen, kan alleen voorkomen worden door het beschermen van de titel en het gebruik ervan te reguleren. In mijn ogen dragen bijna alle mensen in een organisatie bij aan 'de architectuur'. Op sommige gebieden alleen wat meer dan op andere. De mate waarin dat bewust en gestructureerd wordt gedaan en de mate waarin dat als sturingsinstrument voor het management wordt gedaan, vanuit missie, visie en strategie, varieren ook. Het zou in de rol van een architect in de organisatie moeten worden verankerd dat deze, gebaseerd op een methode, gestructureerd de samenhangen binnen en naar de omgeving van de organisatie stuurt vanuit de strategie van het management en rekening houdend met alle belanghebbenden.

Volgens mij gaat ICT architectuur in de kern maar over één ding: samenhang. Het in kaart brengen van de samenhang (of juist het ontbreken daarvan) in de informatievoorziening is waar ICT architec-tuur zich mee bezig zouden moeten houden. Ik ben het op dat vlak dan ook volledig met Wouter eens. Die samenhang zou je m.i. bij voorkeur duidleijk moeten maken met grafische overzichten; of je die nu blauwdrukken noemt of landschapskaarten of whatever: plaatjes dus ! Voor iedere betrokkene van elk niveau begrijpelijk en inzichtelijk. En betrokkenheid van de architect is hierbij ontegenzeglijk een be-langrijke vaardigheid maar dat staat niet op gespannen voet met het wel of niet kunnen visualiseren..  
 
Natuurlijk heeft Marc gelijk als hij zegt dat het uiteindelijk gaat om het verbeteren van de dienstverle-ning aan de klant. Maar dat is pas mogelijk als je, zoals Wouter terecht stelt, een helder beeld hebt van de huidige situatie. En of je dat beeld nu wel of niet hebt gevormd op basis van een (standaard) methode, is voor een opdrachtgever niet van belang. Die zal het worst zijn of je zijn informatiehuis-houding in kaart heb gebracht met Tapscott, TOGAF of Zachman. Zo lang hij maar het overzicht heeft op basis waarvan hij verbeteracties kan starten. 
 
De hele discussie over methodes en standaarden vind ik eigenlijk een beetje zonde van de tijd en energie die beter besteed kan worden aan het simpelweg “doen”. Ik zie nog te vaak dat we als be-roepsgroep blijven hangen in die ivoren toren waar we mooie plannen maken om die vervolgens op de plank te zien belanden. Laten we gewoon de mouwen opstropen en zoals we in Rotterdam zeggen “niet lullen, maar poetsen”. Zodra klanten zien welke mooie, creatieve en waarde-toevoegende oplos-singen we niet alleen kunnen bedenken maar ook daadwerkelijk voor ze kunnen realiseren, zullen we als groep ook die waardering krijgen waar we blijkbaar zo naarstig naar op zoek zijn.

Als er iets opvalt in het IT werkveld, dan is het wel dat we termen van andere vakgebieden overnemen en daar een andere invulling aan geven. Desktop, file, statement, domain, vocabulaire. We verwarren onze omgeving ermee en uiteindelijk ook onszelf. 
 
Zo ook architect, een begrip uit de bouw. De architect is een bouwkundig ontwerper die een beeld van een gebouw creeert dat moet voldoen aan alle eisen die de opdrachtgever er aan stelt. Die architect gebruikt alle middelen om iets bijzonders te ontwerpen dat de opdrachtgever aanspreekt en waarvan de architect duidelijk kan maken dat de gewenste functionaliteit kan worden ondersteund. Als de opdrachtgever daar tevreden is zorgt de architect ervoor dat de de bouwkundige specificaties zo compleet mogelijk op papier of tegenwoordig in de computer terecht komen. Vervolgens kan het worden aanbesteed en dooe een aannemer gerealiseerd. 
 
Iedere opdrachtgever van een bouwopdracht weet precies wat hij doet als hij een architect inhuurt en doet dat bewust. In zo'n geval heeft die opdrachtgever een visie en weet dat architect hem of haar kan helpen die visie om te zetten in iets zeer bruikbaars wat ook nog eens opvalt. Als dat ontwerp is gerealiseerd -door een aannemer en ongetwijfeld allerlei onderaannemers- kunnen mensen die het zien zeggen: "wat een ... architectuur." (Vul een bijvoegelijk naamwoord in dat enige emotie uitdrukt.)  
 
Wat Wouter zegt over de IT architecten zou ik willen verbinden met termen uit de bouw: veel IT architecten die je tegenkomt zijn stadsplanners, projectontwikkelaars, aannemers, constructeurs, bouwtechnisch ingenieurs, bouwinspecteurs, betonspecialisten, timmerlieden, electriciens en loodgieters. Omdat het IT vak ook met vormgeving te makan heeft kom je ook specialisten uit dat vak tegen: ontwerpers, vormgevers, drukkers, uitgevers.  
En allemaal zijn ze in de IT architect. 
 
Een opdrachtgever die enige architect uit het IT werkveld inhuurt verwacht dat hij een helder ontwerp krijgt en dat hij praat met iemand die zijn wereld begrijpt. Althans, sommige opdrachtgevers hebben die illusie mogelijk nog, de meeste zijn in complete verwarring achtergelaten en hebben een gigantische behoefte aan enige standaard werkwijze om ervoor te zorgen dat ze krijgen wat ze nodig gebben.  
 
Onze pogingen onze taal en werkwijze voor de buitenwereld duidelijk te maken vatten we in allerlei methoden en technieken die inmiddels een halfwaardetijd hebben twee jaar. We worden doodgegooid met nieuw acroniemen die allemaal nieuwe zakken zijn voor de oude wijn. Ooit werd de snelheid van computers uitgedrukt in MIPS: millions instructions per second. De andere betekenis van die afkorting die bij een aanbestedingstraject naar boven kwam is mij beter bijgebleven: Misleading Information Provided by Salespersons. 
In de IT zijn we bezig de "E-Tower of Babel" te creeeren. 
 
En uiteindelijk hebben we het vaker over het hoe en maar weinig over het wat. En het laatste is waarom het draait: op welke manier ondersteunt een informatievoorziening de werkprocessen die met hulp van de eerste beter en sneller kunnen. Waar ik nog aan toe zou willen voegen: waar de opdrachtgever, de mensen in zijn organisatie en hun klanten ook gelukkiger van worden. 
 
Een (bouw/tuin/informatie/IT/business) architect moet zich bezig houden met de mens en zijn of haar werk- en leefruimte, want dat is hetgene dat hij creeert.  
 
Daarvoor moet hij Nederlands kunnen praten, maar ook het vakidioom kunnen gebruiken. Een architect moet ook veel kennis hebben van techniek, maar hoeft geen 2000 regels programmacode per dag te produceren, of 9 meter schoon metselwerk op te leveren. 
 
Ik ervaar dat ik als informatie architect alleen wordt opgehouden door de nieuwe acroniemen die we onze omgeving door te strot duwen.  
En tegelijkertijd moet ik met software als Word, Excel, Powerpoint en Viso mijn ontwerpen maken omdat mijn baas, meestal een aannemer, vindt dat het goedkoper en sneller kan. 
Het is de wereld op zijn kop.