Beste Jan (02-05-2009 12:06) 
 
Ja, er zijn een aantal redenen in de contributies en eromheen die me tot de (voorlopige) conclusie laten komen dat het is zoals ik het bechrijf. Je geeft me de opdracht om nog eens naar het geheel te kijken en mijn redenen samen te vatten, zeker met de manier waarop VNA werkt (laatste aan het einde, geen mogelijkheid om te groeperen of te zoeken). Dat is veel werk. Ik kan jou/jullie hetzelfde vragen. Maar goed, ik zal het proberen. 
 
Steven van ’t Veld 
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

Beste Paul (2/5 18:25) 
 
 
Tjonge, je klinkt boos in je woorden waarin je jouw wereld uitlegt. Het is jammer dat je daarvoor wat anderen denken en hier geschreven hebben zo in het algemeen kwalificeert. Je kunt zo niet echt veel verder komen om de huidige diversiteit in en rond ICT verder te brengen. Om dat wel te kunnen gebruik ik mijn ervaring in honderden bedrijven, in internationale standaardisatie en de ervaring die ik in mijn vele Masterclasses met vele bedrijfssituaties heb opgedaan. In eerste instantie om te delen, om te zien wat gelijk en wat anders is. Opleggen van ideeën leidt gewoon nergens toe, dus je zult moeten investeren om er samen uit te komen. 
 
Maar meer concreet. 
 
Ik heb het nodige van TOGAF gezien. Je vraagt voor wie TOGAF waardevol is? Mijn antwoord: vooral voor IT-leveranciers. Zeker, je bouwt er kennis mee op. Maar de effectiviteit daarvan voor een organisatie betwijfel ik, gewoon omdat het geheel niet of nauwelijks past in wat ik zie dat organisaties nodig hebben. Het gevoel van de begindagen van het informatieplan komt weer bij me terug: veel werk over een lange tijd waarvan ik, meestal jaren later, vaak niet anders kon dan het geheel voor het grootste deel direct naar het rond archief te verwijzen. En iets vergelijkbaars zie ik ook rond TOGAF. 
 
De bouwwereld heeft zich in vele eeuwen, zelfs in millennia ontwikkeld. Ik hoor IT-ers roepen dat we met architectuur in de IT al verder zijn dan ze ooit in de bouwwereld geweest zijn. We blijven ook maar vergelijken met de bouwwereld, terwijl er steeds meer verschillen bij komen, en minder overeenkomsten. Moet nu de ontwikkeling van IT uit de IT-wereld vandaan komen? Voldoet veel in de IT-wereld niet gewoon aan de regels die we in andere werelden allang gezien en onderkend hebben? Bouwwereld, of nog andere werelden? Wat vooral specifiek is voor de IT-wereld heeft met de technologie zelf te maken, niet met wat eromheen zit. Dus moeten we alles laten ontstaan in de IT-wereld zelf? Dat proberen we al jaren, tot we steeds weer tot de conclusie komen dat er al is wat we zitten te bedenken. De kracht ligt er m.i. dan ook in dat je het goede overneemt, en wat nieuw is zelf doet. Met als voorbeeld: je wordt geen logistiek specialist door een ERP-pakket te ontwikkelen. Het is ook maar de vraag of je al te veel van een toepassingsgebied af moet weten als informatiekundige en IT-er, want waarom zou je dan nog luisteren naar de mensen in het gebied waar je het voor doet? Of denk je echt dat we echt veel meer kunnen op het gebied van PZ als we een ondersteunend pakket voor dat gebied hebben ontwikkeld? En dat we dan dus aan PZ specialisten kunnen vertellen hoe zij hun werk moeten doen? De ervaring leert echt anders. 
 
“De mogelijkheden van ICT-driven architectuur beperken”. Ik denk je punt te begrijpen als dat je van mening bent dat IT de inrichting van de organisatie gaat/dient te bepalen, en dat organisaties daar blij mee moeten zijn; en dat zij de mogelijkheden die dat biedt vooral niet moet beperken. 
Ik heb het in mijn voorgaande teksten uitgebreid over synergie gehad. Dit is zo’n punt waar synergie gehaald kan worden. Maar is het nu IT die gaat bepalen wat een organisatie wel of niet kan, en mag? Of is het de organisatie die, door goed gebruik te maken van haar hulpmiddelen (dus ook IT), gaat doen waar zij voor opgericht is? In mijn praktijk is het de organisatie die bepaalt (richt), en wil bepalen. De juiste, of betere hulpmiddelen kunnen daar enorm bij helpen, waarbij de organisatie vraagt en de “hulpmiddelen inrichters” die vraag beantwoorden. In goede samenspraak, maar wel binnen het geheel van de organisatie. Synergie is dan als je er achter komt dat een hulpmiddel je in staat stelt om je doel beter te bereiken. Of dat je er achter komt dat je je doel als organisatie maar beter bij kunt stellen. Of diverse andere mogelijkheden. Maar op zich bepaalt IT niets, het is de organisatie die de consequenties van bepaalde oplossingen moet overzien, en ze dan wel of niet wil inzetten. Al of niet binnen een aangepast doel en strategie. Dat geldt zelfs voor bedrijven als Amazon, en die zijn daar ook achter gekomen toen hun zaak echt begon te lopen. 
 
Ik weet niet in hoeverre de betekenis van het woord projectie bedoelt zoals je het woord hier gebruikt. Je zegt tegen me dat ik een gewenste werkelijkheid heb die ik ook in mijn praktijk zie omdat ik die werkelijkheid wil zien. Je zegt zo tegen iemand dat hij/zij in een sprookje, een sage of een mythe leeft, en dat zij/hij de werkelijkheid zo aanpast dat het idee blijft bestaan. Ik weet niet zeker of we elkaar ooit ontmoet hebben, maar, of dat nu wel of niet het geval is, ik verbaas me erover dat je zo’n oordeel zo makkelijk durft uit te spreken. Ik ken mensen met veel kennis van en ervaring in psychologie die veel moeite hebben om zoiets te durven zeggen (of zelfs denken). 
 
Je komt met een bewijs uit het ongerijmde dat TOGAF een goed iets is, waarbij je de mate waarin het functioneert laat afhangen van de situatie waarin het toegepast wordt en/of van wie er bij betrokken is. Zo is alles goed en fout tegelijk. Je lijkt, zoals ik het lees, te ontkennen dat er vakgebieden bestaan die je kunt leren (als je voldoende aanleg hebt) en waar je binnen kunt werken “want wat je doet is afhankelijk van de situatie en van degene die het doet. Dat is feitelijk tegen wat het woord methode betekent: een bepaalde manier van werken. Voor het ontwikkelen van zoiets zijn keuzes gemaakt, en die keuzes hebben redenen. Als die keuzes te maken hebben met het vakmatige doel van de methode, dan is er vaak niet echt een probleem. Als die keuzes bijvoorbeeld gemaakt zijn om commerciële redenen (meer werk, meer omzet, meer leveranciersafhankelijkheid enz.) vind ik dat er wel een probleem bestaat. Want niet het doel van de methode staat dan voorop, bijvoorbeeld het verbeteren van een informatievoorziening, maar marktpositie.  
Aan de andere kan je ook de stelling van Jaap aanhangen, waarbij de methode het niet doet maar de mens. Dan zou de methode zoveel ruimte moeten geven dat de mens optimaal kan functioneren, waarbij de vraag is of je nog wel over een methode kunt spreken. Een beetje in de trant van: we weten niet echt wat het is, maar we noemen het TOGAF. En we zorgen ervoor dat TOGAF mensen en bedrijven het gaan doen. En dat is wel heel erg sterk waar het rond TOGAF op lijkt: TOGAF als spin, insect, vogel, olifant en wie weet wat nog meer. 
 
