Van Rees over informatiekunde en zijn constructieprincipes

Pieter Wisse

Hoe nieuw en uniek is objecttechnologie (OT) eigenlijk? Met deze vraag als leidraad had ik een gesprek met Jaap van Rees, directeur van het gelijknamig adviesbureau voor informatiekunde te Rotterdam.

Waarom Van Rees? Mijn reden luidt dat hij volgens mij als eerste in Nederland informatiekunde nst informatica als een heus, samenhangend vak beschouwde. Daarom heeft hij een uitgesproken opvatting over onder meer methoden en technieken die de vaklieden in kwestie, de informatiekundigen en informatici dus, kunnen hanteren. Ik weet verder dat Jaap van Rees zijn kennis & ervaring verdicht tot wat hij architectuur- en constructieprincipes noemt.

Vroeger behandelde Van Rees, die met zijn adviesbureau vooral als opleider in het vlak van informatie-analyse ruim bekendheid geniet, OT niet expliciet. Dat kon ook niet want de noemer objecttechnologie was onbekend. Toch blijkt de huidige theorie achter objecttechnologie sterk overeen te stemmen met nogal wat van zijn tot dusver geformuleerde constructieprincipes. Dat is interessant. Ik wilde dat allemaal weleens horen. Dit is het resultaat van ons gesprek. Achteraf bleek overigens dat woorden als object en objecttechnologie nauwelijks gevallen waren. Is dat omdat objecttechnologie zo uniek en nieuw niet is? Ons gesprek ging in elk geval meer over zoiets als grondslagen van de informatiekunde. Die grondslagen zijn en blijven k voor objecttechnologie uiterst relevant.

 

 

even geduld

P: Kunnen we concreet met principes beginnen? Wat vind je zlf het belangrijkste principe?

J: Zo simpel is het niet. Ik kan wel zeggen, bijvoorbeeld, dat informatie en meta-informatie van elkaar gescheiden moeten zijn. En dat zo'n scheiding geldt voor zowel opslag als verwerking. Daarmee heb ik inderdaad n van mijn constructieprincipes genoemd. Tegelijk weet ik zeker dat niemand dat zonder uitvoerige toelichting begrijpt. Overigens koos ik er opzettelijk eentje die erg abstract klinkt. Ik bedoel maar, er hoort een verhaal bij.

P: Jouw principes voor architectuur en constructie van informatievoorziening zijn geen tips die je zomaar kunt toepassen?

J: Helaas is dat nog steeds een enorm misverstand. De inrichting van informatievoorziening is echt een vak. Het is netzo makkelijk, maar ook netzo moeilijk als vele andere vakken. Er is domweg geen principieel verschil. Toch willen veel mensen het snel leren, in een korte cursus. Of liefst met enkele tips. Dat gaat ng sneller, nietwaar? Dat is de moderne misvatting van de check list.
Zelf geef ik al vele jaren aan vele mensen cursussen. Wat ik daarin aanreik, is een begin van een orintatie, steeds wat moeilijker om verdere ontwikkeling te stimuleren. Een vakbekwame informatiekundige kan ik niet in drie dagen klaarstomen. Dat is belachelijk.
Wie laat zich opereren door een hartchirurg die na zijn1 middelbare school slechts drie dagen theorieles en geen enkele praktijkervaring gehad heeft? Vijf of tien keer drie dagen cursus is trouwens ook nog lang niet genoeg. Zo iemand noemen we toch eigenlijk zelfs geen hartchirurg. Of neem een huis. Wie geeft opdracht voor ontwerp van zijn nieuwe huis aan iemand die niet aantoonbaar over kennis en ervaring beschikt? Dan wil je toch een echte bouwkundige architect? Echt betekent allereerst dat alleen hun formele opleiding al vele jaren duurt. Graag willen we ook weten dat ze eerder succesvol waren. Wat je voor je huisontwerp bijvoorbeeld niet zoekt, is een makelaar, hoe knap en goed opgeleid zo iemand ook in diens vak is.
Merkwaardig genoeg vergeten opdrachtgevers vaak dergelijke gerichte eisen te stellen als het om de informatievoorziening in hun organisatie gaat. Zo is informatiekunde ook cht een vak apart. Daarbij blijkt het in verhouding zelfs een behoorlijk moeilijk vak, zoals goede bouwkundige architecten ook zeldzamer zijn dan goede makelaars in onroerend goed. En behalve betrekkelijk moeilijk is dat vak van de informatiekunde momenteel nogeens sterk in beweging.

P: Dat houdt in, dat hoor ik je tenminste zeggen, dat bijbehorende architectuur- en constructieprincipes wat hun toepassing betreft eigenlijk alleen aan de vaklieden besteed zijn. Dat ziet er voor dit gesprek dan somber uit. Ik hoopte dat je aan betrekkelijke leken iets zou kunnen uitleggen.

