Beste Pieter en Steven, 
 
Ik kies inderdaad bewust voor de rol van meester-bouwer, maar dat wil niet zeggen dat ik verander om het veranderen en geen rekening zou houden met het grotere geheel.  
 
Mijn ruimte in de rol van infrastructuur architect is in het algemeen beperkt doordat allerlei keuzes/problemen al zijn bepaald, bijv. door de enterprise architecten, applicatie architecten, informatie architecten, business cases, referentie architecturen, enzovoort. Zo kan er zijn besloten tot outsourcing, ontvlechting, invlechting, nieuwe communicatiekanalen richting klanten, nieuwe richtlijnen rond beveiliging enz. Dat zijn zaken waar ik nauwelijks tot geen invloed op kan, wil* of mag, uitoefenen. 
 
Mijn taak is dan ook vooral om ervoor om te zorgen dat de op andere niveaus gemaakte keuzes goed landen op infrastructuur/technisch niveau en daarvoor zijn veranderingen nodig, niet alleen technische, maar ook procesmatige, en veranderingen aan procedures, documentatie, organisatorisch (maar dan vooral aan de ict organisatie kant) etc. En daarbij moet ik (meestal met collega architecten) zorgen dat allerlei belangen van allerlei verschillende stakeholders zo goed mogelijk zijn gewaarborgd. 
 
Voor jullie mag dat allemaal klinken als platte technische issues die er niet toe doen vanuit business oogpunt maar ik kan jullie verzekeren dat de infrastructuur wereld ook steeds complexer wordt, en dat bij het aanbrengen van veranderingen de rol van de architect steeds belangrijker wordt gevonden. Juist omdat die kijkt naar de infrastructuur als geheel en niet alleen maar probeert dingen voor elkaar te krijgen met op zich zelf staande op korte-termijn gerichte technische oplossingen.  
 
*Pieter heeft enigszins gelijk als hij stelt dat ik mijn rol op eigen initiatief beperk. Dat is omdat ik vind dat er aan de bouw en beheerkant binnen de infrastructuurwereld veel is te verbeteren. Vandaar mijn keuze om vooral te acteren als meester-bouwer of werkvloer architect of project architect of systems engineer hoe je het ook wilt noemen. Als de term architect voor een dergelijke rol niet passend zou zijn dan vind ik de laatste term, systems engineer de meest passende term want ik draag systems engineering en systems thinking beide een warm hart toe ...

Beste Pieter, 
 
Macht is en blijft gevaarlijk… 
 
Dat jij de relatie legt tussen architectuur en ontwerp is helder. Ik heb daar moeite mee, maar dat zit niet in het feit dat ontwerp niet iets is dat hard nodig is, maar meer in het feit dat ontwerp niet de kern van de huidige problemen in de praktijk is. Misschien is dat probleem nog wel het beste aan te duiden door planologie naast ontwerp en bouwkunde te beschouwen. Vanouds spreken wij over functioneel ontwerp en technisch ontwerp. Functioneel ontwerp is daarbij het vormgeven van een oplossing voor de omgeving die hem zal gaan gebruiken, technisch ontwerp de manier zoals de oplossing werkt. Dus als je iets wil, een probleem hebt, dan kan je daarvoor een oplossing (of verandering) functioneel (en later technisch) ontwerpen. Dus bij een Bank: je gaat vorm geven aan oplossing nummer 10.001.  
 
Een totaal andere vraag is waarom je oplossing 10.001 zou willen hebben. Ik ken een Bankorganisatie waar men meer dan 30 verschillende workflow oplossingen heeft, en dat de vraag niet echt gesteld wordt waarom men de 31e zou willen (en de consequentie dat het aansluiten van die 31e op de 30 anderen zo kostbaar is…). Dus waarom zou je een nieuwe oplossing willen als je een probleem hebt? En dus ook: waarom zou je zo’n oplossing al gelijk functioneel, laat staan technisch, willen ontwerpen? 
 
Stapje hoger. Als ik Jaap zijn werk zie zie ik dat hij vaak niet over 1 oplossing nadenkt, maar over een geheel waarbinnen één of meer oplossingen zouden kunnen passen. Stapje breder (en m.i.) beter, maar m.i. nog steeds (te) beperkt: 
• Het is praktisch onmogelijk om een ontwerp te maken van behoeften aan informatie voor een omgeving. Dat betekent dat je wel opschaalt, maar nooit kompleet zult zijn en dus geen totaaloverzicht hebt.  
• Met het maken van een ontwerp maak je, ongeacht hoe vrij je het opzet, keuzes. Elke keuze beperkt. En daarmee beperk je dus je ontwikkeling naar je toekomst. 
 
Daarom zie ik architectuur en ontwerp als verschillende zaken. Architectuur voor het geheel van je gekozen werkelijkheid, ontwerp als je daar iets binnen wilt gaan veranderen. Informatiearchitectuur is dan voor mij het beeld dat een organisatie heeft van haar bedrijfsmiddel informatie in haar organisatie. Richtinggevend, maar zoveel mogelijk inrichting-vrij. Je kunt daarbij richtlijnen extra geven voor het inrichten, zoals jij met ontwerp zult bedoelen. Daarna kan je dan technologie gaan bekijken om te zien hoe oplossingen voor onderkende problemen in te zetten: dus probleemanalyse, functioneel ontwerp enz. Dus waar methoden als DYA en TOGAF rond opgezet zijn: aannemerswerk. 
 
Wat in een informatiearchitectuur hoort is op zich niet zo moeilijk te bedenken: alles wat een organisatie rond haar informatie wil bepalen en vaststellen. Informatie, dus niet technologie. Ontwerprichtlijnen (zoals ik interpreteer wat je informatiekundige ontwerpleer noemt) kunnen daarbij horen, maar zijn feitelijk 2e plan. Technische, dus IT, richtlijnen zo beperkt mogelijk, want daarmee beperk ik de nabije toekomst ook al teveel, laat staan de verdere toekomst. 
 