Mensen die als vakmens veel ervaring hebben in vele organisaties kunnen vaak al heel snel zien wat binnen een organisatie, vanuit hun expertise gezien, aan de hand is. Je zegt: “Er is dus een grote variëteit aan contexten die de betekenis van informatie beïnvloedt. Ofwel: homoniemen alom.”. Mijn ervaring is dat er natuurlijk verschillen zijn, maar dat ook veel vergelijkbaar is. Tenminste als je vanuit je eigen vakgebied, daar waar je echt wat vanaf weet, kijkt en werkt. Na 15 jaar aan internationale standaards gewerkt te hebben weet ik hoe moeilijk het is een echte standaard neer te zetten, en hoe goed het is om een echte standaard te hebben. Hoe moeilijk zou het immers zijn als we niet ooit vastgesteld hadden hoe lang een meter precies is, en hoe gemakkelijk het nu is als we afstanden in die meter uit kunnen drukken.  
 
Ik lees in je betoog, maar dat kan ik verkeerd lezen, dat je het nut van standaarden en van vakgebieden niet ziet. Zoals je gelezen hebt ben ik niet iemand die het “ontwerpen van een alomvattend iets” ziet zitten. Maar er zijn wel degelijk vakmatige regels, standaarden en, al of niet lokale, afspraken te maken die een ontwerp voor een omgeving in goede banen kunnen leiden. Ik zie dat TOGAF echter niet doen, en dus zie ik TOGAF op dat punt tekort schieten. Ongeacht op hoeveel andere punten het wel voldoet. En wat ik bedoel is juist bedoeld voor een “netwerkmaatschappij”, zoals ik eerder betoogd heb. 
 
Als laatste zeg je “Net als iedereen projecteer ik maar wat, zoals mijn feitelijk en onbetwistbaar enige juiste definitie van architectuur”. Ja, je idee en mening is, denk ik, duidelijk. Ik geloof niet in je laat-duizend-bloemen-bloeien notie. Juíst omdat we in een netwerkmaatschappij zitten waar zo langzamerhand echt het nodige aan elkaar gekoppeld dient te gaan worden. Ook je claim dat jij feitelijk en onbetwistbaar de enige juiste definitie van architectuur geeft in de criteria passend, stevig, attractief, in balans is, met als vijfde criterium dat wie uit moet leggen dat hij/zij architect is het dus niet is zie ik toch echt als een mening die op punten tekort schiet. En natuurlijk kan ik alleen vanuit mijn perspectief spreken, wie niet. 
 
 
Waar blijven trouwens de TOGAF aanhangers? Zijn jullie het eens met wat hier allemaal geschreven staat? Het lijkt erop….. 
 
 
Steven van ’t Veld 
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

Mijn standpunt: TOGAF is op dit moment, voor de beoogde doelgroep, gezien de ontwikkelingen die er zijn en op meerdere plaatsen als nodig worden ervaren, een belangrijk en waardevol hulpmiddel (niet meer en niet minder) om verder te komen met samenwerking tussen verschillende disciplines en vakgebieden die samen tot een moderne en evenwichtige inrichting van de netwerksamenleving van de 21ste eeuw willen komen.  
 
Beste Steen (3/5 01:28) 
In jouw bijdragen zit veel waar ik van kan leren, wat me tot verder nadenken stemt, waardoor ik geholpen wordt er eens op een andere manier naar te kijken etc. en dat is prima en waardeer ik. Daar tussendoor staan ook opmerkingen en beweringen, soms in vraagvorm geformuleerd, die binair en simplistisch overkomen, en dat vindt ik dan weer jammer.  
 
Boos ben ik allerminst en ik kwalificeer wat anderen denken en schrijven niet algemeen; ik poogde juist algemene kwalificaties te relativeren. Bijvoorbeeld door de erkenning van jouw ervaring “die ik in mijn vele Masterclasses met vele bedrijfssituaties heb opgedaan” te voorzien van de wetmatige consequentie, namelijk dat ervaringen meningen altijd ‘kleurt’. En dat geldt zeker voor iedereen: algemeen. 
 