J: Dat kan k prima aan de hand van architectuur- en constructieprincipes. Wie dit leest, moet echter niet denken dat hij ze zonder enige diepgaande opleiding en ervaring, zomaar dus, kan hanteren. In mijn opleidingen orinteer ik de cursisten door onder andere enige constructieprincipes te behandelen. Maar ik herhaal dat dergelijke principes pas waarde hebben in de context van het gehele vak en vakmanschap. Waar ik als adviseur en ontwerper optreedt, blijf ik er ook zelf bij.
De lezer moet daarom even geduld hebben. Voordat we het over concrete principes kunnen hebben, en dan eveneens bij wijze van algemene orintatie, is dat verhaal nodig dat de noodzakelijke context verschaft.

 

 

vak en bril

P: Je hebt het nadrukkelijk over bemoeienis met de status van een vak. Blijkbaar moeten het daar allereerst over hebben. Waarom vind je informatiekunde een apart vk?

J: Allereerst is het nuttig om in het algemeen te begrijpen wanneer wij iets een vak noemen. Dat heeft te maken met een manier van kijken die anders is. Met andere woorden, elk vak heeft een zogenaamd paradigma. Je kunt het ook een eigen bril noemen.
De informatiekundige kijkt en ziet een organisatie als een informatieverwerkend geheel. Daarbij is voor hem informatieverwerking ruimer dan wat er geautomatiseerd gebeurt. Hij kijkt naar alle informatie, dus ook en vooral hoe mensen ermee omgaan. Zo'n manier van kijken, en als gevolg daarvan het resultaat, verschilt van hoe de meeste andere mensen dat doen. Daarom is informatiekunde een apart vak.
Informatiekunde is om deze reden beslist geen informatica. Dat kan ik vanuit het besef van eigen brillen eenvoudig uitleggen. De informaticus ziet op zijn beurt weer wat vele andere mensen normaal niet zien. In het paradigma van de informatica staan middelen centraal. Dat zijn zelfs alleen maar middelen voor geautomatiseerde informatieverwerking, dat wil zeggen aparatuur, programmatuur ofwel informatietechnologie in het algemeen.

 

 

informatiekunde vanuit informatica

Natuurlijk hebben informatica en informatiekunde vanalles met elkaar te maken. Het laatste, informatiekunde dus, ontstaat als apart vak uit het eerste. Pas nadat informatietechnologie op een bepaalde schaal toegepast werd, ontstond de behoefte aan een ruimere zienswijze. Precies in dezelfde volgorde is verkeerskunde voortgekomen uit onder andere de autotechniek. Met weinig auto's hoef je nog niet veel te regelen. Als het er meer worden, blijkt de kunde van hun samenhangende toepassing onontbeerlijk.

P: Hebben we met dat onderscheid tussen informatiekundige en informaticus ook meteen het verschil tussen enerzijds architect, anderzijds aannemer ofwel constructeur te pakken?

J: Dat heb ik lang gedacht, maar zie ik inmiddels anders. Nu denk ik dat er twee dimensies zijn. Langs de ene dimensie maak ik onderscheid naar het vak. In dit geval hebben we het over informatiekunde, respectievelijk informatica. Langs de andere dimensie plaats ik de rol die iemand in een veranderingsproces speelt. De architect en de constructeur beschouw ik als zulke rollen.
Aldus ontstaat in z'n eenvoudigste opzet een matrix met vier elementen. En element daarvan is de architect van de organisatie als informatieverwerkend geheel, ofwel de informatiekundige architect. Daarnaast is er de architect van de middelen voor de informatieverwerking. Dat is dan de informatica-architect. Met betrekking tot de constructeur is er dezelfde nuancering, dat wil zeggen een informatiekundige constructeur en een informatica-constructeur.

P: Alvast concreet over n element, die informatiekundige constructeur, wat kan ik me daarbij voorstellen? Wie mkt de organisatie als een, wat jij noemt, informatieverwerkend geheel?

J: Daar ben ik inderdaad nog niet uit. Misschien is dat element niet gevuld. Of misschien hebben we het daar over de maker van de administratieve organisatie.
Die matrix, die je trouwens kunt uitbreiden met meer vakken en/of rollen, heeft trouwens in mijn denken allerminst een definitieve status. Ik zoek naar een manier om vooral het vak van de informatiekunde duidelijker te kunnen plaatsen. Dat lukt al aardig. Ik kan ermee aangeven, duidelijker dan ooit, wat de ontwikkeling van informatiekunde als vak optimaal gezien is.

 

 

dimensies: vak en rol

Ik benadruk nog even wat die twee dimensies van elkaar onderscheidt. Aan de ene kant beschouw ik informatiekunde en informatica als verschillende vakken. Dat heeft, zoals ik zei, met een manier van kijken te maken. Waarin aan de andere kant de architect en de aannemer van elkaar verschillen, vind ik meer liggen in hun manier van doen. Het zijn, dus min of meer ls van respectieve vakken, rollen in een veranderingsproces. De aard van hun betrokkenheid verschilt.

P: Maar omdat de informatiekundige en de informaticus, zoals je zegt, elk hun eigen vak hebben, verschilt de aard van hun betrokkenheid toch ook al?

