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 
Steven.van.t.Veld@AIM.nl