Je hebt gelijk in je opmerking rond de architect. Wat echt nodig is is ruimtelijk richten, en minder ruimtelijk inrichten, laat staan functioneel ontwerpen. De vele jaren dat ik nu met de term architect werk heb ik steeds het ruimtelijk richten bedoeld, en niet het functioneel ontwerpen. Daarom voeg ik ook het begrip harmonie toe aan de kenmerken van Vitruvius, iets dat in de architectuur pas zo’n 15 eeuwen na Vitruvius gedaan werd. Functioneel ontwerpen zou je in de informatie & IT-sector ook bij de aannemers, de IT-ers/IT-leveranciers kunnen laten, het ruimtelijk richten en waarschijnlijk ook het ruimtelijk inrichten kan daar niet bestaan. Simpel omdat je je hersenen en kennis niet door een derde kunt laten beheren, dat moet je zelf doen. En daarmee komen we dan in een terminologische tweespalt, want in de bouw is een architect dan iemand die echt los van de aannemer hoort, terwijl de functioneel ontwerper in de informatie & IT-sector best wel eens gecombineerd kan worden. Bijvoorbeeld zoals Sogeti bij Capgemini hoort. Voor ruimtelijke richten en ruimtelijk inrichten kan dat absoluut niet. Vraag los van aanbod, anders krijg je snel grote problemen. 
 
Ja, de bewijsvoering van John Sowa, hoewel kompleet, schiet tekort omdat er een premisse onder ligt die niet juist is: alles zou een object zijn. Dat is ook de reden waarom dat ISO 14481 nooit verder is gekomen dan een Final CD. Dat wil niet zeggen dat de inhoud niet goed is, er waren in 1999 alleen 2 stromingen die niet bij elkaar konden komen: praktijk en theorie. 
 
Neen, ik wijs TOGAF niet af zoals je denkt. Waar ik niets mee kan is met de haast agressie waarmee groepen mensen met zoiets als TOGAF omgaan, wat jij sektarisch noemt. Om TOGAF en haar community beter te leren ben ik 2 keer een week naar de States geweest om een conferentie erover bij te wonen (en om te spreken) in Miami (3 jaar geleden) en San Francisco (1½ jaar geleden). Daar heb ik de vorming van de community rond TOGAF gezien. Gesloten, later bijna agressief, commercieel en weinig aansprekend voor de mensen die tijdens de bijeenkomsten probeerden uit te vinden wat het nu eigenlijk is, waar TOGAF om gaat. Daarom ook mijn vergelijking met SDM en het geld dat Capgemini daar jaren mee verdiend heeft. En als ik dan in mijn praktijk kijk, dan zie ik de toegevoegde waarde van TOGAF gewoon niet. Ik zie organisaties die om te beginnen een jaar of 4 een team van 5 tot 15 externen hebben die de Sisyfus-klus deden om alles te beschrijven. Een soort van wat we vroeger informatieplan noemden, maar dan nu onder de kreet enterprise architectuur. Verouderd zodra het opgeschreven is, en nauwelijks nog bij te houden (ongeacht eventuele tools) als het “af” zou zijn (wat het nooit kan zijn). En ja, met dat soort verbranden van geld heb ik moeite.  
Dan een veel ernstiger punt: het nut en de toegevoegde waarde. Waarom zou je zoveel centraal van je IT willen opschrijven, en nog steeds zo weinig over je informatie. IT verandert snel, dus ook de beschrijving ervan. En waarom zou je dan vele fte’s willen zetten op iets dat niet anders dan altijd verouderd kan zijn, en verouderd zal blijven.  
En dan nog de push van IT om het allemaal te gaan doen. Typisch blauw gedrag. En als het af is en het niet voldoet, dan gaan we weer gewoon door met het volgende. Zonder consequenties, zonder dat iemand er de vinger op kan leggen. Jammer, maar helaas. Maar we verdienen er wel lekker aan. 
Ben ik daarom tegen TOGAF? Nee, hoe kan je tegen een methode zijn. Ik heb wel grote bedenkingen tegen wat het beoogd te doen. Maar dat heb ik tegen vrijwel iedere van de huidige “architectuurmethoden”, gewoon omdat de praktijk bewijst dat het meeste uiteindelijk lood om oud ijzer zijn. 
 
Pieter, ik heb al eerder een discussie met je afgebroken omdat je te grof werd. Nu verwijt je mij dat ik je documenten nog niet gelezen heb en eis je van me dat ik dat doe voordat jij me een discussie waard vindt. Het probleem is dat zoveel mensen binnen IT, al of niet in groepen, van zichzelf vindt dat hij/zij de oplossing voor alles heeft, en de denkwijze die iedereen zou moeten hebben. Als je weinig tijd hebt zijn er simpele manieren om vast te stellen of dat inderdaad het geval is. Noem het een lakmoesproef. Weet je, als iemand me niet echt kan interesseren in dit soort discussies zie ik geen reden om de (vaak vele) schrijfselen van zo iemand (of groep) te gaan lezen. Ik merk bij jou dat je steeds weer teruggrijpt op dingen die je ooit geschreven hebt, en dat je dan zelf vaststelt dat het toch wel erg goed was en dat je er niets aan wilt/gaat veranderen. Prima hoor, maar geen aantekening voor de kwaliteit ervan in mijn ogen. Als het bovenstaande niet al te ver af is van jou werkelijkheid, exclusief mijn opmerkingen daarover natuurlijk, dan weet ik je te plaatsen en te vinden als dat nodig is. Maar als jij niet zonder referenties naar jezelf of naar wat anderen een keer opgeschreven hebben kunt vertellen wie je bent en wat je ideeën zijn, dan laat ik het hier nog maar bij. Je verwijt laat ik deze keer voor wat het is. 
 
Steven van ’t Veld 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken

Blijkbaar waren Steven van ’t Veld en ik gelijktijdig aan het schrijven. Wat hieronder allereerst volgt is wat ik schreef, vóórdat ik zijn reactie getimed op 18:36 uur op 23 april 2009 las. Daarin wijzigde ik nav zijn genoemde reactie niets. Verderop markeer ik duidelijk vanaf welk punt ik wèl inga op die reactie. 
 