J: Ja, maar tegelijk is het anders dan het onderscheid tussen een architect en een aannemer. Wat is in het algemeen kenmerkend voor een architect? Ik bedoel dus dat het niet uitmaakt of een architect een kantoorpand, een stadswijk, een organisatie als informatieverwerkend geheel enzovoort ontwerpt. Kenmerkend vind ik dat een architect iets persoonlijks inbrengt. Met een andere architect krijg je geheid een ander ontwerp en tenslotte een ander resultaat. Dat komt, en dat is ook kenmerkend, omdat een architect met vele vrijheidsgraden werkt. Moet werken. Situaties kunnen enorm van elkaar verschillen. Het resultaat van de bemoeienis van een architect is voorts sterk afhankelijk van zijn kennis en ervaring. Als je daarop let, zie je dat de ene architect inderdaad de andere niet is. Trefwoorden voor de aard van de betrokkenheid van een architect vind ik bijvoorbeeld synthese, rendement en cultuur. Bij een aannemer denk ik aan andere trefwoorden. Dat zijn onder andere analyse en efficiency. De onderlinge verschillen tussen aannemers zijn minder groot dan tussen architecten.

 

 

vechter voor schoonheid

P: Moet ik nog raden hoe jij jezelf positioneert?

J: Dat lijkt me wel duidelijk. Architect. Informatiekundig architect, om het volgens mijn matrixindeling precies te zeggen. Mijn vk, dat is de informatiekunde. En onlosmakelijk claim ik altijd die rol van de architect. Met de betrokkenheid die ik erbij voel. En ik doe dat, als dat volgens mijn gevoel moet, tot de grens van het toelaatbare. Waar ik als architect voor vecht, is de schoonheid van de constructie. Inderdaad, tot en met de informatica-constructie.
Ik noem dat schoonheid, omdat ik met n woord mijn doel niet anders kan aanduiden. Het gaat om het invoegen — let wel invoegen, niet invoeren — van veranderingen in organisaties. Dat moet passen in de cultuur. Ik noemde het trefwoord synthese al. Dat zijn toch allemaal vooral kwalitatieve aspecten, dus roep ik kortweg schoonheid.
Die rol van zo'n architect is nodig. Anders wordt het ook met informatievoorziening in organisaties echt een puinhoop. Zonder aandacht voor die kwalitatieve aspecten gaat de vervuiling hopeloos door. Helaas zijn bewijzen van gebrekkige informatievoorziening alom zichtbaar. Als dat niet verandert, stikken we uiteindelijk in de informatietechnologische rotzooi.
Als onderdeel van opleidingen die ik verzorg voor informatie-analisten, behandel ik al heel lang het zgn. tribunaal. Mijn stelling daarbij is dat elk vak eens voor een tribunaal moet verschijnen, om afgerekend te worden, zo houd ik de cursisten voor. Zo moeten natuurkundigen zich over kernstraling verantwoorden. Chemici over kunststoffen. Enzovoort. Ook het niet-afbreekbare afval, of wat schadelijk lang invloed op het milieu uitoefent, laat zich niet meer zo eenvoudig onder het vloerkleed schuiven.
Omdat liegen voor dat tribunaal uitgesloten is, zullen vele mensen moeten toegeven dat zij altijd al wisten over nadelige effecten. Zij wensten echter, toen zij nders hadden kunnen handelen, de andere kant op te kijken. Wat zij natuurlijk ter verdediging voor het tribunaal kunnen aanvoeren, is dat bepaalde normen zich ontwikkeld hebben. Dit laatste stelt uiteraard een groot ethisch probleem omdat er een kern van waarheid inzit. Hoe kunnen we n iets doen of laten, maar met normen die zich pas in de toekomst uitkristalliseren? Dat lukt inderdaad ook niet zo best. Maar toch moeten we n het maximale ondernemen. Dat is dat iemand zijn vak beoefent in het volle besef van alle relevante aspecten, zoals die n bekend zijn, dus inclusief aspecten die hij eigenlijk zou willen negeren.

 

 

geen Don Quichotte

P: Vanwaar je engagement?

J: Wij kunnen niet doorgaan, zoals we doen. Dat tribunaal schets ik natuurlijk zo radicaal om cursisten rijp te maken voor ander inzicht. Zij moeten tenminste netjes met hun vak leren omgaan. Zij moeten werken volgens toetsbare criteria. Anders blijft informatievoorziening onbeheersbaar. En volgt, roep ik dan, onherroepelijk veroordeling door dat tribunaal. Sommige parlementaire enquetes leren overigens dat zo'n tribunaal helemaal zo fictief niet is.

P: Dus je bent geen als informatiekundig architect vermomde Don Quichotte?

J: Dat zou kloppen als ik helemaal geen invloed had. Dat is gelukkig anders. De meeste mensen weten heel goed wat wl en niet kan. Als zij architect willen zijn, moeten ze leren zich er daadwerkelijk naar te gedragen. Zij hebben immers een bijbehorende verantwoordelijkheid.

 

 

architectuur en cultuur

P: Je zegt dat criteria toetsbaar moeten zijn. Maar hoezo toetsbaar? Je vatte zojuist architectuur vooral kwalitatief samen. Wat valt er dan te meten?

