Steven, 
 
Voor alle duidelijkheid: ik had jouw laatste reactie (21:58) niet gelezen toen ik mijn reactie plaatste (die van 22:43).  
 
Ik ben het op zich met je eens dat je als eerste moet kijken of veranderingen/projecten op zich noodzakelijk zijn, in het geheel passen en werkelijk toegevoegde waarde hebben. (tenminste dat is toch wat jij probeert te zeggen?). Maar ik vind wel dat als projecten eenmaal gedaan worden het wel noodzakelijk is om te zorgen dat niet 1/3e van de kosten verspild geld is.

Beste Pieter (23/4 21:05 + 24/4 16:04), 
 
 
Je vroeg over verandering en stabiliteit. 
 
Neen, ik ben zeker niet tegen verandering. En ik zie stabiliteit als een relatief begrip. Je zou kunnen zeggen dat je, binnen wat Daan rollen noemt, kennis (en ervaring) zult moeten ontwikkelen in de onderlinge relatie binnen en tussen de resp. rollen. Als je de ontwikkeling van die kennis beschouwt, dan is de status daarvan op enig moment uitgangspunt`voor wat je doet, en kunt doen. De totale basis is de relatie tussen de mate waarin je kennis van de resp. aspecten in onderlinge relatie hebt.  
De stabiliteit zou je moeten vinden in het vakmatige van de resp. aspecten. De invulling ervan kan wijzigen als “de wereld” wijzigt waar je mee bezig bent, en de kennis van die wereld zal dus ook bijgesteld moeten worden als dat nodig is.  
Een totaal andere stabiliteits idee zit in de relatieve ervaring met de aspecten. Het feit dat gegevens informatie zijn in een bepaalde wereld is veel stabieler dan het feit dat een bepaalde technologie gebruikt wordt om die wereld van haar informatie te voorzien. Banken doen al duizenden jaren iets met geld voor hun klanten, maar sinds de kleitablet is er toch wel een hele lange reeks technologieën geweest die het voorzien in de informatie over klanten, producten/diensten, de afspraken die met bepaalde klanten over bepaalde producten/diensten zijn gemaakt en de afhandeling daarvan: kleitablet, papier, fax, IT en ga zo maar door. Je kunt dus zeggen het feit dat NAW informatie is die we over klanten willen hebben een veel stabieler stuk kennis is dan het feit dat die NAW op een moment met een bepaalde technologie vastgelegd wordt. Dat verandert eigenlijk alleen als een onderhavige Bank beslist dat ze de NAW van klanten niet meer willen hebben, dat NAW dus slechts een gegeven is dat geen informatie (meer) is. In dit geval na misschien wel 5000 jaar. 
 
Ik denk dus dat je misschien over stabieler kunt spreken, niet over stabiel: in beton gegoten. Verandering in de IT is echter vooral systeemontwikkeling, of bijstelling. De constatering, mening dat iets niet goed is als het er is, als het gebruikt wordt is een hype-push die zijn weerga niet kent. Daarmee wordt alles wat is ter discussie gesteld, met als reden dat we weer lekker aan de slag kunnen als iemand opmerkt dat er iets aan kan verbeteren. Dat is gewoon vaak onzin. Natuurlijk moet je goed in de gaten houden of iets nog steeds “voldoende voldoet”, maar de aanname dat alles wat er is, we noemen het denigrerend de legacy, aan vervanging toe is is een commerciële hype. Als je dan ook nog die verandering binnen de richtlijnen van de oude oplossing laat wordt het echt gemeen precair. Waarom moet ons hypotheeksysteem opnieuw geprogrammeerd worden? Waarom combineren we het niet met andere systemen die ondersteunen als geld verstrekt wordt aan klanten? Dus: waarom heeft een Bank 10.000 applicaties terwijl zij als geheel maar 3 soorten (primaire) informatie hebben?  
IT-specialisten kunnen dit niet overzien, want die werken aan oplossingen, veranderingen. De bank zelf zal zo wijs moeten zijn om deze kennis op te bouwen, en te beheren. Overzicht en inzicht. Als IT nou alleen maar de beste kwaliteit zouden kunnen leveren met de IT-infastructuur. Kwaliteit vooral in relatie tot de vraag die optimaal gesteld dient te worden door diezelfde bank. Op basis van de juiste kennis, dus. En DIE kennis heeft op zich weinig of niets met IT, de op dit moment meest belangrijkst geachte manier van oplossen, te maken. Stabieler, maar zeker niet onveranderlijk. Maar kompleet anders dan wat verandering in de ogen van IT is, zoals blijft als methoden als TOGAF. 
 
 
Steven van ’t Veld 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken

Beste Pieter (23/4 21:05 + 24/4 16:04), 
 
 
Ja, ik heb moeite met je gebruik van het woord ontwerp. Volgens het woordenboek is ontwerp het beschrijven van iets nieuws in hoofdtrekken, een aan anderen ter overweging aangeboden plan. Ontwerpen is iets uitdenken en in schets brengen, of beramen, opstellen. Iets nieuws, dus, dat uitgewerkt is zodat goed bekend is wat het is, moet zijn/worden. Jij zegt dat je ontwerpen gelijk aan onderhouden stelt. Dus iets dat is bijstellen, aanpassen. Dat is iets anders.  
Mijn zorg is hier dat je daarmee een nieuwe betekenis aan het woord ontwerp(en) toevoegt die het begrip een toch wel stevige andere betekenis geeft. Een homoniem dus, iets waar ik vanaf mijn eerste jaren voor gewaarschuwd ben omdat het een zo lastig te hanteren concept is: als jij ontwerpen zegt bedoel je immers iets anders dan ik uit het woordenboek kan halen dat door veel mensen gebruikt wordt: de Van Dale. 
 
Als ik het woord ontwerpen even laat voor wat het is en je beschrijving lees kom ik uit op iets dat onderhouden moet worden. Tot nu toe heb ik steeds het woord kennis gebruikt, kennis van diverse zaken die naast ontwikkeld en beheerd moet worden, en die dus onderhouden moet worden. Even buiten de invulling komen we dan in principe heel dicht bij elkaar. 
 
Nog even over ontwerpen. Ik weet dat Jaap en jij ontwerpen zien als het aangeven van ruimte in plaats van het afperken van wat waar hoort. Schitterend, maar voor mij een half vol glas naast een half leeg glas. Als ontwerpen het beschrijven van iets nieuws in hoofdtrekken is, dan is het dus een combinatie van tekst, tekeningen enz. die, als of niet via IT, gemaakt is, en ter beschikking staat. Elk woord, elke lijn in de tekeningen beperken echter. Iets ergens over opschrijven, het nieuwe volgens de definitie, is immers iets nader aanduiden op een bepaalde manier. Wat je aanduidt zou iets anders kunnen zijn, je had het anders kunnen beschrijven, of tekenen. Je had ook iets anders kunnen beschrijven of tekenen dat misschien wel hetzelfde doel zou kunnen hebben. 
 
Ontwerpen, in de woordenboekbetekenis, is voor mij dan ook altijd beperken, ongeacht wat Alexander ervan zegt. Elk lijntje had immers anders kunnen staan. En het feit dat een lijntje ergens staat, en niet ergens anders beperkt mijn mogelijkheden met mijn voorstel, mijn ontwerp. Hoe goed die keuzes ook zijn, die kan de inzet van en bepaalde technologie, in het ergste geval, mogelijk of onmogelijk maken. Sterker nog: wat met een huidige technologie mogelijk is kan met een toekomstige onmogelijk zijn. Dus is ontwerpen beperken, en is het belangrijk dat het aantal beperkingen tot het minimum beperkt blijft (waar Alexander hopelijk mee bezig is geweest). 
 
Een ontwerp wordt dus niet alleen beperkt door context, maar ook door wat ontworpen wordt zelf. 
 
Neen, onderhoud is niet architectuur. Ik heb net het begrip kennis gebruikt, dus kennis van en rond een bepaald aspect. Bijvoorbeeld kennis van de informatie van een omgeving, een gekozen wereld, of de kennis van de applicaties die die wereld ondersteunen, of de kennis van de technische IT-infrastructuur. Het opgebouwde beeld, al of niet van en rond een aspect, noem ik architectuur. Het totale beeld dus van een bepaalde, vaak gekozen wereld, dus. Daarbinnen hoort van alles en nog wat waar kennis bestaat, dient te worden ontwikkeld en die beheerd zal moeten worden. 
 
Het grappige is dat mensen met een andere achtergrond, met andere kennis en ervaring vooral naar bepaalde dingen in een omgeving kijken, en dan ook vaak nog op een bepaalde manier. Een informatiekundige zal heel andere dingen zien dan een IT-er, een PZ-mens, een jurist en ga zo maar door. Zij kunnen vooral met elkaar spreken als zij zien dat zij op hun eigen manier naar hetzelfde kijken. Een bankdeskundige en een IT-er dienen zich te realiseren dat zij allebei naar de geboden IT-ondersteuning kijken, maar precies vanaf “de-andere-kant”: ondersteund worden versus ondersteuning leveren. Wie dan geen gemeenschappelijke “taal” vindt heeft een probleem, want hoe kan je dan over een te verbeteren ondersteuning spreken. Men spreekt dus deels over hetzelfde, en de overlap van onderwerpen is groot of klein. In de praktijk blijkt dat er een enorm verschil zit tussen de bankdeskundige die IT gebruikt en de IT-er die de ondersteunende IT maakt en exploiteert. Net als een chauffeur die met een monteur moet spreken. Daar blijkt de informatiekundige tussen te zitten, die over informatie kan spreken met de “wereld” en over de inzet van IT om die informatie ter beschikking te krijgen met IT-ers.  
 
En dit is wat ik bedoel in mijn antwoord naar Peter met synergie. Samen---werken, maar dan wel daarover wat de resp. disciplines (Daan heeft het over rollen) raakt. Maar pas daarbij op dat je een IT-er niet de rol van de informatiekundige of de bankspecialist geeft, want die kan zo iemand hoogst zelden goed spelen. Evenals dat de bankdeskundige goed in de rol van de informatiekundige of de IT-er zal zijn. 
 
Mijn “allergie” voor literatuurstudie bestaat overigens niet. Alleen moet ik het wel doen in de praktijk, en heb ik gewoon de tijd niet om te lezen wat iedereen zo schrijft. Zeker in architectuurland wordt zoveel geschreven dat echt nauwelijks hout snijdt dat ik me probeer te beperken tot wat dat wel doet. Na 30 jaar in de wereld bezig geweest te zijn is mijn toetssteen vooral de praktijk, en niet, bijvoorbeeld, de 69 verschillende manieren waarop WO/HBO in Nederland naar IT kijkt, of de 10.000 mensen die vinden dat zij het wiel uitgevonden hebben. Mijn ervaring is dat er nog zo zelden over het geheel binnen de informatie & IT-sector nagedacht wordt dat het aantal geschriften daarover minimaal is. Het gaat altijd over een hulpmiddel, het feit dat je moet tekenen, een methode die in een specifieke omgeving gewerkt heeft om bedrijfsprocessen op een rij te krijgen, software die al op 3 plaatsen werkt of meer van dat soort uitingen. Of het is zo …… theoretisch en moeilijk beschreven, vaak ook nog in een zelfgecreëerde taal, dat het voor een simpele praktijkmens als ik gewoon niet te doen is om het te doorgronden, laat staan toe te passen in de praktijk, in een normale tijd. En er is geen enkele garantie, of iemand nu wat AMBI-modules gedaan heeft, of 3 keer dr. voor zijn naam heeft staan. Kijk naar de taal die je zelf gebruikt, Pieter, en de eigen betekenis die je soms aan woorden geeft. Feitelijk interesseert het me niet of analyse voor ontwerp komt, of andersom. Zo lang het samen maar optimaal past in het geheel, en daar heb ik te vaak twijfels over, en nog veel vaker zie in dat in de praktijk fout gaan. Met steeds desastreuzer gevolgen, tot aan het IT-infarct toe.  
 
Misschien toch een advies. Erkenning krijgen voor jou ideeën, aanpak, methode ligt niet in het door blijven gaan met steeds hardere en grovere argumenten. Je steekt in je tekst je handen in de lucht en roept vertwijfeld dat je zo gauw niet zou weten wat je nog meer moet doen om de erkenning voor je werk te krijgen die je denkt dat je werkt waard is. Misschien is veel minder doen wel een alternatief, want als het echt goed is komt het dan vanzelf aan de orde. Of het aan mij besteed is: ik heb je gezegd dat ik niet zie dat ik het hard nodig zou hebben. Dat kan een probleem van mij zijn, maar de vele teksten die ik van je gelezen heb zetten me niet op dat spoor. En dat geldt dus voor heel veel mensen die teksten produceren, trouwens. Ook binnen Via Nova Architectura. 
 
Jazeker, niet kiezen is ook kiezen. En daarmee beperk je dus ook je ruimte. Wie heeft dat boek Informatiekundige Ontwerpleer dat je aanhaalt dan geschreven? 
 
Weten is de basis om goed te kunnen kiezen. Steeds beter weten, als organisatie en als mens, zal ervoor moeten gaan zorgen dat op een moment keuzes gemaakt kunnen worden die, in ieder geval voor dat moment, optimaal zijn. Maar het weten zelf en de kennis over gemaakte keuzes zal naast elkaar moeten staan, zodat je kunt blijven zien dat je gemaakte keuzes valide zijn en blijven. Als daar verandering in komt heb je een echte aanleiding om te gaan veranderen, a-la TOGAF of DYA wat mij betreft.  
En juist ook weten beperkt, alleen op een totaal andere manier dan ontwerpen. Er is een grapje over mensen, waarin verteld wordt dat je bij geboorte niets van alles weet, later weet je weinig van veel, veel van weinig en uiteindelijk alles van niets. Hoe bedoel je: vrijheid……? 
 
24/4 16:04. Jammer dat je niet wist dat ik toch meer dan 10 jaar aan ODP gewerkt heb. De essenties van het begin van ODP worden met voeten getreden in RM-ODP omdat het door de verkeerde mensen uitgewerkt is, en dat is de reden waarom ik het op een moment opgegeven heb en met conceptual schema’s bezig ben gegaan. Mijn teksten tot nu toe laten m.i. voldoende zien van mijn denkwijze om je te laten zien dat je tekst niet juist is. Natuurlijk ben ik zelf, als opgeleid en ervaren informatiekundige, vooral geïnteresseerd in het information viewpoint, het conceptual schema. Maar volgens mij was ik degene die, bijvoorbeeld, over synergie is begonnen. Jammer dat je dan zo’n tekst schrijft. 
 
 
Steven van ’t Veld 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken

Beste Peter (26/4 22:43 en 22:54) 
 
 
Standaard ISO TR-9007 (1983 en 1986) spreekt over iets dat Universe of Discourse heet. Dat is de wereld waarover wij spreken, en dat kan van alles en nog wat zijn. Het is voor die wereld dat we over een passende informatievoorziening spreken. Dat is dus precies bijvoorbeeld de informatievoorziening gedurende bouwprojecten in de fysieke wereld over partijen heen. De crux is dat je goed vaststelt wat je UoD is, en dat je zo ook kunt vaststellen wat in je informatievoorziening zit die deze UoD ondersteunt. En in feite kan je dat voor alle PIOFAH of COPAFEITH factoren zeggen, dus ook juridisch. 
 
In de wereld waar jij over spreekt leert de architect feitelijk de opdrachtgever kennen op een zodanige manier dat hij/zij weet wat de opdrachtgever wil en dat kan vertalen naar de bouwers. Zeker kunnen architect en aannemer leveranciers zijn, alleen wel nogal verschillende leveranciers die hun rol moeten spelen. De architect als rechterhand van de opdrachtgever en de leverancier als contractpartner met de opdracht om iets te doen. Daarom kan Sogeti ook geen echte architect zijn als IT-leveranciers gekozen worden omdat zij Capgemini zijn. Nog sterker kan dat niet als Capgemini ook nog leverancier kan worden, want wat kunnen de andere leveranciers nog goed doen als de adviseur/architect uit hetzelfde huis komt als de aannemer/leverancier?  
 
Dat een opdrachtgever laat aanhaakt is erg vervelend. Gaat dan een architect aan een opdrachtgever vertellen wat goed voor hen is? Lijkt me erg lastig. Zeker als het niet alleen om IT gaat, zoals je zegt. Of is de feitelijke opdrachtgever in het echt iemand anders, zoals een branchevereniging of een ministerie? Lastig. 
 
Wat je zegt kan je vergelijken met standaardpakketten. Het punt is de vraag waar je de kennis vandaan haalt om echt een goed pakket IT samen te stellen waar men op zit te wachten. De praktijk leert dat IT structuur, functie, schoonheid en harmonie op heel andere manieren ziet en inricht dan dat opdrachtgevers dat doen. De vraag is dan letterlijk: wat is goed, en wat is slecht. In vaktermen spreken we dan gauw over blauwdenkers die moeite hebben met de andere kleuren omdat alleen structuur en functie zelden tot goed passende oplossingen leidt. Een mooi voorbeeld is Exact. Daar hebben ooit administrateurs voor hun collega’s bedacht wat goed voor hen was, en dat heeft ze en grote markt opgeleverd.  
 
Anders gezegd, in lijn met je Engelse tekst: het feit dat een wereld zo slecht ondersteund wordt doet vermoeden dat alles beter is dan dat nu is. Alleen is dat goed genoeg. Is de half lege kop toch een half volle kop? De ervaring leert dat dit meestal niet het geval is, ongeacht hoeveel beter de wereld het al gaat doen. 
 
Heb je nagedacht over waarom opdrachtgevers zo moeilijk te interesseren zijn? Ligt dat aan de slechte naam van IT-leveranciers? Of hebben deze opdrachtgevers andere oplossingen op het oog? Wordt hier, zoals zo vaak gebeurt, verkocht dat het allemaal goed voor deze bouwbedrijven is waar IT mee bezig is, terwijl ze zelf, terecht of onterecht, beter weten? Wensend denken? 
 
Natuurlijk ben ik met je eens dat in projecten weinig verspild moet worden. Daarom zit ik ook zo met kennisontwikkeling, want die kennis is wel de onderbouwing van wat in een opgestart project moet gebeuren. Daarom zie ik business analyse, of hoe het allemaal genoemd mag worden, ook nog nauwelijks als eerste projectfase omdat die kennis er gewoon dient te zijn. En dus gebruikt kan worden door de leveranciers die zo’n project gaan doen. Maar goed weten en onderbouwen wat een leverancier moet gaan doen is echt de enige garantie om effectief en efficiënt projecten te doen, en veranderingen te realiseren.  
Outsourcing naar India laat dat schitterend zien. CMM 5 in India betekent dat je weet wat je krijgt als je iets in stopt. En wij, als we opdrachtgever zijn, weten niet goed genoeg wat we erin stoppen. Dus krijgen we er vaak garbage uit. Maar nog verder hiermee: stel dat we wel goed of zelfs precies weten wat we willen hebben, waarom zouden we dan (out)sourcen? Dan kan je die kennis immers ook in een software generator stoppen en dan krijg je je programma. Alleen is het ontwikkelen van echte software generatoren nu een jaar of 20 stilgelegd. Jammer, maar helaas: wij zijn die kennis haast helemaal kwijt.  
Maar, terugkomend op je laatste tekst: als je projecten goed kunt aansturen, dan zou je weinig moeten hoeven verspillen. Maar ik zie het TOGAF of DYA niet doen. 
 
 
Steven van ’t Veld 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken

Een uitbarsting – dat was het. Noem het een eruptie – die lawine aan reacties die volgde op de bijdrage van Steven van ‘t Veld (22-04-2009 01:33). De helft van de totale tekst van deze thread (vanaf 22 april) vormde zich in slechts 3 dagen tijd. En als ik nu kijk… is de stroom – na een korte adempauze – alweer op gang gekomen. 
De eerste eruptie startte op 30 maart als gevolg van de (molen)steen die Daan Rijsenbrij in de VNA-vijver plonsde en bedaarde 5 dagen later. De geschrokken stenenplonzer herstelde daar gelukkig toch weer van. Daan: bedankt voor je verhelderende sfeerbeeld/samenvatting! 
 
Met deze bijdrage wil ik een begin maken om mijn enorme achterstand in te lopen. Er ligt ‘opeens’ zo’n berg aan materiaal…. Zou het nog lukken…. Aan de slag. 
 
Steven (22-04-2009 01:33): “Als je gaat vergelijken, start dan alsjeblieft met [de] concepten”. Uitermate to the point, moet ik zeggen! En tegelijk ook een wezenlijk vertrekpunt! Ja, als de onderliggende concepten een heel beperkte reikwijdte hebben, geldt dat ook voor alle ervan afgeleide producten. Wie daar geen oog voor heeft en zich domweg tot de stroom aan “verschijningsvormen” beperkt, blijft – zonder het te beseffen – modderen. Ook Pieter Wisse (in 22-04-2009 09:20 en 23-04-2009 10:32) deelt die mening grondig: “Want ik ben het volkomen met Van ‘t Veld eens dat slechts zùlke grondslagen, conceptuele dus, samenhang [(]helpen) borgen.” 
 
Steven (23-04-2009 00:58): Over die conceptuele grondslagen schrijft Steven van ‘t Veld (in samenvattende zin): “Daarmee zeg ik dat de essentie allang bekend is, maar dat in de praktijk te weinig geld verdiend kan worden als we die [10 of 11 echte] basisconcepten echt ook zouden hanteren.” Pieter Wisse is het daar, d.w.z. met “de essentie [die] allang bekend is”, niet eens (23-04-2009 10:32). Hij vindt “resultaten van die ISO-ontwikkeling principieel [tekortschieten].” Die resultaten bieden, als ik hem goed begrijp, domweg te weinig ruimte voor vereiste variëteit. En daarom ontwierp Wisse “een axiomatisch stelsel voor zgn radicale interdependentie.” Als ik Wisse opnieuw goed begrijp levert dat “axiomatisch stelsel voor zgn radicale interdependentie” een stuk meer ‘ruimte’ en omvat het, kort door de bocht, het ‘John Sowa gedachtegoed’ volledig.  
 
Vraag voor Steven is nu wat hij van dat “axiomatisch stelsel voor zgn radicale interdependentie” vindt in relatie tot “de essentie [die] allang bekend is”.

Beste Steven, 
 
Ik zit te bedenken dat we eigenlijk samen een boek zouden moeten schrijven over Architectuur in de Digitale Wereld, in de stijl van "The 100-Mile Walk: A Father and Son on a Quest to Find the Essence of Leadership". :-) 
Dat boek beschrijft de visie op leiderschap vanuit twee tegengestelde standpunten. Een stukje uit een review van het boek: "Two different generations have their own insights into the component parts of leadership. No matter where you live and work, public or private, profit or non-profit, east or west/north or south, the lessons discussed by Sander and Jonathon have a common application and meaning. The perspective of each of the authors is different, but the result of their journey is surprisingly the same. " 
 
Wij schelen niet veel in generatie qua leeftijd/ervaring denk ik, maar op bijna alle architectuur-gebieden zijn we tegenpolen.  
 
Jij, onafhankelijk architect, enterprise(?)/informatie niveau, strategisch 
Ik, altijd architect in dienst van een ICT-leverancier, infrastructuur niveau, tactisch 
 
En toch komen we vaak tot dezelfde conclusies... 
 
Wat betreft de stelling dat architecten onafhankelijk moeten zijn: wat mij betreft is dat geen vaststaand feit. In de fysieke wereld zie je ook dat er steeds meer met design-build constructies wordt gewerkt waarbij de architect niet meer onafhankelijk is. Terwijl dat tot een paar decennia terug ook onbespreekbaar was voor veel architecten. En dat er steeds meer met die constructie geeft aan dat opdrachtgevers daar toch wel de positieve kanten van inzien.  
 
Verder denk ik dat als een niet-onafhankelijke architect maar duidelijk aangeeft aan welke partij hij verbonden is de opdrachtgever zelf de keuze kan maken of daar een risico aan zit. Maar ik denk dat een opdrachtgever vooral zal kijken naar de stijl van architectuur bedrijven. Dus als een opdrachtgever gecharmeerd is van DYA zal hij waarschijnlijk bewust kiezen voor een architect van Sogeti. Het belangrijkste is de transparantie en een vertrouwensrelatie tussen opdrachtgever en de leverancier van de architectuurdiensten. 
 
In de infrastructuur architectuurwereld ligt het weer iets anders. Daar zie je dat opdrachtgevers vaak bewust kiezen voor architecten van ICT-leveranciers, juist omdat ze al diensten afnemen of gaan afnemen van die leveranciers en omdat die architecten weten hoe het werkt bij de "bouwers" (dat is dus vergelijkbaar met de eerder genoemde design-build constructie in de fysieke wereld, die waarchijnlijk het meest effectief zal zijn in de architectuurdomeinen die concreet-werkende (bijna tastbare) producten moeten opleveren, dus de software/applicatie architectuur en de infrastructuurarchitectuur).  
 
En tot slot hebben ook onafhankelijke architecten belangen die niet altijd overeen hoeven te komen met de belangen van de opdrachtgever. Nadeel is vaak dat die belangen veel minder zichtbaar zijn dan bij architecten in dienst van een ICT-leverancier. Vergelijk het met de onafhankelijke verzekeringstussenpersonen. Nu die markt transparanter wordt weten we dat die eigenlijk ook niet bestaan. Want ook de onafhankelijke tussenpersonen zullen je waarschijnlijk verzekeringen proberen verkopen die je misschien niet nodig hebt of waar ze het meeste aan verdienen.

In zijn bijdrage van 23-04-2009 00:34 vraagt Steven van ’t Veld om eens na te denken over wat de architectuur is van iets dat (nog niet) bestaat. Als (onderling afhankelijke) kenmerken noemt hij functie, structuur, schoonheid en harmonie (hoe het geheel past in zijn omgeving). 
 
Zo’n geheel kan uit onderscheiden delen bestaan die samen dat geheel vormen. In de andere richting kan zo’n geheel natuurlijk ook opgevat zijn als deel dat op zijn beurt deel uitmaakt van grotere gehelen. Een dergelijk ordening proberen we ook wel te vangen in ‘schalen’. En zowel binnen de schalen als door de schalen heen (en weer) dient er harmonie te zijn. Harmonie die op elk schaalniveau zijn uitwerking heeft op de schoonheid enzovoort van zowel de kleinere als de grotere gehelen (schalen). 
 
Hoe kiezen we nu – in netwerksamenleving, dynamische informatiemaatschappij enzovoort – verstandig een robuust geheel zodat we binnen dat geheel veilig aan de slag kunnen met ‘een’ voor dat geheel integrale informatievoorziening zonder om de haverklap door het omringende geheel ingehaald of in de wielen gereden te worden (als gevolg van voortdurende wisselwerking, onderlinge afhankelijkheid enzovoort)?  
 
Inderdaad, dat vergt op de ruimst denkbare schaal een juiste organisatie van informatie. Lees voor ruimst denkbare schaal ook het grootst denkbare geheel (GDG). Vanaf dat ‘punt’ schaal je vervolgens naar binnen toe – naar het voor jou relevante geheel (G). Dat is een geheel (G) dat zich gesitueerd weet in grotere gehelen tot en met GDG. Een geheel (G) waarbinnen veranderingen vastgesteld (bestek) en uitgevoerd (ontworpen, gebouwd) kunnen worden. Die veranderingen moeten uiteraard binnen het geheel (G) passen (harmonie). Die veranderingen moeten ook in de grotere gehelen passen (harmonie) tot en met GDG toe. Dat lukt alleen als dat GDG met betrekking tot organisatie van informatie grondig is doordacht zo goed en volledig mogelijk ingevuld is. 
 
Als ik Steven goed begrijp (23-04-2009 18:36), kiest hij zich een werkelijkheid; een geheel (G). Voor dat geheel maakt hij een informatie-architectuur: “het beeld dat een organisatie heeft van haar bedrijfsmiddel informatie in haar organisatie”. Voor veranderingen binnen dat geheel (G) maakt hij bestekken en ontwerpen, waarna bouw volgt. 
Als ik Steven opnieuw goed begrijp zit dáár (bij dat ontwerpen) niet het (kern)probleem. Waar dat (kern)probleem wel zit, duidt hij met de term ‘planologie’. Het gaat dan om veranderingen buiten dat geheel (G). Welnu, daarover zijn Van ’t Veld en Wisse (23-04-2009 21:05) het wel eens. Zowel Van ’t Veld als Wisse hebben het over het buitengebied, het gebied tussen G en GDG, zij het dat zij zich van verschillende termen bedienen. Dat is het gebied waar volgens Steven “de kern van de problemen in de praktijk” zich bevinden. 
 
Met Wisse heb ik de indruk dat Van ’t Veld zich – bewust of onbewust – beperkt tot de organisatie als grootste G, ruimste schaal waarmee je als informatie-architect te maken hebt en waarvoor je een informatie-architectuur maakt (aan de hand waarvan daarbinnen verandering, ontwerp en bouw hun beslag krijgen).  
 
Graag hoor ik hoe Steven daar zelf in staat. Klopt mijn indruk? Indien ja, wat is voor jou de waarde van die beperking (vandaag)? Hoe zie je ‘planologie’ (23-04-2009 18:36) en wat moeten we daar binnen en buiten de organisatie wel/niet mee?

Beste Jan (27/4 11:31) 
 
 
Ja, het is een eruptie. Maar een die allang op de loer lag, en die maar niet wilde komen om allerlei al of niet verheffende redenen. Ik hou het er maar op dat we feitelijk 20 tot 25 jaar ontwikkeling van de vakgebieden in de informatie & IT-sector verloren hebben door vooral commerciële oorzaken en door de introductie van de PC. Die laatste lijkt misschien vreemd, maar ik zie het als een hele grote oorzaak. In de 80-er jaren was al zoveel meer bekend van de vakgebieden dan nu bekend is, of in ieder geval lijkt te zijn. Met de introductie van de PC was alles ineens voor iedereen simpel. We vergaten gewoon onze concepten en onze opgebouwde kennis omdat die toch niet meer nodig was: de hyperlink loste alles op. En ga zo maar door. Dus een eruptie: ja, en één die zich al een kwart eeuw opgebouwd heeft. Misschien dat we nu dan toch nog weer eens wat verder komen met waar het werkelijk om gaat, en dat heeft weinig of niets met IT te maken. 
 
Ik begrijp je samenvatting rond ISO niet. De opzet van ODP was goed, maar is in de loop van de tijd volledig afgebrokkeld. We zijn zeer fundamenteel met concepten binnen conceptual schemas bezig geweest, maar die activiteit is stilgelegd omdat denkers vanuit een verschillende invalshoek elkaar niet hebben kunnen vinden. Ik kan me nog een paar weken discussie met John Sowa herinneren waar de spetters vanaf vlogen, maar die feitelijk nergens toe geleid heeft omdat zijn uitgangspunt, het object als enig alomvattend concept, het niet kon halen. Dus zie ik ook niet waarom Pieter en ik het daar in principe niet met elkaar over eens zijn.  
 
Wel begrijp ik nu dat Pieter een eigen set concepten neergezet heeft. Je noemt dat zijn “axiomatisch stelsel voor zgn radicale interdependentie”. Dat stelsel zou meer ruimte moeten bieden dan de concepten van Sowa. Dat zal beste, want de discussie met Sowa liet in de mid-90-er jaren al zien dat het zijn beperkingen had, en dat is in zijn latere werk aan ontology niet veel beter geworden. 
 
Waar wij mee gezeten hebben was dat meer dan 250 “concepten” hebben kunnen vinden, die later teruggebracht konden worden tot 10 of 11 basisconcepten. Het gevaar is gewoon dat je nu meer vrijheid denkt te kunnen creëren door meer basisconcepten toe te voegen, terwijl dat feitelijk alleen afgeleiden van echte basisconcepten zijn. Bovendien bestaat de enorme kans dat basisconcepten binnen diverse systeemniveaus of, veel zwakker, binnen diverse viewpoints zich herhalen, of juist uit elkaar getrokken worden.  
 
Dan een algemene opmerking. Het is duidelijk dat jullie een nogal eigen terminologie hebben ontwikkeld die jullie gebruiken in deze discussie. Die terminologie is echter nauwelijks te verstaan, en te begrijpen. Als ik een zin als “axiomatisch stelsel voor zgn radicale interdependentie” lees kost het me echt moeite om te bedenken wat jullie daarmee bedoelen. Ik neem aan dat het een set van basisconcepten in hun onderlinge relaties is, maar dat is dus wel een wilde aanname. Het zou enorm helpen als jullie in gewone taal kunnen uitleggen wat je eigenlijk bedoeld. Misschien dat Pieter dan minder zijn handen in de lucht hoeft te gooien omdat niemand hem (lijkt) te begrijpen. Dat begrijpen is ook erg lastig als je niet dezelfde taal spreekt. Je bouwt dan een muur om je eigen viewpoint heen door je afwijkende uitdrukkingen, hoe academisch verantwoord die misschien ook zijn. 
 
Ik ben benieuwd of mijn uitleg van “axiomatisch stelsel voor zgn radicale interdependentie” in de buurt komt. En misschien dat iemand dan ook kort en in goed begrijpbare taal uit kan leggen wat ermee bedoeld wordt. Dan kunnen we zien of Pieter de essenties inderdaad raakt. Daarbij lijkt het me overigens geen onderwerp voor deze bijdrage rond TOGAF als would-be wondermiddel die Daan geschreven heeft. 
 
Steven van ’t Veld 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken

Beste Peter (28/4 7:41) 
 
 
Tja, een boek. Het zou leuk zijn, maar het is zo ontzettend veel werk (en dat is ervaring). 
 
In de IT-wereld wordt zo gerommeld met de titel architect dat er haast geen algemene uitspraken meer over te doen zijn. Algemeen constateer ik dat aannemers die architecten leveren vaak de titel misbruiken. Ze bedoelen in feite dat ze een analist of een ontwerper kunnen leveren. Wat mis is met die titels is dat de tarieven er lager voor zijn. En daarmee is de titel architect in de informatie & IT-sector vrijwel failliet op het moment.  
 
Een bouwaannemer die een architect kan inzetten bindt haar architecten aan bepaalde oplossingsrichtingen. Waarom zou een aannemer in de houtbouw immers een architect willen leveren die adviseert om een gebouw in steen op te trekken? Waarom zou Sogeti een architect leveren die geen IT volgens DYA, TOGAF of IAF voorstelt? Waarom zou HP een architect leveren die adviseert om IBM aan te schaffen? Waarom zou SAP architecten leveren die Microsoft logistieke software adviseren? Net als in de bouwwereld: als je weet dat je met hout wilt bouwen kan je je analist/ontwerper misschien van je aannemer komen, al is ook dat maar de vraag. Want als je 4 slaapkamers wilt hebben en houtskelet gaat hoogstens tot 3 slaapkamers, wat doe je dan? Of als je Sybase hebt en je architect kent vooral Oracle, wat doe je dan? 
 
En dan nog een stap anders: als je een Bank bent en je huurt een architect in die vooral ABNAMRO goed kent, wat gebeurt er dan? Krijg je dan iets dat goed bij je past, of wordt alles omgebogen naar de oplossing die deze architect kent? Dat is wat ik bedoel met onafhankelijk. 
 
The Open Group stelt in haar op haar website http://www.theopengroup.org/ het volgende: “The Open Group is a vendor-neutral and technology-neutral consortium, whose vision of Boundaryless Information Flow™ will enable access to integrated information, within and among enterprises, based on open standards and global interoperability.” Technologie neutraal; dat wil zeggen dat de verenigde leveranciers in deze organisaties het zo zullen doen dat ze elkaar zo min mogelijk pijn doen. Men zoekt helemaal niet naar de optimale manier, men zoekt naar een manier die alle deelnemende leverancier kan gebruiken, en die hen omzet oplevert zonder dat het veel geld kost. En dat is precies de gesloten sfeer die in The Open Group heerst. 
 
TOGAF is dus niet iets dat onafhankelijk is, het zorgt ervoor dat de deelnemende leveranciers er zoveel mogelijk omzet mee halen. Zowel met de methode en de cursussen, als ook met de daaruit voortkomende aanschaffingen. En daarmee mag je verwachten dat de kracht van TOGAF op slag onbekend en zeker niet effectief genoeg zal zijn. Tenminste niet op het vakgebied. TOGAF is dus niet onafhankelijk, maar hoogstens neutraal voor de eigenaren: IT-leveranciers. 
 
En natuurlijk is het logisch dat men in de IT-infrastructuur mensen wil hebben die veel van de gekozen in te zetten apparatuur weten. Maar of dat architecten zijn, daar kun je over strijden. Je komt ergens in de buurt van instellen, inregelen, onderhouden enz. terecht, en dus nauwelijks op het echt inrichten van een omgeving. En wat te doen als dat een multivendor situatie is? Ga je dan een IBM-architect HP en EMC apparatuur mede laten inzetten? 
 
Onafhankelijke architecten die organisaties inhuren en die niet volledig voor die organisatie gaan moeten snel weer ontslagen worden. Het kan toch niet zo zijn dat iemand ingehuurd wordt om een taak te vervullen die binnen de organisatie niet aanwezig is cq. niet aanwezig kan zijn en dat die dan eigen belangen gaat nastreven? Maar je hebt gelijk, dat is wel de praktijk van vandaag. Sommige mensen zeggen dat ook gewoon tegen hun klant, en ik heb nu diverse keren meegemaakt dat die klant daar niet eens op reageert. Waar is onze ethiek? En die van die klant, trouwens. Maar het is al jaren zo, en kennelijk is IT nog te machtig om hier de zaken recht te trekken. 
 
 
Steven van ’t Veld 
Dit e-mail adres is beschermd door spambots, u heeft Javascript nodig om dit onderdeel te kunnen bekijken

Beste Steven, 
 
Dit zal één van mijn laatste of laatste bijdragen zijn aan deze discussie (omdat ik wel het meeste heb gezegd wat ik wilde zeggen), die zoals ik al eerder opmerkte, heel leerzaam is geweest. 
 
Je constatering dat de titel uitgehold is deel ik. Alleen is dat in mijn optiek begonnen op het moment dat allerlei mensen die zich alleen maar bezig houden met kaderstelling en inperking van ontwerpruimtes zich architect zijn gaan noemen. En dat die vervolgens van architecten die zich met het daadwerkelijk ontwerpen en realiseren van oplossingen vinden dat die zich geen architect meer mogen noemen. En die vervolgens met iets als TOGAF komen en dat propageren als de ultieme architectuurmethodiek... 
 
Mijn beeld van een architect is gebaseerd op de architect in de fysieke bouwwereld die een opdracht wint om een concertgebouw in Sydney te realiseren. Die gaat ook niet opnieuw de discussie voeren of het concertgebouw eigenlijk niet een kantoorgebouw zou moeten zijn of een filmzaal of dat het oude eigenlijk niet goed genoeg is. Die discussie is op andere niveau's gevoerd en daar zijn de requirements en de tender uit voort gekomen.  
Nee, wat die architect doet is verder kijken dan de requirements alleen en die ontwerpt een gebouw dat niet zo maar een concertgebouw is conform de gestelde requirments. Nee, die heeft verder gekeken dan de opdrachtgevers en dat gevisualiseerd in een aantal schetsen. Letterlijk door de impact van die schetsen heeft de architect de tender gewonnen. Met een ontwerp dat niet voldoet aan de originele requirements. Sterker nog, eigenlijk had hij de tender geeneens mogen winnen. Toch is dat gebeurd dankzij zijn visie en wijze waarop hij die visie heeft getoond (de schetsen!). Daarna heeft hij samen met de engineers gebruik gemaakt van nieuwe (materiaal en constructie) technieken en vormen waar de opdrachtgever geen weet van had (en dus ook niet in de requirements mee kon nemen) om zijn schets aan te passen zodat het niet alleen realiseerbaar werd maar ook daadwerkelijk gerealiseerd!  
Zo is het meest getoonde en bekendste gebouw ter wereld ontstaan, het Sydney Opera House, dat dus meer is geworden dan een concertgebouw waar de opdrachtgevers om hebben gevraagd. Het is en een goed concertgebouw geworden (qua akoestiek e.d.) maar ook een gebouw dat het beeldmerk is geworden van Sydney en daarmee heel veel heeft gedaan voor de ontwikkeling van Sydney.  
En dat is voor mij architectuur, niet alleen maar vorm volgt functie en het alleen maar plat kijken naar de requirements van de opdrachtgever maar juist dat extra bieden, meer geven dan waar de klant om vraagt, zodat je niet alleen een goede oplossing biedt maar ook de omgeving waar die oplossing in terecht komt positief beïnvloedt. 
 
Architectuur staat voor mij gelijk aan creatief ontwerpen, waarbij creatief staat voor het een realiseerbare oplossing dat ook meerwaarde geeft aan de omgeving waar het in terechtkomt. En voor mij is het irrelevant op welk niveau (digitaal/fysiek, infra/informatie/enterprise) de oplossing terechtkomt. Op al die niveaus kun je architectuur bedrijven. Als je maar de moed en visie hebt om het probleem eerst groter te maken dan alleen de gestelde requirements en dan pas een oplossing gaat ontwerpen. En dat je de moed hebt om je eerste “ideale” ontwerpen aan te passen aan de realiteit. 
 
Voor mij gaat het architect-zijn niet om de titel of de scope maar om de ontwerpstijl. 
 
Eigenlijk wilde ik het tipje van de sluier over waar ik me op wil gaan richten pas oplichten in een visiestuk, maar ik denk dat ik dat toch nu maar doe. Ik wil me meer richten op architectuurondersteunende diensten zoals het modelleren en simuleren (meer kijken naar de dynamische kant van systemen) om zo de kwaliteit van ontwerpen en documentatie te verhogen. Dus meer kijken naar de systems engineering kant maar wel vanuit mijn beeld van architect-zijn....