Peter Bakker vermeldt allerlei soorten architect. Als dat nu mode is, dus dat elke specialist zich graag architect noemt, vooruit. Maar hoe noemen we dan iemand die overzicht, coördinatie e.d. tot haar/zijn, oeps, specifieke verantwoordelijkheid rekent? Eerlijk is eerlijk, ooit deed de slimste timmerman dat erbij. Zo werd z/hij hoofdtimmerman en vandaar architect. In die historische zin maakt Bakker als “meester-bouwer” terecht aanspraak op die aanduiding. 
Maar goed, ambachtelijke bemoeienis met onlosmakelijkheid van aspecten van dien blijkt voor allerlei opgaven niet te voldoen. Dat leidde tot verdeling van activiteiten. Vaak geldt daarvoor onderscheid tussen, zeg maar, verzinnen (lees ook: ontwerpen) en uitvoeren (lees ook: construeren). Nota bene, dat biedt allerminst een zuivere oplossing, maar roept op haar beurt altijd nieuwe problemen op. Daarover gaat volgens mij deze discussie ook! 
In betekenis, althans voor de alsmaar complexere gebouwde omgeving, verhuisde de term architect ooit naar de ontwerpkant. Zo beschouwd kan het inmiddels aanleiding tot verwarring geven door iemand die vooral uitvoerend bijdraagt (nog) architect te noemen. 
Overigens bestaat voor gebouwde omgeving aan de ontwerpkant allang weer een nadere indeling van … specialisaties. Zie ook Architekten und ihre beruflichen Perspektiven (DVA, 1982, oorspronkelijk verschenen als proefschrift) door G. Feldhusen. Wie zich daar architect noemt, werkt overwegend op de schaal van het enkele gebouw. Opmerkelijk genoeg zien ontwerpers op de schaal van de stad, en verder, er bij nader inzien opzettelijk vanàf zich als architect te afficheren. Zij heten stedebouwkundigen, zoals ondermeer onderstreept staat in Stedelijke Transformaties: Actuele opgaven in de stad en de rol van de stedebouwkundige discipline (Hulsbergen, E. en H. Meyer, samenstellers, Delftse Universitaire Pers, 1998). En uiteraard vertonen die ruimtelijke schalen wisselwerking. Er is navenant behoefte aan — borging van — oriëntatie door de schalen héén, zoals dat daar zo mooi heet. Wie rekent dàt tot haar/zijn taak? De ruimste schaal waarop in formele zin planning (in dit verband een ander woord voor ontwerp) aan de orde is, bestaat uit ruimtelijke ordening op nationale schaal. 
Langs informele(re) ‘weg’ zijn we die schaal voor informatieverkeer eigenlijk allang overstegen. Het Internet is wereldwijd. 
Maar terug aan de uitvoeringskant, nee, routinematig is weer heel iets anders. Ook (juist?!) zgn uitvoering is steeds vaker hoogst gespecialiseerd, kortom vergt keuzes, zeg gerust maar ruime ontwerpvrijheid van de betrokken specialist. Dat pleit dus weer vóór aanduiding als architect. 
 
Daar komen we dus niet meer uit. Het recht van de ene beroepsgroep om zich architect te noemen kan redelijkerwijs nooit (meer) inhouden dat het een andere beroepsgroep verboden is. Naar mijn idee is wat Bakker doet daarom optimaal. Hij verduidelijkt wat hij bedoelt. Dat lukt dankzij context, zoals Paul Jansen nogmaals benadrukt. 
Zo verduidelijkt ook Steven van ’t Veld hoe hij zijn bemoeienis opvat. Zij het impliciet verkrijgt hij daarvoor zeker erkenning door Bakker. De bepèrking die Bakker voor zijn professionele bijdragen schetst, mag Van ’t Veld vervolgens gerust óók beschouwen als diens erkenning van de betrekkelijke waarde van — zoiets als — Togaf. 
Met dank aan Jansen voor diens aanzet(ten), indien Bakker en Van ’t Veld zich allebei kunnen vinden in erkenning van hun karakteristieke verschillen, zijn we toch een stuk verder dan Daan Rijsenbrij voorstelt in de column (30 maart 2009) waarmee hij deze discussie startte. Daar schrijft hij als “[z]ijn advies [om] te stoppen met dit initiatief [Togaf] en een (wereld)standaard te ontwikkelen vanuit de vraagkant.” In de eerste plaats kunnen we Togaf wie weet zelfs toejuichen, maar dan wèl volgens reële verwachtingen, maw opbouwend gepositioneerd. Ten tweede blijkt volgens mij hier uit de diverse reacties die, opnieuw in mijn termen, accent op ontwerp leggen dat een vraagstandaard zelfs een contradictio in terminis is. Het heeft even wat tijd gekost, ;-) maar tegen Rijsenbrij’s oorspronkelijke conclusie lijken mij aldus verzameld voldoende argumenten te zijn opgeworpen. 
 
Dankzij Van ’t Velds laatste paar bijdragen meen ik voorts scherper zicht gekregen te hebben waarover hij zich druk maakt. Dat is de aanspraak op hegemonie met bijhorend gevaar van onderdrukking van nuance enzovoort. Als ik dat juist zie, schaar ik me graag aan zijn kant als tegenstander van zulke aanspraak. 
Het klopt niet, is zelfs een ronduit vàlse pretentie, indien welk raamwerk, welke methode dan ook voorgesteld is als borg van totale beheersing. Ik vermoed dat Van ’t Veld bezorgd is dat het effect tegenovergesteld is. Met een Duits neologisme zou ik dat werkelijke effect Übermobilmachung willen noemen. Ofwel, veranderingen slaan op hol. Ik ben het er weer helemaal mee eens, als Van ’t Veld bedoelt dat zulk gevaar reëel is door (te) eenzijdige aandacht voor veranderingen. 
 
De synthese is echter moeilijk herkenbaar, doordat Van ’t Veld op zijn beurt ook een ènkele term benut: stabiliteit. Hij bedoelt dat helemaal niet anti-verandering, maar wat hij er wèl mee wil zeggen blijft m.i. wat verhuld. 
De aanduiding die ik productief acht, luidt dynamisch evenwicht. Hierin ligt de nadruk op evenwicht, want dat staat er als het zelfstandig naamwoord. Maar zulk evenwicht is natuurlijk niet statisch! Werkelijkheid is tijd en daarmee veranderlijk. Het professionele doél is echter nooit de dynamiek zèlf. De tandarts geeft zijn klant na behandeling ook geen snoepgoed mee waardoor gaten in tanden en kiezen sneller vallen dat z/hij ze kan vullen. 
Wanneer Van ’t Veld zijn achterdocht wil uitdrukken tegen (markt)partijen die dynamiek-om-de-dynamiek willen aanjagen en zodoende daarentegen juist evenwicht ontwrichten, ja, dat signaal versterk ik graag. Evenwichtige dynamiek is valse retoriek. In dit geval moeten we niet op de boodschap, maar juist wèl op de boodschapper mikken. Want er zitten altijd mensen achter, die echter vaak niet eens beseffen hoe kwalijk hun schijnbewegingen uitpakken (zoals inderdaad de zgn financiële crisis maar weer eens illustreert). Togaf is het wezenlijke probleem daarom niet. Sterker nog, waarom zou het geen prima middel bieden voor geselecteerde activiteiten? 
 