J: Tussen architectuur en constructie bestaan talloze verschillen. Een wezenlijk verschil is dat er voor architectuur gn universele principes zijn. Daardoor is toetsbaarheid in het vlak van de architectuur inderdaad problematisch. Dat komt omdat architectuur per definitie bestaat uit keuzes op grond van omgevingsfactoren. Op het gebied dat voor de informatiekunde relevant is, gaat het dan om de cultuur van de organisatie. Zo is informatiekundige architectuur pas zinvol vanaf het moment dat cultuur als aspect van organisaties erkend is. Ik zie thans het besef doorbreken dat cultuur zelfs de dominante factor voor organiseren is. Daar komt de kans voor architectuur.
Over toetsbaarheid en architectuur heb ik een uitgesproken mening. Eigenlijk is architectuur niet te toetsen. Althans, dat lukt per definitie niet ls van een heersende cultuur. In een beplde cultuur geldt als criterium dan vooral zoiets als het gevoel van de gebruikers. Voelen zij zich, bijvoorbeeld, prettig met hun gereedschap?
Vanwege de afhankelijkheid van cultuur is kwaliteit van informatievoorziening altijd betrekkelijk. Wat in de ene cultuur prima functioneert, kan ergens anders falen. Dat zie je bijvoorbeeld met pakketten. Wat Amerikanen mooi vinden, slaat hier weleens niet aan.
Ik noem architectuur, wat kryptisch, soms de semantiek van de constructie. Daarin komt diezelfde gebondenheid binnen een cultuur tot uitdrukking. Het gaat immers om betekenis in het kader van een specieke omgeving.
Ook in de bouwkunde, bijvoorbeeld, zijn geen universele architectuurprincipes in de literatuur te vinden. Althans geen bruikbare. Daar staan dus voorbeelden van gebouwen die mensen in een bepaalde periode 'mooi' vonden. Dat zijn per definitie altijd keuzes met geldigheid binnen een bepaalde cultuur.
Wat we wl kunnen aangeven, is dat de cultuurgebonden architectuurprincipes altijd over ordening gaan. De architectuur biedt de voorwaarden, soms ook de regelgeving voor nadere uitwerking.

 

 

verschillende soorten principes

P: Ik begrijp dat je de architect en de constructeur als verschillende rollen poneert. Heb je daarmee tegelijk het verschil tussen de overeenkomstige soorten principes bepaalt?

J: Zo is het. Architectuurprincipes zijn als het ware de abstracte gereedschappen van de architect. Hetzelfde geldt voor de constructeur met diens principes.
Ik geef nog een voorbeeld uit de bouwwereld. Daar kennen we als instellingen onder andere de Welzijnscommissie en het Bouw- en Woningtoezicht. Je kan zeggen dat de Welzijnscommissie over het architectuuraspect gaat. Ofwel, hoe past de voorgestelde bebouwing in de omgeving? Dat is, zoals gezegd, vooral een nogal kwalitatieve orintatie. Daarom kan er ook zoveel verschil van inzicht over blijven. Bouw- en Woningtoezicht houdt zich daarentegen met constructie bezig. Dat gebeurt, precies, op grond van zo eenduidig en concreet mogelijke constructieprincipes. Die zijn wel universeel geldig. Zij zijn geldig ongeacht de ontwerpen ofwel de architectuur waarmee de Welzijnscommissie al dan niet instemt. Bouw- en Woningtoezicht hanteert een lijst van constructies die wl of juist niet zijn toegestaan.
Constructieprincipes zijn universeler omdat elk ontwerp via constructie in de concrete werkelijkheid gedaante krijgt. Iets werkt, punt. Of het werkt niet, ook punt. Het is daarmee duidelijk dat een constructieprincipe niet tegen natuurwetten kan indruisen zoals, alweer, de vergelijking met de bouwsector duidelijk maakt. Een ondeugdelijke brug stort in. Omdat cultuur zelfs per definitie enige afstand van natuur inhoudt, geldt voor architectuur niet die onmiddellijke confrontatie.
Over constructieprincipes vermeldt ik wel een nuance. Zoals architectuur geldigheid binnen een bepaalde cultuur heeft, stelt een bepaalde technologie grenzen aan constructies en daarmee eisen aan principes. De manier om hout te verwerken verschilt van de werkwijze met beton. Voor informatievoorziening kennen we op het ogenblik technolgien van de zgn. derde en vierde generatie. Naast universele(re) constructieprincipes zijn er principes die samenhangen met een beplde technologie. De lijst voor de derde ziet er anders uit dan de lijst met constructieprincipes voor de vierde generatie. Dat is op een bepaalde manier dus ook  relatief.
Via deze nunance blijkt meteen dat er wisselwerking tussen architectuur en constructie bestaat. Met de ene technologie zijn andere constructies mogelijk dan met een andere. Ook de architect krijgt daardoor de mogelijkheid en beperking van andere keuzes.

 

 

achteraf tegenover vooraf