Mijn toegevoegde vraag ‘voor wie?’ m.b.t. de vraag naar de waarde van TOGAF bedoelde ik vooral retorisch. Zoals een helm erg waardevol is voor bereiders van tweewielers, maar niet voor duinwandelaars (de ‘wie’). Grote voorstanders van TOGAF (zoals ik) zijn, denk ik, de eersten om te erkennen dat het geen Haarlemmerolie is, en niet voor iedereen geschikt is, en niet overal bruikbaar is, en strijden tegen ongenuanceerde verwerping. Precies zoals jij ook stelt over “de begindagen van het informatieplan”, maar dan voeg je er wel heel ‘gekleurd’ aan toe “... voor het grootste deel direct naar het rond archief te verwijzen. En iets vergelijkbaars zie ik ook rond TOGAF.” Precies mijn algemene punt: personlijke ervaringen ‘kleuren’ het menselijk oordelen en sturen onze percepties en verwachtingen. Steven: informatieplan ` TOGAF. 
 
Anders: niet de feitelijke situatie in de IT-wereld biedt (jouw) onderbouwing voor de beperkingen daarvan, en het onnut van TOGAF en haar toekomstige bijdrage aan architectuur, maar vooral jouw persoonlijke ervaring met, en oordeel over de IT-wereld doet dat. Dit persoonlijke oordeel beschouwen als ‘de enige werkelijkheid’ maakt dat juist jouw analyses algemeen en ongenuanceerd over komen. Als ik schrijf “[dat] als er al een goede ontwikkeling van het vak architectuur m.b.t. informatie en communicatie mogelijk is, deze uit de ICT moet voortkomen,” en jij dat leest als “Dus moeten we alles laten ontstaan in de IT-wereld zelf?” en (verderop) “dat IT de inrichting van de organisatie gaat/dient te bepalen, en dat organisaties daar blij mee moeten zijn; en dat zij de mogelijkheden die dat biedt vooral niet moet beperken.” Geeft een treffend voorbeeld, waarvoor dank, van wat ik 2/5 18:25 beschreef “dat eigen aannames over, en projecties van, de betekenis van woorden die anderen ... op een bijzonder taaie manier en steeds opnieuw worden opgevat zodat ze (weer) passen in de eigen projectie (waarneming) van degene die leest.”  
 
Hetzelfde gebeurt met mijn zeer genuanceerd bedoelde vaststelling dat iedereen(!) projecteert, wat door jou wordt opgevat als “Je zegt zo tegen iemand dat hij/zij in een sprookje, een sage of een mythe leeft, en dat zij/hij de werkelijkheid zo aanpast dat het idee blijft bestaan. ... ik verbaas me erover dat je zo’n oordeel zo makkelijk durft uit te spreken.” Wat ik dan weer opvat als jouw totale ontkenning van zelfs de geringste mogelijkheid dat jij ooit ‘projecteert’... Beste Steven, ik zou nooit durven beweren dat jij in een sprookje gelooft omdat ik je daarvoor absoluut te veel respecteer, maar juist en vooral ook omdat ‘realiteit’ de optelsom is van externe factoren plus vele persoonlijke factoren: er zijn dus vele realiteiten, en de ene een sprookje en de andere de waarheid noemen is precies waartegen ik strijdt. Juist uit jour reactie vindt ik verdere rechtvaardiging voor die ‘strijdt’. Bush jr. zei ooit “You are either with me or you are against me” en het is dergelijk binair en simplistisch, ongenuanceerd denken waar ik grote moeite mee heb.  
 
Mijn frustratie is dat het maar niet lukt om in de uitwisseling met jou de nuance er in te houden. Ik denk een relatief en genuanceerd oordeel over de waarde van TOGAF te geven, althans dat poog en beoog ik, en jij ervaart dat als “Ik lees in je betoog, maar dat kan ik verkeerd lezen, dat je het nut van standaarden en van vakgebieden niet ziet.” Ja Steven, je hebt dat volkomen verkeerd gelezen! Maar dat is niet zo verwonderlijk als ik merk dat je bijvoorbeeld ook mijn nadrukkelijk als ironisch bedoelde eindopmerking bloedserieus typeert als “je claim dat jij feitelijk en onbetwistbaar de enige juiste definitie van architectuur geeft”. Mijn serieuse boodschap was en is vooral: niemand heeft de (enige) waarheid in pacht; ik zeker niet, maar ook Daan, Peter, Jan, Erik, Pieter etc. niet, en ook Steven niet. Ondanks dat biedt een forum als VNA, en een discussie als deze over TOGAF, een positieve gelegenheid om te ontdekken wat ons bindt, en waar we met elkaar samen naartoe kunnen werken. Polariseren en stereotyperen helpt daarbij niet, en ik poogde met mijn vorige en met deze bijdrage een lans te breken voor de erkenning van de betrekkenijlheid van ieders mening, te beginnen met de mijne.  
Ik steun daarom ook graag je laatste oproep (echter zonder de toevoeging “Het lijkt erop….. ”): “Waar blijven trouwens de TOGAF aanhangers? Zijn jullie het eens met wat hier allemaal geschreven staat?” 
 
Paul Jansen

Beste Jan (2/5 12:06 en Pieter, Jaap enz.) 
 
 
Je hebt me gevraagd om mijn kijk samen te vatten op wat jullie vertellen presenteren. Dat kostte tijd, maar nu dan toch. Daarbij ben ik uitgegaan van voorkennis en van wat in de vele tekst in deze discussie staat. Ik start met een aantal meer algemene observaties die nodig zijn als inleiding voor wat ik daarna als mijn kijk op jullie werk samenvat. Dat het maar tot iets mag leiden. 
 
Het eerste punt is de referentie die ik regelmatig aantref rond jullie werk naar Christopher Alexander. Het is mogelijk dat ik zo meer naar het werk van Jaap refereer dan naar dat van jullie, maar in wat ik van jullie weet gaat het om dingen die minimaal hetzelfde genoemd worden. De relatie lijkt me dan ook logisch. 
Ontwerp is volgens het woordenboek het beschrijven van iets nieuws in hoofdtrekken, of 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, of worden.  
Ontwerpen wordt in de IT-sector al jaren geleerd door verbonden “doosjes” achter en naast elkaar te zetten: bolletjes, rechthoeken, puntjes enz. Zo probeert men vast te stellen hoe iets functioneel /procesmatig kan of moet gaan werken. Er zijn vele methoden voor, al of niet met het expliciet vorm en inhoud gegeven aan de nodige gebruikersinterfaces en meer van dat soort zaken.  
Als ik het goed begrijp gaat het in de afleiding van de ideeën van Alexander om het in kaart brengen van de behoefte aan informatie van een bepaalde situatie in maten en soorten. Daarbij zou zo weinig mogelijk beperkt moeten worden omdat vooral naar ruimte gekeken wordt, dus naar mogelijkheden. En dis moeten zo min mogelijk beperkt worden. Goed idee, zeker in een aantal situaties. Ik kan me echter ook voorstellen dat in andere toch ook het ontwerpen met onze aloude “doosjes”, dus DFD-achtigen/ISAC/OO/UML/.NET/… en vele andere methoden, kan voorstellen. 
 
Jullie spreken verder over schaal: een afbakening van zicht, en dus van werk. En over balans tussen een ordening van die schalen. Schaal als een geheel dat uit onderscheiden delen kan bestaan die samen dat geheel, de schaal zelf vormen, alsook als een deel van een groter geheel. Jullie stellen de vraag hoe verstandig een robuust geheel gekozen kan worden zodat IT binnen dat geheel “veilig” aan de slag kan met een voor dat geheel, die schaal, integrale informatievoorziening zonder “om de haverklap” door omringende schalen ingehaald of “in de wielen gereden te worden” (als gevolg van voortdurende wisselwerking, onderlinge afhankelijkheid enz) zodat het grote ontwerp voor IT-ers verandert. Hieruit lees ik dat “het geheel” zo verstandig in delen, jullie schalen dus, opgedeeld dient te worden dat zo weinig veranderd en er een stabiel IT ontwerp van gemaakt kan worden, met de tijd voor IT om dat ontwerp te implementeren. 
Ik zie onder meer als uitdaging: 
… een disjuncte opdeling in schalen kan alleen maar onder zeer specifieke voorwaarden bestaan. Je zou bijvoorbeeld zo’n opdeling in de IT-infrastructuur kunnen maken, waarbij ik me goed voor kan stellen dat er veel discussie over waar de grens van een schaal nu precies ligt. Mensen willen immers erg vaak meer, en meer, en vechten dus die grenzen aan, hard of zacht. Ook het feit dat als één schaal het eigendom krijgt van bepaalde informatie en een ander naar die informatie moet kunnen kijken. En dat geldt zowel voor de functionaliteit als voor de services. Als het echter over iets als viewpoints gaat (zoals ze bedoeld zijn), dus de manier waarop een bepaalde groep naar de wereld kijkt, dan is een disjuncte opdeling volledig onmogelijk. Juist op de overlap in wat de resp. groepen zien zit immers de onderlinge communicatie, in ons geval informatie-uitwisseling, en daar zullen meer groepen dus per definitie zicht op moeten hebben om rond die communicatie afspraken te kunnen uitwerken.  
… de wereld verandert continu. De kans dat je verstandig eenduidig schalen voor IT-doeleinden kunt kiezen is daarom erg klein. Misschien als je ze erg klein kiest zou e.e.a. stabieler opgedeeld kunnen worden, maar dan moet ook iets gebeuren met combinaties van schalen die samen ook een geheel vormen en komt het probleem even hard, misschien zelfs wel harder terug. Een simpele verkoop van activiteiten of een verbreding van assortiment door de om informatie vragende organisatie kan immers al tot het aanpassen van een schaal leiden. IT is een ondersteunend hulpmiddel, en het is een fictie om te denken dat je een schaal, schalen kunt maken die stabiel, lees onveranderlijk of onveranderbaar, genoeg zijn om de jaren werk die van ontwerp tot IT-realisatie nodig zijn de zaak te bevriezen. Maar het is niet nieuw; volgens mij speelt deze gedachten al alle 70 jaren in de hoofden van automatiseerders/IT-ers. Het is een fictie omdat IT geen doel of bedrijfsmiddel is, alleen een hulpmiddel. Hoe belangrijk dat hulpmiddel vandaag de dag ook voor ons is. 
 
Dan nog een punt: de aloude discussie of door het veranderen van technologie het ontwerp, zoals hiervoor bedoeld, van een schaal verandert. Als het puur om de behoefte van een organisatie aan informatie en functionaliteit gaat zou dat niet het geval hoeven zijn; in de praktijk is het vaak, zelfs meestal niet te voorkomen. Het feit dat het logisch combineren van een behoefte niet mogelijk is omdat bepaalde technologie, hoe groot of algemeen ook, dat niet toestaat wordt vaak, impliciet of expliciet, toch meegenomen in het ontwerp. Met het risico dat morgen andere technologie bestaat waarbij iets plotseling wel mogelijk is, en dus het ontwerp aangepast moet worden. Daarmee wordt een ontwerp altijd een tijdelijk iets. Net als natuurlijk de keuze van wat een schaal omvat. En is de notie van stabiliteit zo lang als die breed is: bevriezen van verandering van een schaal is dus onmogelijk. 
 
In feite komen we hier, als volgend punt, op het verschil tussen functionaliteit en service; resp. de behoefte aan ondersteuning versus wat de ondersteuning die geboden wordt/kan worden. Als je weet wat de behoefte aan informatie en functionaliteit is, is het omzetten naar een technologie onafhankelijk ontwerp van een schaal feitelijk alleen extra documentatie die bestaat in de hoop dat die het gewenste overzicht en inzicht geeft. De inrichting van de te bieden functionaliteit, er zijn andere termen maar we noemen dat tegenwoordig vaak Service Oriented Architecture (SOA), waarbij elke service feitelijk een (groep) functionaliteit is voor een gebruikende organisatie, is feitelijk niet te doen zonder minimaal enige, voldoende afhankelijkheid van technologie. Zo ontstaan dus 2 soorten ontwerp naast elkaar, waarbij het lastig is om het doel van het hebben van een behoefte ontwerp/inrichting naast een infrastructuur ontwerp/inrichting te blijven zien. Van jullie verhaal krijg ik de boodschap dat deze beide situaties toch naast elkaar zullen moeten blijven bestaan, daar zie ik dus de nodige discussies in de praktijk. 
 
Misschien zou je hier ook kunnen kijken vanuit een andere invalshoek. Het doel van een behoefte inrichting, wat jullie m.i. ontwerp noemen, is immers principieel een ander iets dan de inrichting van wat een organisatie aan ondersteuning geboden wordt (gaat worden enz.). De behoefte inrichting, zoals ik jullie ontwerp ideeën lees, is feitelijk één beeld van een schaal dat in de loop van de tijd vooral op punten aangepast zal hoeven worden; het kent in feite geen versies omdat het iets is dat met de behoefte mee zal kunnen groeien, dus kleine en grote stapjes: groei.  
De inrichting van de IT-infrastructuur, daarentegen, heeft in feite een huidige situatie naast een gewenste situatie. Die 2 beelden (het kunnen er zelfs meer zijn) kunnen sterk van elkaar afwijken omdat de eerste weergeeft wat op een moment werkelijk geboden wordt (dit wordt door veel IT-ers ook wel de legacy genoemd) en de tweede een nieuwe inrichting laat zien waar men naar toe wil overgaan. Het verschil tussen de behoefte inrichting (jullie ontwerp) en de toekomstige inrichting van de IT-infrastructuur is feitelijk de keuze om, nieuwe en oude, technologie in te zetten, en de mogelijkheden daarvan. Op deze manier zouden beiden soorten ontwerp elk een goed doel dienen, en naast elkaar een vinger aan de pols kunnen geven van de organisatie en de haar ondersteunende IT. Waarbij nog steeds het punt blijft dat het verschil voor veel IT-ers in de praktijk moeilijk zal zijn. 
 
Nog een punt: Eén van de basisproblemen in de IT-sector is al jaren dat vooral vanuit verandering gedacht wordt, en (nog) zelden vanuit kennis en groei. Met in het kielzog hiervan de nog zelden geziene (logische) constatering dat elke organisatie architectuur hééft, hoe goed of hoe slecht die ook is. Het feit dat alles wat een informatievoorziening aan IT door IT-ers legacy genoemd wordt met de conclusie dat legacy niet goed is, iets dat dus veranderd moet worden is feitelijk een verkooptruc en geen vakmatige constatering of wetmatigheid. Natuurlijk is stilstand achteruitgang, en is verandering nodig om bij te kunnen blijven in onze veranderende wereld. Maar weten wat je, als organisatie of als “schaal”, wil en moet is wel de enige echte basis om je hulpmiddelen, zoals IT, te kunnen veranderen. In de praktijk blijkt regelmatig dat rigoureus veranderen van IT vaak gewoon niet nodig is, en dat wat we legacy noemen regelmatig helemaal niet zo slecht is als denken “omdat het legacy is”. Dat iets vaak beter kan is immers nog geen reden om daar ons schaarse geld te stoppen, want goed genoeg is goed genoeg. 
 
Mijn samenvatting kan gegeven worden in het verlengde van de eerdere discussie over wat er eerder was: analyse of ontwerp. Ontwerp is voor mij inrichting. Ontwerpen is niet mogelijk zonder dat keuzes gemaakt worden. Al is het alleen maar omdat een lijntje zo en niet anders getekend wordt. Keuzes beperken altijd. Het doortrekken van dat soort “keuzes” leidt tot het maken van nog meer keuzes, steeds gedetailleerder en steeds technischer, op dezelfde en op andere vlakken. In feite de manier waarop IT-applicaties en -systemen ontwikkeld worden, of het traject nu SDM, OO, TOGAF, Prince-II, dotNet of nog iets anders genoemd wordt.  
 
Als je “ontwerp eerst, dan analyse” zegt stel je in feite dat de analyse het nader invullen van (een deel van) het ontwerp is. Het ontwerp, de logische inrichting van functie, structuur, schoonheid en harmonie voor een “schaal”, leg ik uit op de manier zoals hiervoor besproken is. Analyse is dan dus feitelijk de eerste stap in IT-projecten die de bestaande IT-infrastructuur gaan aanpassen. Projecten kosten tijd (maanden, soms zelfs jaren), en om het goed te kunnen doen zal, zoals gezegd, een schaal gekozen moeten worden die een stabiel ontwerp mogelijk maakt. Anders gaat een later project immers uit van een veranderde situatie, met als groot risico dat de resultaten toch niet op elkaar aansluiten zoals in het ontwerp bedoeld was. 
 
Bij “analyse eerst, daarna ontwerp” ligt alles nogal anders. Om te kunnen ontwerpen is veel kennis nodig, in ons geval alles wat je rond de gegevens die informatie voor je omgeving zijn moet weten. Het veranderen van die kennis kan gevolgen hebben voor het ontwerp. Als we weten dat de organisatie binnenkort een nieuw product of dienst gaat leveren, dan kan het immers zijn dat we daarvoor andere, of anders werkende hulpmiddelen nodig hebben. Dan zal dus het ontwerp aangepast moet worden om die nieuwe ondersteuning een plaats te geven. Met als mogelijk gevolg dat een applicatie ontwikkeling project opgestart (of afgebroken) moet worden, of een verandertraject voor het aanpassen van de huidige ondersteuning ontstaat. 
Je kunt natuurlijk het ontwerp, met al de daarbinnen gemaakte keuzes, de vastlegging van de kennis van de informatie van de organisatie laten zijn. Dat is m.i. veel te kort door de bocht, want in een ontwerp zullen vooral die dingen voorkomen die in het ontwerp, de vormgeving opgenomen zijn. Andere dingen zijn dat niet. Daarom is de eerste stap, de analyse, hier niet een eenmalige analyse, maar een continue. Anders gezegd is het belangrijk om de kennis van een omgeving, bijvoorbeeld een organisatie, rond haar informatie als zodanig te gaan ontwikkelen en beheren. Daarmee wordt de hier bedoelde analyse zelf feitelijk steeds minder werk: we hebben immers beheerde kennis die we kunnen aanvullen, laten groeien. Binnen die kennis zitten, rond de informatie zelf, 20 tot 25 verschillende invalshoeken, onderwerpen die nader uitgewerkt moeten worden. Als de relevante organisatorische en IT kennis rond die informatie ook meegenomen wordt zal het om ongeveer 100 verschillende invalshoeken/onderwerpen gaan.  
In feite vormt deze kennis zelf ook een beeld van de relevante werkelijkheid, en dat zou uitstekend de informatiearchitectuur genoemd kunnen worden. Eén van de onderwerpen daarbinnen is de functionaliteit die als logisch ontwerp uitgewerkt zou kunnen worden. Het ontwerp zoals jullie dat voorstaan. Dat is echter maar één van de verschillende invalshoeken/onderwerpen, en dus maar een klein deel van het geheel. Met, opnieuw, de opmerking dat de gekozen inrichting, het ontwerp dus, geen goede kapstok is voor die informatiearchitectuur. 
 
Analyse voor ontwerp is dus een nogal andere soort analyse dan analyse na ontwerp. Bij de eerste gaat het om de kennis van de informatie die eigenlijk zodanig beheerd moet worden dat het analyseren zelf steeds minder vaak nodig wordt. De tweede soort is het verder uitwerken van een deel van het ontwerp, bijvoorbeeld door de projectopdracht te formuleren (bijv. RFP enz.), of om bijvoorbeeld een business case samen te stellen.  
 
Het zal duidelijk zijn dat mijn voorkeur uitgaat naar analyse voor ontwerp, zoals hiervoor beschreven. Blijft in deze samenvatting nog wat ik denk dat informatiekunde is. Voor mij is dat het vakgebied waar het om de informatie van een omgeving gaat. Aangevuld met het nodige om te weten wat je met die informatie kunt, moet, zal enz. Zowel breed als binnen een omgeving (aandachtsgebied/UoD, “schaal”) waarbij informatie dat gegeven is dat betekenis heeft in de omgeving waar je mee bezig bent. Dat is dus nogal anders dan de notie van de stabiele schaal, of de keuzes die voor het logisch inrichten van een bij die omgeving passende informatievoorziening gemaakt zijn. De kennis van de informatie van de organisatie als bedrijfsmiddel dient om de informatievoorziening, als of niet IT, van een organisatie te richten. Daarom is het ook iets dat aan de kant van de organisatie zelf thuishoort, en niet of nauwelijks iets dat met de inrichting van de informatievoorziening zelf te maken heeft. Of met het verrichten van de werkelijke ondersteuning die deze informatievoorziening geeft. Inrichten en verrichten hoort aan de aanbodzijde, daar waar bijvoorbeeld naar de inzet van hulpmiddelen als IT gekeken wordt. 
 
Voor informatiekunde heb ik overigens nog geen echte opleiding in Nederland kunnen vinden, noch in het hoger onderwijs, nog in het wetenschappelijk onderwijs. Dat is jammer, want informatiekunde slaat de brug tussen organisaties en de inzet van hulpmiddelen als bijvoorbeeld IT. Als je naar het curriculum voor informatiekunde kijkt bevat dat nogal wat verschillende vakken, naar schatting tussen de 20 en de 30, die, elk in een eigen mate, samen die opleiding informatiekundige vormt.  
Jullie leggen informatiekunde rond ontwerp uit. Dat is voor mij dus een te beperkte opzet. Naar analogie met bouwkunde in de bouwwereld spreken jullie zelfs over civiele informatiekunde. Zover ik kan zien staat naast/tegenover de aanduiding civiel alleen de aanduiding water/marine. De toevoeging civiel aan informatiekunde is voor mij dan ook niet nader bepalend. Maar misschien komt dat ook omdat ik, als informatiekundige, ook ervaring heb rond water/marine en zie ik niet wat het woord civiel toevoegt. 
 
Tot zover mijn antwoord op je algemene vraag, Jan. Hoop dat je hiermee verder komt. 
 
 
Steven van ’t Veld 
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

Beste Paul (3/5 13:33) 
 
 
Je standpunt is helder. Het mijne is anders, sterk aarzelend. We hebben al zoveel op dit gebied, en dus is het de vraag of yet-another-method iets toevoegt. Daarbij komt dat het zo groot is, en zoveel werk gaat kosten dat ik me echt, vooral op praktische gronden, afvraag of je die investeringen wel moet doen. Mijn ervaring is dat omgevingen, organisaties, altijd architectuur hebben, en dat je echt geen jaren werk nodig hebt om “het” te krijgen. Bovendien beperkt TOGAF zich vooral om investeringen in IT, wat feitelijk maar 20% van alle uitgaven aan IT is. Daarmee wordt die andere 80% uit de weg gegaan, hier en daar zelfs ontkend.  
En last but not least: het is een ontwikkeling van een kleine groep commerciële organisatie die bepalen wat er met TOGAF gebeurt. Zij spreken zich uit als neutrale groep; dat betekent dat zij het elkaar niet moeilijker zullen maken dan nodig is. Met als consequentie dat de ontwikkeling van TOGAF afhankelijk is van wat deze (commerciële) organisaties als best bruikbaar zien, en wensen. 
Kortom: als het een puur vakmatig geheel zou zijn dat onafhankelijk beheerd wordt zou ik er waarschijnlijk veel minder kanttekeningen bij hebben. Wat ik er de laatste 4 jaar van gezien heb is TOGAF vooral een commercieel vehikel dat zich vooral en voornamelijk richt op investeringen in IT. Ik heb eerder gezegd dat ik The Open Group als een gesloten organisatie ervaar, die niet of nauwelijks dingen toelaat die niet uit de eigen gelederen komen, en zeker niet als het niet (direct) past in wat TOGAF heet. Daarom dus mijn reserve; ik zie TOGAF dan ook vooral(snog) als een commerciële beweging waarvan ik hoop dat het geen volgende hype wordt. 
 
Je vraagt me voor wie ik denk dat TOGAF toegevoegde waarde zal hebben. Als ik naar TOGAF kijk zie ik dat het vooral iets is voor IT-leveranciers. Het is voor mij de vraag of het ook voor interne IT-afdelingen geëigend is, maar dat zal ook afhangen van hoe de mensen in die afdelingen met IT omgaan. Een zelfstandig opererend intern IT-leverancier zal er mogelijk meer aan hebben dan een ingebedde IT-afdeling. Voor die laatste zou het mogelijk een checklist kunnen zijn, waar, zoals ik er nu tegenaan kijk, nogal wat afgestreept moet (en kan) worden. Samengevat dus zie ik het gebruik vooral in de IT-aanbod kant in en rond een omgeving.  
Ik zie niet dat het goed bruikbaar is voor de vraagkant: de informatiekundigen en niet-IT vakmensen in omgevingen. Natuurlijk zal het de discussie met IT-aanbieders enige vorm geven omdat de door IT-aanbieders gebruikte terminologie op TOGAF afgestemd zal zijn. Net zoals dat bij SDM, Prince-II enz. het geval is/was. 
Ik zie ook niet dat het goed bruikbaar is voor de exploitatie-kant van een IT-infrastructuur. Het zal zeker zaken op een bepaalde manier ordenen tijdens het opzetten van de te exploiteren IT, en daarmee zal er invloed zijn, maar ik zie niet zoveel zaken die met die exploitatie zelf te maken hebben. 
Tenslotte is het voor mij de vraag of het veel verandert voor niet-IT-ers. Die zullen misschien merken dat de taal van IT-ers verandert, maar dat is voor hen vaktaal dus het is de vraag of dat iets voor hen gaat betekenen. Hopelijk zal de kennis van IT verbeteren, wat een betere dienst aan de ondersteunde organisatie kan opleveren en dat zou dus wel een voordeel zijn. 
En dan natuurlijk de cruciale vraag: verbetert het de inzet van IT in organisaties? Ik zou het eerlijk gezegd niet weten. Omdat ik meestal vanuit de organisatie vandaan werk zie ik dat er enorm veel te winnen valt rond IT. Met de ervaring in de praktijk dat de beste verbeteringen uit de organisatie zelf komen, en minder uit een efficiëntere inzet van IT zelf. En als ik dat zo zeg dan heb ik het idee dat TOGAF daar ook nauwelijks iets mee kan, want de kern en de invalshoek is en blijft immers IT. 
 
Ik kan, zoals iedereen, alleen vanuit mijzelf praten, uit wat ik zie en wat ik hoor. Daarom staat mijn naam hier ook onder, en mijn email adres. Natuurlijk zijn er mensen die objectiever naar zaken kijken, en mensen die subjectiever bezig zijn. Door wat ik doe en de vele organisaties die ik zie zou ik objectiever bezig moeten zijn, maar zodra ik mijn mening gevormd heb is die natuurlijk altijd weer subjectief. Daarom bied ik mijn mening hier aan, en hoop ik te leren van de reacties en ervaringen van anderen. Want ook hun mening kan immers alleen subjectief zijn. Daarom kan ook niemand het grote gelijk claimen. Alleen als je iets al letterlijk 100 keer gezien en nog meer keer gehoord hebt krijg je de neiging om…… 
Ik heb niet het idee dat ik ergens de enige werkelijkheid claim. Maar ik schrijf mijn teksten snel, en dat zal hier en daar te weinig genuanceerd zijn. Toen ik van jou las: “zoals mijn feitelijk en onbetwistbaar enige juiste definitie van architectuur (met een WWW)” kon ik daar de nuance niet in vinden, en daar heb ik dus op gereageerd. Al is het alleen maar omdat ik je definitie te beperkt is voor mijn praktijk. 
 
En die oproep aan de TOGAF aanhangers was echt gemeend. Jammer dat ze dit soort discussies kennelijk alleen in de eigen kring voeren, en niet naar buiten treden. Het bevestigt wel weer het beeld van een gesloten organisatie dat ik van The Open Group heb. 
 
 
Steven van ’t Veld 
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

In de voorlaatste post stelt Van ‘t Veld “… over schaal: een afbakening van zicht, en dus van werk.” Dat is wat ik een ‘tweedimensionale afbakening’ van ... het begrip ‘schaal’ noem. Alles wat daarna volgt is helder en begrijpelijk, en voor velen wellicht herkenbaar. Het is echter (juist) niet een verheldering van wat ‘schaal’ in driedimensionale (hier gebruikt als analogie) duiding beoogt. Daarom ook vereist het overstijgen van de huidige beperkingen een paradigmawissel, al was het maar omdat het huidige paradigma (dat Van ‘t Veld uitstekend verwoord) niet verder komt dan steeds opnieuw zichzelf bevestigen. Het is deze paradox: “ ... schaal, nu als onafgebakend gezichtspunt, en dus van ontwerp”. Onvoorstelbaar, zelfs onmogelijk, vanuit het tweedimensionale. 
 
Twee vingerwijzingen: #1 infrastructuur omvat ook en met name (ontwerp)principes; #2 maatschappelijke schaal omvat alle andere schalen en uitzonderingen worden op de juiste (lagere) schaal geregeld. Ik geef ook twee voorbeelden: #1 ‘rechts rijden’ is op verkeerschaal een (ontwerp)principe voor de totale infrastructuur. #2 bij plaatselijke, meestal tijdelijk, afwijking van ‘rechts rijden’ regelen we dat ... ter plaatse, en alleen daar. Zo bezien bevat de bijdrage van Van ‘t Veld een uitstekende uitleg over die uitzonderlijke schalen, als deelgebieden, en over de benadering van de uitzondering. Het probleem waartegen ik zelf steeds aanloop kan ik daarmee als volgt verwoorden: het denken dat het organiseren van uitzonderingen hetzelfde is als, of kan zonder, het ontwerpen van het geheel. Ook wat Van ‘t Veld heel duidelijk en leerzaam over SOA zegt is een impliciete bevestiging van het maximale niveau van waaruit wordt geredeneerd, en dat is de ‘schaal’ zoals Van ‘t Veld die definieert (het afgebakende deelterrein) en de beperking van de specifieke behoefte als leidraad: tweedimensionaal. Natuurlijk begrijp ik de lastigheid en persistente misvatting, dat het geheel de optelsom is van alle delen, goed: het Internet is daar immers een voorbeeld van. Alleen is datzelfde Internet juist een resultaat van de optelsom waartegen Van ‘t Veld (terecht) strijdt: een verzameling van technische deeloplossingkjes die op een technische wijze aan elkaar zijn verbonden. Internet heeft geen ‘last’ van de ontwerpstappen van ‘informatie’ en dat is ook precies waar we nu keihard tegenaan lopen. Immers: beste Steven, wie ben jij? Volgens Internet: “Results 1 - 10 of about 126,000,000 for Van ‘t Veld. (0.38 seconds)”. Daar hebben we dus helemaal niets aan! En wie nu denkt dat ik mijn vraag ‘aan het Internet’ dan nader had moeten verbijzonderen (en daarmee de noodzaak van informatie-ontwerp raakt) die wil ik graag uit die droom helpen. Niet alleen omdat het aangeven van steeds meer specifieke informatie aan een ‘zoekbewerking’ om uiteindelijk op een enkel ‘antwoord’ uit te komen de verkeerde/omgekeerde weg is (en beter moet en beter kan, lees Metapattern), maar ook omdat we dan nog geen enkele garantie hebben over de kwaliteit van dat enkele antwoord dat uit onze uitvoerige zoekopdracht voortkomt: en dat komt omdat exact dàt onderdeel ... niet is ontworpen. Ofwel: er is een absolute noodzaak om het principe van contextuele verbijzondering als ontwerpprincipe voor de totale informatiemaatschappij te hanteren. 
 
Over de volgordelijkheid van ontwerp en analyse, of van analyse en ontwerp, geeft Van ‘t Veld m.i. een prima uitleg, en maakt een goede case voor het analyse-ontwerp-analyse ‘traject’, met mijn toevoeging dat Van ‘t Veld dit consequent doet vanuit, en gericht op, de deelgebieden naar zijn eigen uitleg van ‘schaal’. Prima! Binnen die beperking volg ik hem en neem het graag van hem aan en over. De generieke ‘schaal’ vergt echter, alweer, een paradigmawissel in (ook) die benadering. Terug naar mijn eerdere voorbeeld van de verkeersregel ‘iedereen rijdt rechts’: enige discussie over de volgordelijkheid van analyse en ontwerp of vice versa zal, naar ik mag hopen, voor de goede verstaander op die ‘maatschappelijke schaal’ zinloos over komen. Dergelijk ontwerp (op dergelijke schaal) is immers meer wiskundig van aard dan zoals Van ’t Veld het gebruikt (ontwerp = vormgeving) en heeft veel meer overeenkomst met een fractal-benadering dan met het vormgeven van enige specifieke oplossing. Mag ik de lezer in dat verband eens uitdagen om na te denken over bijvoorbeeld het ‘ontwerp-principe’ van dotindividual (persoonlijke informatie is persoonlijk eigendom)? Enorme consequenties op allerlei vlak en niveau, maar de vraag naar analyse-ontwerp volgorde is, zoals de kip/ei-vraag, hier irrelevant. 
 
Met Van ’t Veld’s definitie van informatiekunde kan ik het niet eens zijn: ‘brug tussen organisaties en de inzet van hulpmiddelen als bijvoorbeeld IT’. Toch zie ik in zijn verdere uitleg hoopvolle signalen richting contextuele verbijzondering (‘... waarbij informatie dat gegeven is dat betekenis heeft in de omgeving waar je mee bezig bent’) maar mis toch, ook hier weer, het toepassen van deze ‘relativering’ op de eigen begriphantering en –inhoud, hier dus over ... (het begrip) informatiekunde. Interessant is het dat juist Van ’t Veld de duiding van informatiekunde (zoals Van Til m.i. doet:) op maatschappelijke schaal, en omvattende de principes voor contextuele verbijzondering, als ‘te beperkt’ want ‘informatiekunde [alleen] rond ontwerp uitgelegd’ typeert. Het beeld van een in zichzelf verdeelde Roomse Kerk die strijdt tegen de verkeerde idee dat de aarde rond de zon draait doemt op: Copernicus’ heliocentrische kosmologie vertoont grote overeenkomst met ‘maatschappijcentrische informatiekunde’, en ook in de reacties op Copernicus zie ik, inderdaad, overeenkomsten met discussies als in deze thread. Niets nieuws onder de zon dus, zoals Plato’s Grot en Magritte’s pijp ook al aangaven. 
 
Hamvraag en terug on topic: kan TOGAF iets bijdragen aan de ontwikkeling waarbij we af groeien van het IT-centrisch denken? Ik denk zeker wel! TOGAF9 biedt daar, binnen de beperkingen van de (beperkte) schalen, zeker aanleidingen toe. Kan TOGAF ook bijdragen aan het toepassen vanuit dat andere paradigma, die ‘maatschappijcentrische informatiekunde’? Ook daarin denk ik, juist voor degenen die in het huidige paradigma blind hun weg kunnen vinden, dat TOGAF behulpzaam kan en zal zijn. Het is zeker geen 'universeel wondermiddel' maar kan zeker, in specifieke contexten, een bijdrage leveren aan verbetering van de aansluiting van (kleinere) schalen op de maatschappelijke schaal.  
 
Paul Jansen

Beste Steven, 
 
Terwijl ik nog aan het prakkiseren was over antwoord op jouw zo uitgebreide bericht van 12 mei 2009 00:45, was daar opeens die krachtige en to the point bijdrage van Paul Jansen (16 mei 2009 18:49). Die bijdrage is wat mij betreft niet meer en niet minder dan… antwoord! Antwoord waar ik nog naar zocht. Dank je wel Paul! Daardoor kan mijn bijdrage nu kort zijn. Ik hoef er niets meer aan toe te voegen; een iets andere verwoording is alles wat mij rest. 
 
Steven, naar mijn idee roep je in je bijdragen voortdurend (om) ‘planologie’. Je ziet heel scherp dat en hoe de ‘hele huidige boel’ vastloopt in ‘ontwerp’. Tegelijkertijd beschrijf je, naar mijn idee, ‘planologie’ stelselmatig in termen van ‘ontwerp’. En dat lukt niet. ‘Planologie’ verschilt immers kwalitatief van ‘ontwerp’. Je kunt het driedimensionale leven nu eenmaal niet uitleggen met de termen die je vanuit het tweedimensionale ter beschikking staan. Dat is eenvoudigweg onmogelijk. Punt. Klaar. 
 
Mijn oproep – en ook die van Paul en Pieter – is dan ook: laat ‘ontwerp’ los! Zet het eens even radicaal uit je hoofd. Laat vervolgens ‘planoloog’ echt binnenkomen – dwz. niet gefilterd (lees ook: versplinterd) door ‘ontwerp’. Dan… dan ‘doe’ je de paradigmasprong! Zoals Paul het verwoordde: “Het is deze paradox: ‘ ... schaal, nu als onafgebakend gezichtspunt, en dus van ontwerp’.” Inderdaad: “Onvoorstelbaar, zelfs onmogelijk, vanuit het tweedimensionale.”

Beste Paul (16/5 18:49) 
 
 
Dank voor je antwoord. Ik kom er echter niet zoveel verder mee, en ik zal proberen dat uit te leggen. 
 
Je benoemd mijn uitleg van het begrip schaal, wat dus niet mijn begrip is maar een begrip dat ik tracht te interpreteren, als tweedimensionaal. Daarna stel je dat 2 dimensies niet voldoende is, maar je geeft daar verder geen invulling aan wat dan de 3 dimensies zouden zijn. Het is voor mij niet duidelijk wat jij onder een n-dimensionale schaal verstaat. Daarnaast verwijs ik naar het veel rijkere begrip Universe of Discourse (UoD) uit ISO TR9007 en het nogal verkeerd uitgelegde begrip Viewpoint uit het werk van ISO/ODP. Zoals het nu is kan ik er niet verder mee. Misschien dat een uitleg van je nieuwe paradigma daarvoor nodig is. 
 
Dan je vingerwijzingen.  
 
Je stelt als eerste dat infrastructuur ook en met name (ontwerp) principes bevat. Dat zou ik anders verwoorden. Bijvoorbeeld: bij het inrichten van “deze” infrastructuur zijn de volgende (ontwerp)principes gehanteerd.  
Zoals ik eerder heb aangegeven zie ik zowiezo punten rond het principiële van ontwerpprincipes. Als het om ontwerp gaat is e.e.a. vaak te zeer afhankelijk van gebruikte technologie, en in hoeverre je dan over principiële zaken kunt spreken is voor mij de vraag. Als het om meer basale afspraken gaat als “rechts rijden” zou ik het geen ontwerp principe meer willen noemen, maar een afgesproken regel die ik ook algemeen in de organisatie zou willen laten beheren omdat die ook voor niet-IT technologieën geldig is. Je kunt dan zo’n regel bij de IT-infrastructuur opnemen, maar dan heb je grote kans dat die regel op diverse plaatsen herhaald wordt, met alle consequenties van afwijkingen van dien. 
Nog een punt is dat er een probleem ontstaat als zo’n regel wijzigt. Dus, in het voorbeeld, van rechts rijden naar links rijden. Met het aanpassen van de regel verandert geen enkele infrastructuur. Want er moet immers werk komen om die aan te passen, en tot dat moment is de infrastructuur (of delen daarvan) echt nog op rechts rijden gebaseerd. Terwijl de algemene afspraak toch echt links rijden is. Daarom dus een vraagkant met wat de organisatie uitspreekt en een aanbodkant van bijvoorbeeld de infrastructuren van een organisatie die volgens regels opgebouwd is die misschien niet meer hoeven te gelden. Dus daarom is een eenduidige vraagkant voor een organisatie echt belangrijker dan alle aanbodkanten samen, zoals wens tegenover realiteit staat. 
 
In je 2e punt heb je het over een maatschappelijke schaal. Mogelijk dat je daarmee wat ik hierboven even snel vraagkant heb genoemd bedoel. Het zou ook kunnen zijn dat ik je het beste kan verwijzen naar bijvoorbeeld de systeemniveaus in de systeemtheorie van de bioloog Boulding uit 1956. Zo zie je waarom ik een hekel heb aan het huidige gebruik, ik vind misbruik, van het woord principe omdat iets dat je een principe noemt bij een bepaald systeemniveau hoort, en daarmee hoogstens vertaalbaar is naar iets wat op een ander systeemniveau geldt. Eenzelfde principe geldt in het sociale systeem (misschien is dat jouw maatschappelijke) is immers anders dan een gelijk principe het open systeem of het cybernetische systeem. 
 
Je probleem rond het managen van regel en uitzonderingen wordt heel simpel als je in iets als vraagkant en aanbodkant denkt, en werkt. Eigenlijk heb ik dat al gezegd, maar nu met een voorbeeld: de laatste jaren wordt de regel steeds meer dat we zuinig met energie moeten omgaan. Groen, dus. Dat kunnen we in de organisatie afspreken, en daarmee wordt het een regel. Die regel is echter nieuw, en dus in eerste instantie nergens gehanteerd. De gehanteerde regels dienen bij wat we hebben opgenomen te worden. Auto’s zijn immers gebouwd en hebben een bepaald energiegebruik. Die regels zullen snel ouder zijn dan de afspraken die we voor nieuwe auto maken. Als je nu bij de bestaande auto’s aangeeft aan welke regels die voldoen kan je zien of zo’n auto aan de huidige regel zou voldoen, waarbij het nog iets ander kan zijn wat het energieverbruik van een exemplaar is. Als je de afwijking niet accepteert zal je iets moeten gaan doen, anders kan het zo blijven. Als je over uitzonderingen praat wordt het nog iets anders. Want dan zou je een auto gaan neerzetten die niet aan de afgesproken regel voldoet. Dus als die auto opgeleverd wordt weet je dat die regel niet gehanteerd is, om welke reden dan ook. Dat is natuurlijk mogelijk, maar dan alleen als een beslisser daartoe besloten heeft. Het tast geen enkele regel aan, niet die aan de vraagkant, noch de gehanteerde regels aan de aanbodkant. En daarmee is het dus gewoon te managen, en geen probleem meer. 
 
Als ik nogmaals verwijs naar Boulding, dan is de kans dat het geheel alleen de optelsom van de delen is alleen goed mogelijk op het laagste systeemniveau. Hoe hoger je komt, zoveel minder dat het geval is. Met als consequentie dat een afbakening op laag systeemniveau ook veel beter mogelijk is dan op hoger systeemniveau. Hogere niveaus zijn er steeds meer factoren die meespelen, en ik heb een beetje het idee dat jij dat dimensie noemt. Ik denk dan dat je toch eens goed de term Universe of Discourse moet bekijken. Alleen is daar het strikte indelen in dimensies zelden mogelijk omdat je daarmee een soort orthogonaal suggereert die er gewoon niet is. Daarom was het originele idee van viewpoint ook zo aardig, alleen is dat binnen ISO/ODP feitelijk om zeep geholpen. 
 
Internet is voor mij een redelijk laag systeemniveau. Ook een virtuele wereld kan daar weinig aan doen. Daarom zie ik ook dat internet, feitelijk een combinatie van extranetten, vooral gevuld is met gegevens. Daar moet je de gegevens nog uit zoeken die voor jouw (of je organisatie) informatie is. Juist de beweging naar een volgende versie van internet laat zien dat die ontwerpstappen van informatie juist wel nodig zijn. Dat is nu precies hét probleem, zoals je volgens mij ook zegt. 
 
Wie ik ben? Tja, die vraag kan ik op vele manieren beantwoorden. Als ik het filosofische en het reële even naast me neerleg hou ik het in het kader van informatiekunde hier bij een referentie: lees het boek Data and Reality van Bill Kent maar eens. Of kijk eens naar de lexicaal/non-lexicaal theorie. Wie ik ben is immers iets anders dan hoe ik me bijvoorbeeld noem, of genoemd wordt. Zeer verhelderend. Ik griezel van je “Results 1 - 10 of about 126,000,000 for Van ‘t Veld. (0.38 seconds)”: ben ik dus 126 miljoen results? Of ben ik gewoon ik, en wordt 126 miljoen keer iets over of rond mijn achternaam gezegd zijn op het IT-systeem internet? Aan dat laatste hebben we niet alleen niets, het zegt ook te weinig over mij. Want zo mijn achternaam, ik heb bijvoorbeeld 2 zonen die ook Van ’t Veld heten, al iets over mij zegt is het alleen maar wat over of rond mij gezegd wordt. Maar dat ben ik niet….. Om nog maar te zwijgen over wat mensen al niet over mij kunnen zeggen, waar of niet waar. De kwaliteit dus, inderdaad. 
 
Internet is een vrije bron van informatie waar steeds meer organisaties problemen mee hebben. Daarom kan het alleen een bron zijn, tenzij we, organisaties, zeker kunnen zijn van de kwaliteit van wat gezegd wordt. Daarom zal de toekomst steeds meer zijn dat we zaken als organisatie waarderen en dan volgens die waarde gebruiken. Wikipedia is wat dat betreft een schrijnend voorbeeld. Elke idioot kan daar zijn ideeën inzetten. Misschien filtert zich dat ooit weer uit, maar wanneer is dat het geval? En weten we ook wanneer dat het geval is? Daarom is dat gewoon een slechte bron, die alleen intelligent te gebruiken is. Als organisatie zal ik de eigen waarheid daar tegenover moeten zetten, waarbij internet als te filteren basis kan dienen. Maar meer ook niet. Je kunt dan proberen elementen van het internet achteraf te gaan waarderen, maar daarmee loop in de oude kuil van het aanpassen van iets versus het nieuw ontwikkelen: wat levert voldoende kwaliteit tegen de juiste prijs. En dan zal internet nog zeer driftig moeten wijzigen. 
 
Voor je punt rond analyse-ontwerp-analyse verwijs ik hier naar de genoemde systeemtheorie. Ik krijg het gevoel dat je paradigmawissel en je generieke schaal heel dicht bij het anders benaderen dat bij de resp. systeemniveaus hoort.  
 
Ik weet niet precies wat je met fractal benadering bedoeld, maar mogelijk dat het past binnen de brede kennis die vraag naar informatie onderbouwd en het infrastructurele (ontwikkelen en beheren) die het aanbod van informatie regelt. Start je met een project, dan pak je maar een stukje van het geheel, en dat stukje is wel onderdeel van het (gekozen) geheel. Je eerste analyses in een project zijn daarom in te passen in dat geheel, waar de te analyseren elementen natuurlijk inzetten. Noem het verticaal benaderen (project) naast horizontaal (“generieke schaal” breed) kennis hebben. Daarmee pak je dus ook het “persoonlijke informatie is persoonlijk eigendom” op, want informatie is iets in het geheel, en per project wordt een deel daarvan verder uitgewerkt. Zowel het feit dat bepaalde gegevens voor de omgeving informatie is, alsook het eigendom van die informatie. Juridisch gezegd dus eigendom, houderschap naast gebruik. Met opnieuw de opmerking dat iets dat je weet niet hetzelfde is als het ding zelf waar je die kennis dan van hebt.  
Met als voorbeeld het EPD. Daar is het gevecht dat informatie over patiënten eigendom van de patiënt is, maar dat het organisaties/mensen zijn die houder en gebruiker van die informatie zijn. Omdat ik dat niet goed geregeld vind, en vele andere dingen ook niet, heb ik bezwaar gemaakt tegen mijn informatie in het EPD. Daarom is je regel, je noemt het waarschijnlijk een principe, “persoonlijke informatie is persoonlijk eigendom” veel te beperkt. 
 
Je zegt dat ik informatiekunde definieer als de “brug tussen organisaties en de inzet van hulpmiddelen als bijvoorbeeld IT”. Ik weet niet hoe dit komt, maar zo zie ik dit niet. Informatie is voor mij, in lijn met de ISO definitie, het gegeven dat voor mij betekenis heeft. Of: Informatie is voor mijn organisatie het gegeven dat voor mijn organisatie betekenis heeft. Informatiekunde is voor mij het vak waar het rond informatie draait. Informatie technologie is voor mij een techniek die zijdelings met informatiekunde te maken heeft, een technologie om informatie beter ter beschikking te krijgen. De “brug tussen organisaties en de inzet van hulpmiddelen als bijvoorbeeld IT” wordt vaak aangeduid met IT-business alignment. Daar vinden we de informatie oplossingen die we de organisatie bieden die gerealiseerd zijn met IT. Aanbodkant, dus. Informatiekunde is vraagkant. Ik weet niet hoe jij aan de door jou gegeven definitie komt, maar dat is niet de mijne. 
 
Ik weet niet of je de referentie naar Jan van Til goed uitlegt. Zoals ik het werk van Jan, Jaap en Pieter cs. lees is ontwerp daar iets dat centraal staat, en daar kan ik het niet mee eens zijn. Dat zie ik ook in mijn praktijk, want daar is ontwerp één van de vele zaken die men heeft en nodig heeft, waarbij ontwerp ook vooral nog eens een extra grote mate van detail geeft. Met de vraag of je daar altijd behoefte aan hebt. Daarom heb ik het steeds over kennis van informatie, en niet over ontwerp en principes. 
 
Ik blijf het niet met je eens over TOGAF. Zo lang we over IT en over IT-leveranciers spreken zie ik dat het goed werk kan doen. Met de aantekening dat het het zoveelste probeersel is van iets dat zoiets beoogt. Aan de organisatiekant zelf zie ik geen nut. De gerichtheid op IT is daarvoor te zwaar beperkend. Het geeft voor mij de beperking aan van hoe ver IT-ers een organisatie in kunnen kijken. IT-ers die denken als informatiekundige te gaan werken hebben zowiezo een probleem omdat ze dan een ander vak moeten aanleren. En TOGAF heeft daar geen mogelijkheden voor. En daarom ook mijn mening dat business analyse feitelijk buiten TOGAF hoort. Een mening die sterk gestaafd wordt door de discussies en ruzies die rond business analysis in de TOGAF gelederen gevoerd worden. 
Nog een simpele vergelijking: monteurs en auto ontwerpers moet je geen land laten inrichten omdat hun uitgangspunten anders zijn dan die van een landschaps architect. 
 
 
Steven van ’t Veld 
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it

Beste Jan (18/5 8:54) 
 
 
Mooi dat jullie elkaar gevonden hebben. De bijdrage van Paul is inderdaad substantieel, en grotendeels helder. Zie mijn antwoord, hierboven. 
 
Volgens mij zijn we het feitelijk eens over ontwerp versus planologie. Ontwerp is, zoals ik gezegd heb, voor mij een stevig gedetailleerde uitwerking van gewenste functionaliteit die naast vele andere kennis van informatie nodig kan zijn. Ik heb ontwerp neergezet als het aangrijpingspunt om het naast “planologische” concepten te zetten. Planologie en ontwerp zijn voor mij zeker niet hetzelfde. Sterker nog: ontwerp is een detail binnen het geheel van kennis dat nodig is om een informatievoorziening te kunnen richten. Ik heb niet het idee dat ik planologie stelselmatig in termen van ontwerp heb beschreven. Ik heb geprobeerd het naast elkaar te zetten, waarbij informatiekunde voor mij juist datgene is waar de kennis van informatie zich bevindt, en ontwikkeld wordt.  
 
Je laatste paragraaf heb ik even over na moeten denken. Mijn betoog is juist dat ontwerp als kern losgelaten moet worden. Daarom haal ik juist het werk van Alexander als invalshoek voor informatiekunde aan zodat ik duidelijk kan maken waar dat past, en waar het tekort komt.  
Als ik je reactie zo lees herinner ik me dat ik een vergelijkbare verschuiving van paradigma heb gemaakt in 1988/1989, waarbij ik het projectmatige en het beheersmatige ben gaan relativeren. Dus ook ontwerp. Ik begrijp alleen niet dat je me adviseert om ontwerp als kern los te laten; dat heb ik dus 20 jaar geleden al gedaan. Als dat niet uit mijn tekst blijkt, dan heb ik iets verkeerd gedaan. 
 
 
Steven van ’t Veld 
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it