Dat is naar mijn oordeel ook wat Erik Proper vergeet. Zijn oproep tot deugdelijke toetsing van Togaf verdient uiteraard volle instemming. Maar wat stelt hij als toetsingskader voor? Met andere woorden, precies wèlke activiteiten komen in aanmerking om ermee te verrichten? 
In Propers aparte oproep elders op VNA las ik dat hij een methode associeert met “to achieve X.” Daaraan meen ik vlot te herkennen hoe hij er letterlijk ‘in’ zit. Proper kent voor zijn toets van Togaf oid. immers op voorhand een doel, dat is X. Dan gaat het vervolgens inderdaad om uitvoering. Maar wie heeft ooit bedacht en zo door naar ertoe besloten dat X het doel is en niet bijvoorbeeld Y? 
Van ’t Veld wijst er m.i. terecht op dat zulke doelstelling veeleer nadruk op, hier dus in mijn vervangende terminologie, dynamisch evenwicht verlangt. Dat moet je inderdaad maar kunnen. Zachtjes uitgedrukt is twijfel gerechtvaardigd, of je daarvoor moet zijn bij commerciële partijen met een nadrukkelijk éénzijdig eigenbelang bij veranderingsprocessen. 
 
Vroeg of laat moet het dus om een beroepsethiek gaan, met alle zèlfbeperking door nota bene de dienstverlener van dien. In een afhankelijkheidsrelatie moet de klant er zelfs èxtra op kunnen vertrouwen dat de professionele dienstverlener in voldoende mate het klantperspectief kiest en haar/hem eventueel ook begeleidt tot inzicht in relevant dynamisch evenwicht. Dankzij de vertrouwensrelatie groeit doorgaans pas in wisselwerking realiteitszin. Dat is pas een heuse X-factor. 
 
… en toen wilde ik bovenstaande tekst (uiteraard met uitzondering van de later toegevoegde aanhef) als reactie plaatsen. Steven van ’t Veld was mij vóór met een reactie die hij aan mij richtte. Hartelijk bedankt ervoor. 
 
Ik het bovenstaande ben ik volgens mij al ingegaan op diverse thema’s die Van ’t Veld (verder) aansnijdt. Zo vermeldt Van ’t Veld “planologie” en dat weerspiegelt inderdaad een ruimere ordeningsschaal. 
Waarop ik verder graag reageer is dat Van ’t Veld en ik blijkbaar zéér sterk afwijkende ontwerpbegrippen hanteren. Ik proef dat hij er een beperking aan geeft, die ik juist niet zie. Context, dus. Hopelijk helpt de samenstelling dynamisch evenwicht te verduidelijken dat vanwege zijn inherente dynamiek dat evenwicht continue onderwerp van ontwerp moet zijn. In die zijn komen ontwerp en onderhoud sterk overeen. Volgens mij vindt Van ’t Veld dat ook, maar noemt hij dàt architectuur. Als dat zo is, zijn we het dus over strekking eens. 
Ik begrijp ons misverstand tot dusver, als het zo is dat Van ’t Veld de gebruikelijke indeling in de anglo-saksische landen volgt. Daar komt analyse vóór ontwerp. Dat zie ik dus òmgekeerd. Dan kan Van ’t Veld het hinderlijk vinden dat ik daarvoor verwijs naar eerdere publicaties (waarin ik die omkering schets), maar hoe ziet hij vakontwikkeling ànders dan via uitspraken toetsbaar krijgen door ze allereerst maar eens te documenteren? Daarin heeft Erik Proper m.i. volstrekt gelijk. 
Nee, ik voel me allerminst aangesproken dat ik “vorm [ga] geven aan oplossing nummer 10.001.” Het is, opnieuw, zelfs uitdrukkelijk òmgekeerd. Het paradigma van civiele informatiekunde is immers wezenlijk infrastructureel voor informatieverkeer. Als Van ‘t Veld al schalen wilt vergelijken, maak ik uit zijn teksten op dat hij overwegend de organisatorische kiest terwijl ik bewust door-de-schalen-heen tot en met nadrukkelijk op de maatschappelijke mik. Overigens kan ik me prima voorstellen dat er ooit een versie van Togaf komt die bepaalde uitvoeringsaspecten ook op die schaal dekt. 
Je hebt gelijk: “Het is praktisch onmogelijk om een ontwerp te maken van behoeften aan informatie voor een omgeving. Dat betekent dat je wel opschaalt, maar nooit kompleet zult zijn en dus geen totaaloverzicht hebt.” Daarom gebeurt dat volgens civiele informatiekunde ook niet. Met focus op infrastructuur, niet beperkt tot wat techniek in een aparte organisatie, maar voor informatieverkeer op maatschappelijke schaal lukt dat wèl. Ik ben inderdaad zo “grof” om je voor nader inzicht naar verdere publicaties te verwijzen. Maar, nee hoor, ik “verwijt” Van ‘t Veld in dat opzicht helemaal niets. Ik betreur zijn desinteresse slechts, dat natuurlijk wel. 
Wellicht kan Van ‘t Veld ooit toelichten wat op mij overkomt als een allergie voor literatuurstudie. Het lijkt erop dat hij de gedachtesprong maakt dat iemand die zich aan zijn adres zelfs maar waagt aan een verwijzing “van zichzelf vindt dat hij/zij de oplossing voor alles heeft, en de denkwijze die iedereen zou moeten hebben.” In elk geval voel ik mij opnieuw allesbehalve aangesproken, integendeel zelfs. Zoals ikzelf het zie, doe ik moeite om redelijke, dus onderling afhankelijke positioneringen voor mensen en methoden te bepleiten. Aan Van ’t Veld lijkt het allemaal echter minder besteed. Hoe ik nòg duidelijker kan helpen, zoals Jan van Til eerder deed, om juist voor zijn opvatting erkenning te verkrijgen, weet ik zo gauw niet. 
Nee, met informatiekundige ontwerpleer bedoel ik geen “ontwerprichtlijnen.” Wat dan wel? Ik durf het Van ’t Veld bijna niet te suggereren, maar lees het boek eens met de gelijknamige titel (ook beschikbaar op het ww web). Daarin staat ondermeer een fictief vraaggesprek met Jean-Paul Sartre over verantwoordelijkheid. Niet-kiezen is altijd óók een keuze stelt hij en volgens mij doet hij dat terecht. Daarom maakt Van ’t Veld zich volgens mij nog valse illusies over vrijheid als het ontwijken van beperkingen voor ontwikkeling. Dat ruimste, want existentialistische ontwerpbegrip vind ik vruchtbaar werken.