Nog iets over het verschil tussen architectuur en constructie. Het is zo dat de menselijke reactie op een element van architectuur altijd eerst gevoelsmatig is. Alweer dat begrip schoonheid. De rationalisatie van onze ervaring leidt eventueel tot formulering van een architectuurprincipe. Dat is achterf. Het is daarbij voor elk volgend geval de vraag of dat principe opnieuw toegepast moet worden. Daarentegen bedoelt een constructieprincipe per definitie een norm te zijn. Een norm geldt al voorf en is van toepassing op alle constructies.      De som van constructieprincipes is nog geen architectuur. Dat komt, ik heb het al eerder gezegd, omdat architectuur pas telt in een specifieke omgeving. Architectuur schakelt natuur met cultuur.
De aard van betrokkenheid is voor architecten, respectievelijk aannemers echt totaal anders. Zij horen daarom ook niet in n organisatie thuis. Hun culturen zijn immers onverenigbaar.
Ondanks deze onverenigbaarheid van culturen ontwijken vele software houses een open keuze. Daardoor komen klanten met een architectuurprobleem vaak terecht bij een aannemer — want dat is een software house uiteindelijk toch — en zijn daar natuurlijk aan het verkeerde adres. Het resultaat laat zich raden. En kijk maar naar de bedroevende staat waarin informatievoorziening zich in vele organisaties bevindt. Het wordt tijd voor expliciete aandacht voor architectuur, k in de informatievoorziening.

 

 

zonder architectuur een crisis

Omdat het besef van het onderscheid tussen architectuur en constructie er niet is, hebben wij een crisis in de informatievoorziening. Dat is trouwens ook lastig te waarderen, dat onderscheid. Dat snapt een gebruiker niet. Een gebruiker wil gewoon dat ht werkt. Hij zal dus nooit zo'n boodschap hebben aan wat architectuur en wat constructie is.
Zij het weliswaar vaag geanalyseerd, maar inmiddels ervaart de klant annex gebruiker gelukkig al meer zijn problemen met gebrekkige informatievoorziening. Door die vaagheid ziet hij de oplossingsrichting helaas nog niet voldoende rationeel. Dat gaat echter komen. Wij zitten in een stadium waarin ook voor informatievoorziening duidelijkheid, niet zozeer over het onderscheid tussen architectuur en constructie, maar tenminste wl tussen architecten en aannemers groeit. Dat gaat nu behoorlijk snel.
Voor zijn informatievoorziening moet de klant eerst en vooral kiezen voor een bekwame architect. Dat is dus een keuze voor een rol die voor resultaat in informatievoorziening onontbeerlijk is. Inschakeling van een echte architect is de enige manier om de crisis in informatievoorziening te bestrijden.
Tot voor kort had de klant geen alternatief. Aannemers domineerden de markt. Er waren geen informatiekundige architecten. Hij, de klant, moest accepteren wat informatica-constructeurs (niet) leverden. Toen er geen keuzevrijheid was, was er evenmin architectuur. Dat verandert nu gelukkig.

 

 

pionieren met constructieprincipes

P: Ikzelf heb het gevoel dat we tot dusver wel degelijk voortdurend over informatievoorziening spreken, zij het soms nogal abstract en overdrachtelijk. Ik beschouw het als dat noodzakelijke verhaal, in elk geval een gedeelte ervan, om latere zgn. details te kunnen begrijpen. Zijn we inmiddels zover dat we het over die concrete principes kunnen hebben? Althans, een beetje? En dan stel ik voor dat je vanwege hun algemenere geldigheid in het bijzonder iets over je constructieprincipes zegt.

J: We zijn bijna zover. Als verdere inleiding beantwoord ik eerst nog de volgende vraag: Waar moeten we naartoe?
Met de constructie van middelen voor informatievoorziening, ofwel de informatica-constructie, moeten we naar de saaiheid van de oudere constructievakken. Saaiheid, dat zei ik. Neem werktuigbouw. Dat ingenieursvak heeft al een traditie. De constructieprincipes moeten er bij leerlingen, studenten en dergelijke ingestampt kunnen worden. Ook voor constructie met informatietechnologie moeten er vergelijkbaar respectabele leerboeken komen. En zo'n boek is dat pas wanneer, om maar wat te noemen, de zevenentwintigste, onlangs herziene druk verschenen is.
Zover is het met constructie met informatietechnologie nog lang niet. Waar bevinden wij ons nu? Wij bewegen ons primitief aan het begin. Aan het zoeken. Wij zijn nog pioniers wat de constructieleer van de informatietechnologie betreft. Vergeleken met de bouwkunde staan wij nog vr de romein Vitruvius die vele bouwkundige constructieprincipes codeerde.

P: Wat doe jij eraan?

J: Ik roep dat constructieprincipes voor informatievoorziening nodig zijn. Verder geef ik een aanzet door concreet enkele principes te formuleren. Bijvoorbeeld die scheiding van informatie en meta-informatie. Enkelvoudige vastlegging en opslag. Consistentie van taal. Reductie van complexiteit. Maximale onafhankelijkheid van delen. Standaardpatronen zonder afwijkingen. De 80/20-regel. Geen onzichtbare koppelingen. Al deze korte uitspraken zijn evenzovele van mijn constructieprincipes.

 

 

aannemers als obstakel

