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 náást 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.
P: Kunnen we concreet met principes beginnen? Wat vind je zèlf 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 nòg 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 oriëntatie, 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 oriënteer 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 oriëntatie, is dat
verhaal nodig dat de noodzakelijke context verschaft.
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 vàk?
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.
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. Eén
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 máákt 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.
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 lòs 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.
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 vàk, 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.
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 wèl en niet kan. Als zij architect willen zijn, moeten ze leren zich er daadwerkelijk naar te gedragen. Zij hebben immers een bijbehorende verantwoordelijkheid.
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
géén 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 lòs van een
heersende cultuur. In een bepáálde 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 wèl kunnen aangeven, is dat de cultuurgebonden architectuurprincipes
altijd over ordening gaan. De architectuur biedt de voorwaarden, soms ook de
regelgeving voor nadere uitwerking.
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 oriëntatie. 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 wèl 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 technolgieën van de zgn. derde en vierde generatie. Naast
universele(re) constructieprincipes zijn er principes die samenhangen met een
bepáálde 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.
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 achteràf. 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 vooràf 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.
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 hèt
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 wèl 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.
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 vóór 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.
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.
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 vóóraf. 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.
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.
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 bepááld 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.
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.
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 zichzèlf,
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.
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 géén 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 commerciële 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 stùkgeadverteerd.
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.
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).