Van vele kanten heb ik zowel in deze discussie als via e-mails de vraag gekregen waarom ik niet (meer) reageer in de onderhavige discussie 
 
Ik was nogal overrompeld door het commentaar van Ron Tolido en Erik Proper op 9 april: ‘Daan Rijsenbrij bewijst met zijn column dat er nog steeds genoeg architecten zijn die liever over architectuur kissebissen dan dat ze er feitelijk een maken’. Weliswaar heeft de redactie van Via Nova Architectura gemeend daar een kanttekening onder te moeten plaatsen, maar ik heb van genoemde heren nog geen enkel excuus mogen vernemen. 
 
Ik heb mij kwetsbaar opgesteld door een duidelijke mening over TOGAF te poneren. Als reactie daarop komt een zeer korte, duidelijk op de persoon bedoelde aanval met als enig doel mij belachelijk te maken. Ik heb in eerste instantie geen enkele reactie vanuit de redactie gezien. Is het dan vreemd dat ik 48 uur later en vele e-mails waarin aan mij off line de afschuw wordt uitgesproken over de onderhavige reactie door Capgemini, in de verleiding ben gekomen een lichte steek onder water te geven: ‘…..was dat jouw (bedoeld werd Ron Tolido) prijs voor het board membership van The Open Group’.  
Het is mij niet duidelijk welke persoonlijke aanvallen de redactie heeft onderkend in mijn posting waaronder zij hun disclaimer hebben geplaatst. Omdat ik niet de aanstichter ben, had ik het charmanter gevonden als de redactie een wat genuanceerdere tekst onder mijn posting had geplaatst, zoiets als: ‘Hoewel de redactie zich kan voorstellen dat de heer Rijsenbrij in de verleiding is gekomen Ron Tolido wat persoonlijker aan te spreken, wil zij nadrukkelijk stellen dat zij vindt dat dit commentaar elementen bevat die tegen de blog etiquette van Via Nova Architectura indruisen’. 
Ik heb er geen probleem mee mij kwetsbaar op te stellen, omdat mijn stellingnamen de toets der kritiek kunnen doorstaan. Maar dan denk ik wel recht te hebben op positief kritische opmerkingen en geen denigrerende losse flodders. 
 
Vervolgens werd ik verrast door de posting van Erik Proper op 22 april: ‘Aangezien mijn blog posting "off topic" is m.b.t. de door Daan Rijsenbrij gestarte discussie, zal ik hier niet reageren op comments op mijn blog entry. De blog staat inmiddels zowel op mijn VNA blog als mijn eigen blog. Op commentaren op die plekken zal ik reageren’. 
Ik vind het nogal brutaal dat Erik Proper in een discussie waar hij en zijn andere collegae van Capgemini systematisch weigeren deel te nemen, ineens opduikt met de bedoeling de deelnemers naar zijn eigen blogs te verleiden. Hoort dit tot de hedendaagse blog etiquette van de jonge generatie? Ik zag dat Pieter Wisse ook al zijn wenkbrauwen fronste over dit gedrag. 
 
Bovenstaande voorvallen hadden mij de lust ontnomen verder te participeren in de discussie die ik zelf had aangezwengeld. Maar Pieter Wisse en vele anderen hebben gelijk met de opmerking dat ik hoor te reageren omdat ik de knuppel in het hoenderhoek heb gegooid. 
 
Overigens wil ik opmerken dat ik geen persoonlijke onenigheden heb met mijn voormalige werkgever Capgemini, doch ik houd mij het recht voor om misstanden in de IT aan de kaak te stellen. 
Op mijn vraag op 1 april of Capgemini waar de TOGAF docenten Mieke Mahakena en Dave van Gelder werken zelf wel een architectuur heeft, heb ik nog steeds geen antwoord gekregen. Je mag toch aannemen als je wereldwijd TOGAF zo fanatiek propageert, dat de directie van je onderneming toch een architectuur voor de eigen onderneming heeft laten opstellen conform TOGAF 9.0, of niet soms? 
Ik, en waarschijnlijk vele lezers van deze discussie, zouden graag na al het theoretisch gedoe over TOGAF wel eens een real life voorbeeld willen zien. Dus, Capgemini publiceer s.v.p. jullie TOGAF-conforme architectuur op Via Nova Architectura.

Samenvatting tot nu toe 
 
Het is voor mij bijzonder moeilijk om een uitgebalanceerde samenvatting te geven van de uiterst interessante discussie over de pro’s en contra’s van TOGAF 9.0. Daarnaast ontvouwde zich een discussie over wat er zou moeten zijn in plaats van TOGAF. Deze discussie is zeer inspirerend, maar nog te divers om in enkele woorden samen te vatten. 
Kortom, moeilijk om iets compacts te formuleren. Vandaar een subjectieve sfeertekening, gevolgd door enkele conclusies en enige aanbevelingen. 
 
 
Sfeertekening: 
 
Het is duidelijk dat er veel goed onderbouwde kritiek is op TOGAF 9.0, maar uit het kamp van de voorstanders is het ijzingwekkend stil. Mogen zij niets zeggen, willen zij niets zeggen of zijn zij het diep in hun hart roerend eens met de kritieken die in deze discussie zijn geuit over TOGAF 9.0? 
 
Op 30 maart merkte Danny Greefhorst terecht op: ‘Ik ben het met Daan eens dat TOGAF de scherpte mist die wenselijk is en dat de oorzaak ongetwijfeld ligt in het standaardisatieproces’ en ‘Het is lastig om te bepalen wat de essentie is tussen al die interessante zaken’. 
 
Op 31 maart constateerde Paul Jansen dat TOGAF 9.0 een bouwers product is met hier en daar de eerste tekenen van holistische, creatieve en contextgedreven elementen. 
 
Hans Bot mijmerde op 31 maart: ‘Als ik nu sentimenten en argumenten in de discussie probeer te scheiden, dan lees ik een flinke dosis kritiek op de scope van TOGAF. Veel van die kritiek ben ik geneigd te delen: enige bescheidenheid zou de architectencommunity geen kwaad doen - zeker gelet op de resultaten die tot dusverre zijn geboekt’. Voorts stelde hij dat: ‘Hier wreekt zich naar mijn idee het ontbreken van een professionele, internationale, leveranciersonafhankelijke architectuurcommunity, waarin professionele architecten uit alle NAF-pijlers vertegenwoordigd zijn, die met voldoende autoriteit een standaard methodiek voor het vakgebied zou kunnen ontwikkelen’. 
 