Een groot obstakel voor de ontwikkeling van constructieprincipes is tot dusver geweest dat proceskwaliteit in zgn. automatiseringsprojecten vrijwel alle nadruk kreeg. Dat is verklaarbaar vanuit het monopolie van de aannemers ofwel constructeurs. Pas wanneer de klant als alternatief een architect kan inschakelen, als intermediaire partij, kan het accent op het produkt of het resultaat komen te liggen. Dan zijn constructieprincipes ook expliciet nodig om de produktkwaliteit in termen van zijn constructie meetbaar en bespreekbaar te maken.

P: Zonder een aparte architect maken de constructeurs het zich dus gemakkelijk met een inspanningsverplichting. Dankzij de rolverdeling n constructieprincipes kunnen de klanten hun constructeurs meer tot een resultaatverplichting dwingen. Maar gaat de, zeg maar, vrije rol van het software house dan niet over op de architect?

J: Het conceptuele gat tussen de klant/opdrachtgever en de constructeur is te groot. De architect overbrugt die afstand. Hij beheerst beide talen in voldoende mate. Als zodanig heeft de architect een eigen verantwoordelijkheid. Over ethiek heb ik het verder al gehad.

P: Ik vroeg eigenlijk naar externe controle over de architect, niet naar diens noodzakelijke zelfcontrole. Wie garandeert dat de architect zich ethischer gedraagt dan de aannemer? Ik begrijp uit je antwoord dat we bij een bepaalde groep niet verder kunnen gaan dan redelijke zelfcontrole. Dat moeten dan de architecten maar zijn? Vroeg of laat verschijnen ze voor je tribunaal, heb je aangekondigd. Ontsnappen is dus niet mogelijk.

 

 

door met pionieren

J: Met dat vroege idee van het tribunaal is het toch begonnen, mijn ontwikkeling van constructieprincipes. Ik zocht en zoek naar operationele kwaliteitseisen. Die moeten echt toetsbaar zijn. Neem termen als flexibiliteit en onderhoudbaarheid. Dat blijft te vaag. Het gaat om de vraag: Welke constructies zijn toelaatbaar? Welke niet? Precies zoals in de bouw.
Concreet kan ik inderdaad slechts voor constructeurs zijn. Meetbare principes zijn er uitsluitend voor constructie. Voor architectuur ontbreekt de mogelijkheid tot normering vraf. Dat zou zelfs averechts werken. Met louter constructie komt cultuur tot stilstand. Zeker met informatievoorziening is dat nu het laatste dat we willen. Er valt nog zoveel te verbeteren en verder te ontwikkelen.
Overigens waren andere mensen al eerder met constructieprincipes voor informatietechnologie bezig. Het bekendst, trouwens ook in de Verenigde Staten, is stellig de nederlander Dijkstra die in 1968 het artikel met de titel 'Go To Statement Considerd Harmful' publiceerde. Dat heeft echt enorme indruk gemaakt. En er wordt nog altijd op teruggegrepen. Zeer invloedrijk. Er is over programma's, over wat een goed computerprogramma is, dus al veel nagedacht. Parnas was er ook vroeg bij met zijn artikel 'On the Criteria To Be Used in Decomposing Systems Into Modules' uit 1972. Hij schreef in dat kader over de eigen verantwoordelijkheid van een aparte module.

P: Frappant dat je Parnas noemt. In hun boek Object-Oriented Analysis (tweede druk, 1991, p 14) voeren Coad en Yourdon het principe van de inkapseling direct terug op het werk van Parnas. Overigens, dat over inkapseling is dus een constructieprincipe.

 

 

reikwijdte van constructieprincipes

J: Parnas maakte qua beschouwingsniveau de stap van afzonderlijk programma naar totaal systeem. Daar slaat die decompositie tot afzonderlijke modulen op. Zo kunnen we eventueel  nog ruimere beschouwingsniveaus hanteren. Voor elk niveau gelden dan kenmerkende constructieprincipes. Zulke principes voor een apart programma verschillen immers van de principes voor constructie van een totaal informatiesysteem.

P: Dan stel ik n systeem als volgend beschouwingsniveau de zgn. infrastructuur voor informatievoorziening voor.

J: Dat kan. Altijd, op elk niveau gezien, zijn er bouwstenen. Zowel de aparte bouwstenen, als hun samenhang moeten daar een verantwoorde constructie kennen.

 

 

eigen pogingen

P: Kan je doorgaan met het verhaal hoe jijzelf met constructieprincipes begon?

J: Er bleek dus al een traditie van constructieprincipes te zijn. Ik probeerde erop voort te borduren. Dat was aanvankelijk niet zo succesvol. Wat ik destijds als principes voor constructie formuleerde, bleken helemaal geen constructieprincipes te zijn.

P: Heb je een voorbeeld van zo'n mislukking?

J: Niet meer zo concreet. Maar ik zocht het toen nog onder begrippen zoals flexibiliteit en onderhoudbaarheid. Ik kwam er vervolgens achter dat je daar operationeel niets mee kan. Is en blijft te vaag. Er is niets door meetbaar en dus toetsbaar. Het leidt niet tot de criteria die operationeel handen en voeten hebben.

P: Hoe bedacht je ze vervolgens, je constructieprincipes?

J: Zij zijn nu het resultaat van een mengsel van benaderingen. Ik kijk bijvoorbeeld naar wat een ervaren constructeur eigenlijk als vanzelfsprekend al doet. Dat is onderzoek in positieve zin. De negatieve benadering bestaat uit onderzoek naar fouten en problemen uit het verleden. Er is helaas genoeg materiaal. Aardig, en dat vind ik weer positief, werkt het ook om je als mentor van een nieuwe medewerker te beschouwen. Wat wil je hem leren? Hoe beoordeel je zijn resultaten? Wat zijn je criteria? Nog een benadering is het om van de vage begrippen uit te gaan, dus toch van flexibiliteit, betrouwbaarheid en dergelijke. De vraag is dan of er concretere verschijningsvormen van bestaan die vertaalbaar zijn naar operationeel meetbare principes.
Zo kom je op allemaal losse problemen. Daarvoor probeer ik losse oplossingen te verzinnen. En langzaam krijg je vervolgens het gevoel dat er iets chter zit. Dat sommige oplossingen iets gemeenschappelijks hebben. Via zulke verdichting kom ik tot universeler inzicht, tot de zogenaamde principes.
Dat proces van ordening, herordening, verdichting enzovoort gaat overigens steeds door. Ik stuit op nieuwe feiten, nieuwe problemen. Nieuwe inspiratie. Passen hun oplossingen in de huidige verzameling constructieprincipes? Ligt hergroepering meer voor de hand? Is het nodig een principe toe te voegen? Zo gaat dat.
Verder is het onvermijdelijk dat de principes elkaar gedeeltelijk overlappen. Het gaat immers steeds over constructie. Waarin principes van elkaar verschillen, is dan het accent op een bepld aspect van constructie.

P: Je bent nu bij acht. Wat is jouw negende constructieprincipe, als je die nu meteen moet formuleren?

J: Daar heb ik meteen een antwoord op want ik ben er al een tijdje mee bezig. Dat principe luidt: Ongekeurde materialen mogen niet in produkten opgenomen mogen worden.
Deze aanwijzing is uit de logistiek afkomstig. Een implicatie is onder andere dat invoer ten opzichte van een domein getoetst moet worden.

 

 

nog steeds nummer n

Toen ik met de nummering begon, luidde mijn eerste principe: Reduceer complexiteit van de constructie! Dat principe heb ik tot dusver op de eerste plaats gehouden. En ik verwacht dat dat zo blijft. Er hoort natuurlijk uitleg bij.

P: Dat is de lezer wel duidelijk. Hopelijk heeft hij het nodige geduld opgebracht.

J: Ik bedoel met dit eerste principe dat de constructie moet bestaan uit losgekoppelde elementen met daartussen uitsluitend lineaire (sequencies van) interactie.

P: Ik vermoed dat de lezer, als hij tenminste geen vakman is, ondanks jouw uitleg nog steeds naar de toepassing van dat constructieprincipe moet raden. Ik concludeer daarom tussendoor dat dit verslag eigenlijk slechts geldt als aansporing om het informatiekundig vak degelijk te leren. Alles hier uitleggen gaat immers niet. Anders komen we nergens meer concreet aan toe. Goed, en bijvoorbeeld constructieprincipe nummer twee?

J: Daarvoor heb ik de volgorde van de principes wel veranderd. Daar staat nu: Onzichtbare koppelingen zijn verboden! In termen van objecttechnologie heet dat inkapseling en information hiding.

 

 

aanpasbaarheid

Niet alleen hun onderlinge rangschikking, maar ook het kader waarin ik de constructieprincipes plaats, verandert trouwens. Vijftien, tien jaar geleden nog lag het accent op de efficiency van de programmatuurontwikkeling. Nu staat de aanpasbaarheid centraal. En dat inmiddels gezien op ruimere schaal dan van de afzonderlijke programma's. Het gaat om gehele systemen, inderdaad steeds meer om infrastructuur. Dat is natuurlijk weer zo'n inzicht dat past bij de informatiekundig architect. Het gaat niet om een computerprogramma op zichzlf, maar om de omgeving waarin dat programma optimaal moet passen. En blijven passen. Met snelle veranderingen van de omgeving wint aanpasbaarheid aan betekenis.
Mijn tweede constructieprincipe, dat van het verbod op onzichtbare koppelingen, wijst op de noodzaak van een revolutie. Want vrijwel alle huidige constructies in de informatievoorziening voldoen er niet aan. Het barst van de onzichtbare koppelingen, met alle gevaren van dien. Denk maar aan een verborgen waterleiding. Wie een schilderij wil ophangen en daarvoor een gat in de muur boort, kan voor een onaangename verrassing komen te staan. Vanwege dergelijke risico's moet bijna alles wat voor informatievoorziening geconstrueerd is, weggegooid worden. Alles moet overnieuw. Nu begrijpen nog onvoldoende gebruikers dat. Maar als gevolg van versnelde veroudering van programmatuur verwacht ik dat binnen korte tijd die grote vraag naar vervanging losbreekt. Ik zei al, een revolutie.

 

 

niet het etiket, maar de stroming