Bijzonder treffend vind ik de opmerking van Steven van ’t Veld op 31 maart: ‘Als ik de externe versies van SDM goed geteld heb, zou TOGAF gezien kunnen worden als SDM versie 6 of misschien 7. Het is een reeks zich herhalende stappen die tracht steeds meer informatie te verzamelen over een IT-omgeving, om die als kennis vast te leggen’.  
Voorts ziet hij net als ik een TOGAF-sekte ontstaan. Hij vervolgde met: ‘Dat roept bij mij beelden op die ook tussen 1975 en 1985 rond SDM versies 1 en 2 ontstonden. Klopt ook wel, want, zoals gezegd, is TOGAF voor mij zoiets als versie 6 (of toch 7?) van SDM. Ook TOGAF richt zich voornamelijk op IT ontwikkeling en dat is gemiddeld toch maar 20% van alle geld dat aan IT uitgegeven wordt’. Interessant is zijn constatering: ‘weinig is meer gesloten dan The Open Group, en dus ook TOGAF’. 
 
Pieter Wisse stelde op 2 april: ‘Ik ben inderdaad eerder geneigd TOGAF met ITIL te vergelijken’ en ‘Psychoanalytisch bekeken zou TOGAF wel eens een uitdrukking van angst voor het onbekende kunnen zijn’. 
 
Ten slotte concludeerde Paul Jansen op 23 april: ‘Zijn we het vervolgens niet juist allen volledig met elkaar eens dat TOGAF niet gelijk is aan architectuur?! En, dat iedereen die beweert dat je voldoende hebt aan een inbussleutel (TOGAF) of alleen een schroevendraaier (DYA) om ‘meubels te maken’ blijk geeft de weidse wereld van meubels buiten IKEA niet te (willen) kennen’. En ‘Daarom is er een toenemende behoefte aan die ‘andere’ architecten, voor wie dus TOGAF geen (goede) oplossing biedt’. 
 
 
Conclusies: 
 
Terecht merkten velen op dat het de hoogste tijd wordt dat de ideeën over informatiekunde van Jaap van Rees worden afgestoft en worden geactualiseerd met de vele waardevolle zaken die ik heb zien langskomen in deze discussie. In de huidige praktijk lijkt de informatisering van ondernemingen niet te worden begeleid door informatiekundigen (of echte architecten), maar te worden geforceerd door technisch georiënteerde informatici. Jammer, daar lijden we al ruim 40 jaar onder. Wat hebben al die leergangen BIK aan universiteiten ons eigenlijk opgeleverd? 
 
In mijn reactie op Paul Jansen stelde ik op 1 april: ‘Je hebt gelijk, we hebben nog een hele weg te gaan voordat tussen de (business-)opdrachtgever van een IT-project of een groot verandertraject met een zware IT-component enerzijds en de bouwer anderzijds een onafhankelijke architect wordt geplaatst die aan de kant van die opdrachtgever staat en de werkelijke vraag/behoefte van die opdrachtgever accentueert. Het wordt hoog tijd dat er een emancipatie komt van de architect’. 
 
De ontnuchterende constatering van Steven in ’t Veld op 1 april zou meer ter harte dienen te worden genomen: ‘Veranderen is het doel van IT-leveranciers. Daar verdienen zij immers geld aan. Voor organisaties gaat het echter alleen om een voldoende effectieve informatievoorziening. En die moet liefst zo min mogelijk veranderen als die voldoet, want alleen zo kan die organisatie zich zo goed mogelijk op haar werkelijke taken concentreren: bankieren, rail exploiteren, handel drijven en wat verder nog’. 
Deze conclusie zou het startpunt kunnen zijn voor een meer volwassen wijze om met IT om te gaan. Het is immers zo simpel: we hebben business en IT. In de eerste plaats willen we een effectieve business. Op de tweede plaats willen we dat die business efficiënt is, hiervoor is meestal ondersteuning van IT nodig is. Dus op de derde plaats willen we een effectieve IT-ondersteuning. En ten slotte willen we op de vierde plaats dat die IT efficiënt is. Dat dient de juiste volgorde te zijn die moet worden nagestreefd. Doch het heeft er nu alle schijn van dat veel softwarehuizen en pakketleveranciers bezig zijn een efficiënte IT te propageren, totaal voorbijgaand aan het feit dat IT bedoeld was voor een effectieve bedrijfsvoering. Kortom, in veel gevallen hebben we te maken met een verheerlijking van een suboptimalisatie op IT niveau. 
 
Ik onderschrijf volledig de conclusie van Steven in ’t Veld op 23 april: ‘Maar zolang wij SDM-achtige molochen als TOGAF, DYA en andere architectuurmethoden willen blijven pushen, komen we geen stap verder. Simpelweg omdat als je echt kijkt naar wat het kan en doet, de complexiteit ineens extreem groter maakt.’ 
 
De conclusie van Peter Bakker op 2 april lijkt mij zeer plausibel: ‘Volgens mij maak je het architectuurvak niet volwassener met zoiets als TOGAF of welk architectuurraamwerk dan ook. Volgens mij zou het vakgebied pas volwassen zijn als architecten ook aansprakelijk gesteld kunnen worden voor gebreken in hun gerealiseerde ontwerpen’. 
 
Pieter Wisse concludeerde op 23 april net als ik dat er best waardevolle zaken in TOGAF zitten: ‘Togaf, prima, maar ‘slechts’ voor zus-en-zo’. 
 
 
Aanbeveling: 
 
1. Resultaatgerichte informatisering van de onderneming. 
Jaap van Rees zei in een bijna vergeten verleden: ‘de methode doet het niet’. Zeker, het zijn de vakmensen die het moeten doen. Ik zou vier essentiële rollen willen onderscheiden: de opdrachtgever (natuurlijk uit de business), de architect (geruggensteund door engineers), de bouwer (inclusief zijn eigen engineers) en de eventuele toeleveranciers (zoals Oracle, SAP, Microsoft, Google, servicesproviders). 
Ik ben persoonlijk niet zo geïnteresseerd in de wijze waarop deze essentiële rollen hun werkzaamheden verrichten. Ik wil wel van te voren weten welke resultaten zij opleveren. Daarom pleit ik er al jaren voor dat er duidelijke resultaten (documenten) worden gedefinieerd voor de communicatie tussen die rollen en wellicht ook binnen die rollen. 
De architect maakt documenten die hij gebruikt in de communicatie met de opdrachtgever. Hij maakt andersoortige documenten voor de communicatie met andere architecten en met de te raadplegen engineers. Ten slotte maakt hij documenten die nodig zijn om de bouwer te tonen wat er moet worden gebouwd. Dit zijn drie essentieel verschillende soorten documenten. 
 