P: Is dat d kans voor objecttechnologie?

J: Ik vind het vooral een kans voor degelijke constructieprincipes. Dit roept overigens wel de vraag op wat objecttechnologie eigenlijk is. Ik meen dat objecttechnologie vooral het meest recente etiket voor een stroming is die allang bestaat en voortgaat. Zonder objecttechnologie is die stroming er heus ook. En gaat verder. Er staat dan gewoon een ndere naam op het etiket. Neem nu die constructieprincipes. Vele mensen dachten al dat er veel mis was. En is. Ook vele mensen denken al in dezelfde richting voor oplossingen. Daar heb ik het over gehad. Dijkstra, Parnas enzovoort. Onder de noemer objecttechnologie kan de laatste lichting onderzoekers dat nu ook hardop zeggen, en proberen hun gelijk te krijgen.
Mijn idee is dat de nadruk moet liggen op algemeen toepasbare constructieprincipes. Als objecttechnologie op dit moment de geschiktste naam voor die stroming is, is dat mij best. Zo'n noemer kan helpen. Is steuntje in de rug, een beetje wind mee. Wie weet? Maar meer dan handige legitimatie van de onderliggende, continue stroming zie ik er niet in.
Waar ik me zelfs tegen afzet, is de indruk dat met objecttechnologie niets meer mis kan gaan. Maar kijk naar mijn tweede constructieprincipe. Daarmee staat objecttechnologie met hergebruik via overerving op gespannen voet. Want wat is zulke overerving nders dan een onzichtbare koppeling?

P: Dus gn kans voor objecttechnologie?

J: Deze technologie heeft zeker iets toe te voegen en als zodanig kan het enige tijd het gezicht van de onderliggende stroming bepalen. Als nuttig, zelfs noodzakelijk accent beschouw ik het principe van de inkapseling. Maar zelfs dat is overigens niet nieuw en uniek voor objecttechnologie, zoals we eerder bespraken. Het extra accent is echter bijzonder welkom. Dat is dus prima aan objecttechnologie. Maar zoals het zo vaak gaat met een goede bijdrage, nemen commercile kringen het initiatief over. Specialisten van marketing gaan de bijbehorende kreet gebruiken om de verkoop van wat ze eigenlijk aan produkten en diensten al hadden te stimuleren. Dat draagt niet verder bij aan dat noodzakelijke accent. Laat staan dat er iets echt nieuws gebeurt. Vaak maken verkopers het met hun valse aanprijzingen zo bont dat je als integere architect dat woord, en nu is dat objecttechnologie, bijna niet meer durft te gebruiken. Dat heb is dus al met client/server. Dat begrip is al stkgeadverteerd.

 

 

operationeel, dus meetbaar en toetsbaar

Ongeacht de noemer, dus objecttechnologie of iets anders, moet de ontwikkeling van meetbare, toetsbare constructieprincipes doorgaan. Anders hebben we nog niets en komt objecttechnologie op hetzelfde kerkhof terecht.
Met of zonder objecttechnologie heeft informatievoorziening volgens universele constructieprincipes de toekomst. En dat zal hard gaan, en wel via opleidingen. Er komt een nieuwe generatie architecten en constructeurs die niet beter weet dan dat het volgens die degelijke, zelfs saaie principes moet. Zij nemen niet de tijd om de huidige puinhoop te begrijpen.
Met onderhoud is het snel afgelopen. Daar piekeren ze niet over! Dus nieuw! Dat heeft niet zozeer met gebrek aan geduld te maken, als met noodzaak voor kwaliteit. Als obstakel voor revolutie geldt wellicht dat er niet tijdig gereedschappen zijn om volgens die constructieprincipes te werken. In het vlak van gereedschappen ligt heel concreet een kans voor objecttechnologie. Dat moet dan wel kloppen.

 

 

architect znder methoden

P: Na constructeurs wil ik tenslotte nog iets over architecten horen. Als er al architectuurprincipes zijn, zijn die van een andere orde dan de constructieprincipes. Het heeft ook geen zin over methoden voor informatiekundige architecten te spreken, nietwaar?

J: In 1982 publiceerde ik in het tijdschrift Informatie het artikel 'De Methode Doet Het Niet.' Mijn stelling was dat niet de methode ontwerpt, natuurlijk niet, maar dat de ontwerper dat doet. Nooit is een methode een klakkeloze checklist voor de architect.
Er is helaas geen vak dat zich zo druk maakt over methoden als de informatica. Dat heeft natuurlijk met die nadruk op proceskwaliteit i.p.v. produktkwaliteit te maken. Die val moeten informatiekundige architecten vermijden. Als motto beveel ik aan: De methode doet het nog steeds niet.

 

 

1. Kortheidshalve zijn in dit interview slechts mannelijke voornaamwoorden gebruikt. Waar het in algemene zin past, zijn echter nadrukkelijk zowel mannen, als vrouwen bedoeld.

 

 

1994, webeditie 2002.
Eerder verschenen in in: OT Magazine, jaargang 1, 1994, nr 5, 1994 en De Informatie-architect (Kluwer Bedrijfswetenschappen, 1995).