2. Een nieuw alomvattend denkkader voor architectuur, engineer en bouw. 
Op grond van de vele waardevolle bijdragen, in het bijzonder van Hans Bot, Jan van Til, Paul Jansen, Peter Bakker, Pieter Wisse en Steven van ’t Veld, zou ik wil pleiten voor een fundamentele herbezinning op het SDM-denken, of dat nu lineair is, iteratief, incrementeel of welke andere ontwikkelstrategie dan ook. 
Reeds in mijn posting op 3 april bepleitte ik dat er behoefte is aan een breder denkkader voor ‘architectuur + engineering’ waarin TOGAF eventueel kan worden gepositioneerd. Persoonlijk onderscheid ik een vraagkant die in de business ligt en een aanbodkant die in de technologie kan liggen. Ik zou architectuur willen reserveren voor de vraagkant en aan de aanbodkant de term engineering of desnoods IT-architectuur willen gebruiken.  
De knip tussen (business-)opdrachtgever en bouwer hoort pas te liggen na de functionele specificaties. De architect zorgt voor of begeleidt de architectuurfase, het functioneel ontwerp en de functionele specificaties. Dat laatste document hoort te kunnen leiden tot een bouwbare opdracht. 
 
3. Een strikte functiescheiding tussen architecten en engineers. 
Laten we voor de eenvoud architecten weer architecten noemen, en engineers weer engineers. Nu gooien we appels en peren door elkaar. En natuurlijk, het is allemaal fruit maar voor de klant is het wel zo plezierig dat als hij een appel wil ook een appel krijgt en niet een peer. Goede, creatieve architecten zijn zeldzaam. Maar een vakbekwame engineer is wellicht nog zeldzamer. Dus, heren en dames engineers wees er trots op engineer te zijn en noem jezelf geen architect. Architecten, zorg dat je informatie inwint bij vakbekwame engineers om te borgen dat je bouwopdracht bouwbaar is. En, engineers probeer de taal van de architecten te verstaan.

Beste mensen, een korte reactie. Ik voel me uitgedaagd om volgende week een blog te schrijven waarin ik toch wat concreter probeer te zijn over hoe we de evaluatie van methoden concreet kunnen aanpakken. Liefst ook op een dusdanige manier dat het mogelijk wordt om de diverse hypothesen die in de afgelopen reacties heen/weer zijn gegaan zouden kunnen toetsen.  
 
Nog even een reactie op het "achieve X" gebeuren. Nergens noem ik dat X een specifiek punt. Die X mag best verwijzen naar een bewegend doelwit zijn. Dus bijvoorbeeld "zorg dat er de informatievoorziening zodanig wordt vormgegeven of ingekaderd, dat deze voldoende bij de bedrijfsdoelen aansluit", zou zo'n X kunnen zijn. En ja ... bij aanvang zou het maar eens zo kunnen zijn dat je de langere termijn bedrijfsdoelen nog niet helder hebt.  
 
Mijn veronderstelling is dat je met het verrichten van werk altijd iets wilt bereiken. Vanuit die veronderstelling wil ik me dus afvragen of de manier/aanpak/methode waarop je dat werk verricht het meest effectief en efficient is. Dat geldt voor methoden, maar ook voor de methoden-vrije wijze waarop Pieter en Steven wellicht soms/altijd werken.

Beste Paul, 
 
Dank voor je vriendelijke woorden.  
 
Ja, het gaat om, als ik dat woord goed begrijp, om beschouwingshouding en niet zozeer over scope. Beschouwingshouding zou ik zelf graag relateren aan discipline, vak. Een jurist beschouwd de wereld immers anders dan een PZ-mens; andere dingen zijn belangrijk, of dezelfde dingen worden anders beschouwd. Een personeelscontract is voor PZ een overeenkomst die ervoor moet zorgen dan een mens dingen doet voor een organisatie, terwijl de jurist datzelfde contract ziet als een set voor de wet al of niet afdwingbare regels. De jurist kijkt naar wat gebeurt na een ontslag, de PZ-mens wil dat iemand het juiste werk gaat doen. En dus je en/en, want samen kunnen de jurist en de PZ-mens bij een aanname sluitend werk verrichten voor de organisatie. 
 
In de 80-er jaren is door voorzitter Joost van Griethuysen een mooie combinatie van viewpoints, beschouwingsmanieren, neergelegd binnen de ISO standaardisatie activiteit Open Distributed Processing (ODP, ISO-10476 Reference Model ODP = RM-ODP): enterprise, information, computational (applications and data), engineering en technology. Zoals blijkt is elk van deze 5 de manier van beschouwen van mensen met een bepaalde opleiding, vorming en ervaring. ODP is, hoe we er ook voor gevochten hebben om meer te doen, feitelijk nooit verder gekomen dan het computational en engineering viewpoint. Waarom: de standaardisatiegroep bevatte vooral IT-ers die veel van applicaties, databases en systeemsoftware afwisten. Toen deze mensen rond 1990 probeerden te kijken naar het information viewpoint kwam men niet verder dan dat het daar om policies moest gaan, principes. Waarom? Simpel, dat is wat zij nodig hadden om te kunnen werken in hun viewpoints. Wat ook bleek was dat deze mensen niet te stuiten waren in hun mening dat zij gelijk hadden met wat mensen met de andere viewpoints dachten en moesten doen. De PZ-mens die vertelt hoe de jurist moet denken en werken.  
 
In termen van RM-ODP gaan TOGAF, DYA en vele andere architectuurmethoden over wat via de computational en engineering viewpoints gezien wordt. Ik gaf net aan dat het wel en/en is. Want wie weet hoe de organisatie werkt, het enterprise viewpoint, en wie weet welke informatie binnen die organisatie hoort, het information viewpoint, leggen samen de basis voor een passende IT-infrastructuur.  
Als je nu naar TOGAF kijkt worden er enorme discussies over business analysis gevoerd. Door mensen die een computational, engineering of zelfs technology viewpoint hebben. Technologen die opleggen via een, wat ze noemen, de-facto standaard hoe mensen in andere disciplines moeten werken en denken. En omdat mensen met een information viewpoint vrijwel nergens opgeleid en gevormd worden komen ze nog een eind ook. Fouten worden hen zelfs vergeven, want er is immers niemand anders. Maar wil nog niet zeggen dat ze daarmee gelijk hebben, en dat ze weten hoe dat andere vakgebied in elkaar zit. Ik ga als informatiekundige toch ook geen bankproducten en diensten formuleren omdat ik er ook wel ideeën over heb? 
 
Ik ben het dus in grote lijnen met je eens, Paul. Zoals schoenmakers zich bij hun leest moeten houden, zo zullen IT-ers dat moeten doen, net als informatiekundigen en bedrijfskundigen. Maar wel samen, en/en dus, want daar zit juist de synergie. Zoals eerder gezegd, de eerste stap daarvoor is respect voor elkaar, en elkaars denken. Andere beschouwingen, viewpoints leveren nu eenmaal andere beelden, maar die moeten het wel samen doen. 
 
 
Steven van ’t Veld 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken

Beste Peter, 
 
O, begrijp me niet verkeerd: er zullen absoluut goede ontwerpers en bouwers moeten zijn. Mensen die echt goed weten hoe zij binnen een informatievoorziening iets kunnen veranderen op de manier die de organisatie stelt. Samenwerken is een uiterst belangrijk goed, maar dan ook letterlijk samen---werken. Ieder het zijne. Als informatiekundige ben ik een slecht bouwer, en als goed bouwer zal het hoogstwaarschijnlijk zo zijn dat jij minder van informatie in organisaties weet. Dat erkennen maakt samenwerking gelijk mogelijk, met groot respect voor elkaar. En dus vrijwel zeker met synergie. 
 
Daarom ben ik het ook niet direct met je eens dat je “geen invloed op zaken kan, wil of mag uitoefenen” want hard opleggen kan geen synergie opleveren. Het relatieve belang van de IT-infrastructuur mag dan minder zijn voor de informatiekundige, wat hij/zij zegt moet nog wel kunnen. Dus ook hier moet goede communicatie bestaan. 
 
Het zou van een ongelofelijke arrogantie zijn als mensen die zouden moeten samenwerken elkaar niet respecteren: “Voor jullie mag dat allemaal klinken als platte technische issues die er niet toe doen vanuit business oogpunt maar ik kan jullie verzekeren dat de infrastructuur wereld ook steeds complexer wordt, en dat bij het aanbrengen van veranderingen de rol van de architect steeds belangrijker wordt gevonden.” Andersom geredeneerd: wat te doen als die business en informatie issues niet (goed) realiseerbaar zijn? Waar ligt dan de zwarte piet? Zoals gezegd is elkaar vinden en goed samenwerken erg belangrijk. Ik denk wel dat je gelijk hebt dat je dat wel moet kunnen. Het is dan ook logisch dat iemand met echt overzicht over de IT-infrastructuur en met het oog op de langere termijn architect genoemd wordt. Maar daar zijn er echt niet veel van, zeker veel en veel minder dan het aantal mensen dat zich nu architect noemt. Architect ben je namelijk niet als je van school komt, je zult dan nog veel kennis en ervaring op moeten doen voor je zover bent. Tot die tijd zijn functienamen als systems engineer en software engineer veel en veel beter. Met een doorgroei naar architect op de langere termijn, mits en indien iemand zich voldoende ontwikkeld op de haar of hem relevante gebieden.  
 
De schatting was een tijdje geleden dat er in Nederland best wel eens 30.000 mensen kunnen zijn die zich architect in de informatie & IT-sector noemen. Dat kan niet waar zijn, tenzij de titel vergeven is aan mensen die niet doen wat de titel doet vermoeden. Daarmee is de waarde van de titel architect feitelijk gereduceerd tot nul. Jammer, want er zijn nogal wat echte architecten nodig, op diverse gebieden. 
 
Dus Peter, ik denk dat wij het over meer eens zijn dan het zich misschien laat aanzien. Met mijn complimenten over je open en eerlijke bijdragen. Ik zie teveel teksten van mensen die het, om welke reden dan ook, niet over hun hart kunnen verkrijgen om zo over hun vak te schrijven. Het m.i. wel de enige manier om verder te kunnen komen op de weg die we nog af moeten leggen, want die is nog erg lang. 
 
Steven van ’t Veld 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken

Beste Daan, 
 
Het is goed te zien dat je terug bent bij de door jou geschreven bijdrage! Het werd inderdaad een beetje vreemd om iemand te zien afhaken terwijl hij zelf de zaak in gang heeft gezet. 
 
 
Ten aanzien van je aanbevelingen: 
 
Ad 1. Essentiële rollen: opdrachtgever, architect, bouwer en evt toeleveranciers. Het idee van essentiële rollen spreekt mij aan, alleen zie ik de indeling die je voorstelt als de juiste. Maar het werken aan dit soort indelingen juich ik toe, waarbij we nog eens goed naar de indeling zelf moeten kijken. 
 
Ad 2. Denkkader. Ook hier ben ik het in essentie eens, alleen de indeling die je voorstelt is te kort door de bocht. Het kan simpel blijven, maar je kunt het niet zo sec indelen zoals je nu voorstelt. Maar ook dat is invulling. 
 
Ad 3. Strikte functiescheiding tussen architect en engineer. Feitelijk om dezelfde redenen als hiervoor ben ik het eens met het neerzetten van een goede functiescheiding, maar heb ik moeite met het simpele toepassen in architect vs. engineer. 
 
Dus een goede samenvatting en in principe goede aanbevelingen. Al moet in lijn met de aanbevelingen nog wel over het nodige gesproken worden. 
 
 
Steven van ’t Veld 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken

Steven, 
 
Het eerste punt gaat in feite om de documenten die de essentiële rollen dienen op te leveren, daarom heb ik het resultaatgerichte informatisering genoemd. 
Alle drie de zaken denkkader, essentiële rollen en resultaatgerichte informatisering vereisen nadere nuancering en verdieping. Wat mij betreft zou ik wensen dat een van de verenigingen NAF, GIA of NGI daarvoor eens een middag beleggen of zelfs alle drie tegelijk. Bij een succesvolle eerste bijeenkomst kunnen we vervolgens via VNA de nadere verfijning met z´n allen bediscussiëren, eerst free format en daarna middels een wiki.  
Het lijkt mij dat als wij duidelijkheid krijgen over die zaken ook fenomenen als TOGAF beter kunnen worden gepositioneerd. 
 
Daan. 
 
PS: Zijn er anderen die daar ook in geïnteresseerd zouden zijn.