andere rol, andere methode
Jaap van Rees en Pieter Wisse
De discussie over methoden is niet zinvol zolang partijen deelnemen die volledig verschillende opvattingen hebben over de aard van taken, zeg ook maar over de diverse rollen, die in het totale ontwikkelproces spelen. Voor alle duidelijkheid kan het onderscheid tussen architecten en aannemers dienen als fundamenteel uitgangspunt. Wie dit onderscheid niet begrijpt, drukt zich bijvoorbeeld — zoals ook uit talloze publicaties nog telkens blijkt — negatief uit over andere deelnemers. Indien beroepsbeoefenaren hun rol en taken als die van informatiearchitect òf systeemaannemer begrijpen, ligt daarentegen wederzijds respect voor de hand. Samenwerking is nodig om informatievoorziening op het noodzakelijk hogere peil te krijgen.
Er is een grote overeenkomst tussen methoden voor systeemontwikkeling en voetbalclubs. Hoe wordt iemand een fanatieke aanhanger van juist dat ene team? Objectief gezien heeft dat meestal niets te maken met de kwaliteit van het spel. Waarschijnlijk groeide de persoon in kwestie in de buurt op, waren zijn oudere broers en/of vriendjes al fan, was zijn fidele oom het rolmodel, zoekt hij een uitweg voor zijn maatschappelijke frustratie enzovoort. Opvallend is verder dat eenmaal gevormde loyaliteit een levenslange aandoening blijkt. Supporters wisselen immers zelden van club. Of ze eigenlijk van de voetbalsport in het algemeen houden is daarbij vaak de vraag. Duidelijk is dat hun waarnemingen worden gekleurd door de loyaliteit met hun club; bij dezelfde aktie op het veld zien supporters van verschillende partijen soms het tegenovergestelde gebeuren.
De band van clubfans verschilt naar onze mening inderdaad bijna niets van de intieme verhouding die vele informatici met hun favoriete methode onderhouden. De misvatting is in elk geval precies dezelfde. Zoals de ene club ten onrechte met de totale voetbalsport vereenzelvigd wordt — "Wat de tegenpartij doet, is geen voetbal!" — vertegenwoordigt de eigen methode in de ogen van adepten meteen alles wat met informatievoorziening samenhangt. Nogmaals, dat is natuurlijk onzin.
Die sektarische inslag moet verdwijnen. Het is geen goede basis voor een vak. Daarom weigeren wij ons als supporters van de zoveelste methode te gedragen, ook al is dit hoofdstuk oorspronkelijk geschreven als artikel in een reeks over methoden voor systeemontwikkeling. Onze benadering is daarentegen fundamenteler. Uitgangspunt is dat realisatie van adequate informatievoorziening in complexe organisaties een grote diversiteit aan inzet vergt. Gelet op de complexiteit kan één soort specialisme onmogelijk alles voor haar rekening nemen. Laat staan dat er een universele methode bestaat. Er is behoefte aan allerlei specialisten. Zij gebruiken voor onderdelen van hun werk, naar omstandigheden, allerlei methoden. Daarbij bestaat wezenlijk onderscheid tussen de methoden van betrokken specialisten.
Onze insteek is dat complexiteit vooral om diverse rollen vraagt. Dit hoofdstuk is eerst en vooral een pleidooi om minimaal onderscheid te maken tussen enerzijds informatiearchitecten en anderzijds systeemaannemers. Met daarnaast uiteraard de opdrachtgever, die zijn primaire rol behoudt. Informatiearchitect en systeemaannemer leveren elk karakteristieke bijdragen aan de realisatie, dat wil zeggen aan het totale ontwikkelproces. Hier schetsen wij waarin zij wezenlijk van elkaar verschillen. En waarom zij dus ook behoefte hebben aan hun eigen, karakteristieke methoden.
In onze opvatting zijn de meeste informatici op dit moment voornamelijk systeemaannemers. Daarom pleiten wij vooral voor erkenning van de aparte rol van de informatiearchitect bij de realisatie van organisatorische informatievoorziening. Een goede informatiearchitect is onmisbaar voor het ontwerpaspect van dit proces, waarin beeldvorming door alle betrokkenen een belangrijke rol speelt. Natuurlijk is een goede systeemaannemer evenzo onmisbaar, maar dat is hij in het bijzonder voor het bouwaspect.
Waarom paste dit hoofdstuk eerder als tijdschriftartikel toch in een reeks over methoden voor systeemontwikkeling? Dat heeft allereerst te maken met onze opvatting over het verschijnsel dat wordt aangeduid met de term methode. Wij ontkennen absolute pretenties voor welke methode danook, zoals wij in de eerste paragraaf al duidelijk gemaakt hebben. Maar relativering van het belang van methoden blijft ... een verhaal over methoden, misschien zelfs wel fundamenteler dan uitleg van één of andere methode in het bijzonder. Als zodanig sluit deze tekst aan op de bijdrage die één der auteurs leverde aan de eerdere artikelenreeks in Informatie die begin jaren tachtig verscheen (Van Rees, 'De Methode Doet Het Niet').
Behalve het onderwerp methode vormt systeemontwikkeling een geldige aanleiding. Immers, wij kunnen voor uitleg over het onderscheid tussen informatiearchitecten en systeemaannemers uitstekend met dat begrip systeemontwikkeling beginnen. Want sommige problemen die nu door opdrachtgevers en gebruikers worden gesignaleerd met betrekking tot de kwaliteit van informatievoorziening, worden veroorzaakt doordat de thans nog gangbare betekenis van dat begrip is verouderd. Er is overigens niets mis mee om de term systeemontwikkeling te handhaven, maar dan moet de betekenis ervan natuurlijk wel met zijn tijd mee. Wat systeemontwikkeling tegenwoordig betekent moet dus sporen met de complexiteit van organisaties, waarin de informatievoorziening integraal functioneert. Inderdaad is het in vele organisaties zover nog (lang) niet. Met een aparte informatiearchitect lukt het beter.
Wij vinden dus, gezien de problemen die zich in de praktijk voordoen, dat het nu het moment is aangebroken om ook voor informatievoorziening onderscheid te gaan maken tussen architecten en aannemers. Kortom, tussen informatiearchitecten en systeemaannemers. Te vaak komen opdrachtgevers, die zelf nog geen goed beeld hebben van het systeem dat zij willen laten maken, terecht bij systeemaannemers, die in hun denken en in hun aanpak ervan uitgaan dat de klant precies weet wat hij wil.
Dat de, zeg maar, antieke betekenis van systeemontwikkeling inmiddels simplistisch is, blijkt uit een historisch overzicht. Wij vatten als volgt samen. Computers werden reeds vroeg in hun geschiedenis zgn general purpose machines. Voor het specifieke gedrag dat zo'n machine moet vertonen, zorgt een programma. Dat moest op maat worden gemaakt. Zo werd systeemontwikkeling synoniem met voortbrenging van specifieke computerprogrammatuur.
De vroegste programmeurs waren vooral wetenschappelijke onderzoekers. Meteorologen, sterrenkundigen en dergelijke kenden hun eigen informatiebehoeften natuurlijk door en door. Omdat zij ook zelf programmeerden was communicatie over specificaties nog geen probleem.
De hulpmiddelen werden steeds complexer. Daardoor was er steeds meer kennis nodig om er iets 'uit' te halen. Daarnaast werden andere toepassingsgebieden ontgonnen, zoals administraties. Hierdoor ontstond de behoefte aan arbeidsdeling. Er kwamen specialisten voor de automatisering, die het ontwikkelen van maatwerkprogrammatuur op zich namen. In het denken over systeemontwikkeling staat dit eigenlijk nog altijd centraal. Een programma op maat wordt dus helaas nog overal als het echte resultaat van ontwikkeling beschouwd. Met andere woorden, als 'het' systeem. Natuurlijk hebben andere verschijnselen aandacht gekregen. Zelfs gebruikers krijgen door automatiseerders weleens een rol toegedicht. Tot een herorientatie van wat systeemontwikkeling moet zijn, heeft dat echter te weinig geleid. Waar traditionele automatiseerders werken, krijgen personele, organisatorische verschijnselen enzovoort nooit meer dan de status van aanvullend aspect. Het is en blijft voor automatiseerders, alle mooie beloften van zulke systeemaannemers ten spijt, maar een — lastige — randvoorwaarde om programmatuur aan de praat te krijgen. Omdat het daarbij blijft, is er geen sprake van een integrale benadering, waarin alle relevante aspecten naar omstandigheden meetellen. Het blijft zoals gezegd lippendienst. Een mooi voorbeeld nu is business process redesign/re-engineering. Zolang dat legitimatie moet verschaffen voor ontwikkeling van alweer nieuwe programmatuur, kan dat nooit iets worden. Pas wanneer het bedrijfsproces ipv computerprogrammatuur centraal staat in ontwikkeling, zijn er resultaten te verwachten en dat is precies waarom een goede informatiearchitect onmisbaar is. De informatiearchitect kijkt naar een organisatie als geheel en naar processen die daarbij een rol spelen. Hij kijkt er natuurlijk naar in relatie tot de mogelijkheden van de informatietechnologie, maar blijft nadrukkelijk met organisatorisch perspectief kijken. Dat kan een systeemaannemer niet. De systeemaannemer moet zo goed mogelijk programmatuur blijven bouwen, maar binnen het kader dat de informatiearchitect aangeeft (zoals hij dat in samenspraak met de opdrachtgever heeft ontworpen).
Het is al met al veel te beperkt om een systeem, dat wil zeggen als onderwerp van systeemontwikkeling, synoniem met maatprogrammatuur te houden. Die tijd is allang voorbij. Inmiddels is een veel ruimere betekenis relevant voor wat 'het' systeem is. Dat is bijvoorbeeld de organisatie, vandaar de noemer organisatieontwikkeling. Procesontwikkeling zou ook kunnen, maar door marketing is de term proces daarvoor misschien al te besmet geraakt. Aardig is dat in de russische taal het woord complex wordt gebruikt, waar wij het woord systeem gebruiken. Zo spreken wij in het nederlands weer wel van een gebouwencomplex.
Onverbrekelijk verbonden met architectuur is het begrip cultuur. Het gebruik van het begrip architectuur zonder de context van cultuur blijkt meestal te berusten op een misplaatste verwarring met wat constructie betekent. Steeds duidelijker wordt het in ieder geval voor informatiearchitecten dat veranderingen in informatievoorziening tot en met in een culturele context thuishoren. Wie niet voor verrassingen wil komen te staan, kan daarom maar beter die allerruimste context hanteren. Het begrip systeem is immers ingevoerd om samenhang te benadrukken. Relevante samenhang over het hoofd zien is een oerzonde in het systeemdenken. En het is inmiddels duidelijk dat informatieverwerking en organisatiecultuur onverbrekelijk met elkaar samenhangen. In de praktijk blijkt dit doordat een systeem dat voor de ene organisatie is ontworpen in een andere organisatie, die bijvoorbeeld wèl dezelfde formele structuur heeft, doorgaans niet wordt geaccepteerd. Maar ook in de theorie blijken cultuur en informatieverwerking verrassend dicht op elkaar aan te sluiten. Wat is cultuur volgens de theorie van de sociologen? Twee mensen horen tot dezelfde cultuur als zij overeenkomstige interpretatieschema's hanteren. Als zij de werkelijkheid op dezelfde manier waarnemen en waarderen. De theorie van informatieverwerking zegt in feite hetzelfde op een andere manier: Gemeenschappelijke informatieverwerking is alleen mogelijk indien de betrokken personen en systemen hetzelfde entiteitenmodel (lees ook: taalmodel, lees ook: interpretatieschema) hanteren. Het ontwerpen van een systeem begint danook in veel methoden met het opstellen van dit interpretatieschema. Met andere woorden, de cultuur wordt in het systeem ingebakken.
Van programmatuur naar cultuur is nogal een omvangrijke verschuiving voor de betekenis van het begrip systeem, dat beseffen wij terdege. Maar dat is beslist noodzakelijk. Want deze verandering weerspiegelt precies waarom realisatie van informatievoorziening inmiddels niet meer zonder een aparte informatiearchitect kan lukken. Nieuwe informatievoorziening moet immers in de heersende cultuur passen of zelfs bijdragen aan cultuurveràndering. Dat vraagt van de informatiearchitect dat hij gespecialiseerd is in het waarnemen van cultuur. Daarbij gaat het niet alleen om de beeldvorming bij de informatiearchitect. Hij moet overeenkomstige beeldvorming bij opdrachtgever en overige betrokkenen stimuleren opdat een draagvlak voor veranderingen ontstaat. Tot de overige betrokkenen behoren natuurlijk ook systeemaannemers. Wij zeggen dit er maar even duidelijk bij. Als specialist in waarnemen, beeldvormen en dergelijke moet de informatiearchitect over gerichte methoden daarvoor beschikken.
Het verband tussen cultuur en architectuur kan ook in evolutionaire termen verklaard worden. Dit onderstreept nogmaals de potentiële reikwijdte van de bemoeienis van de informatiearchitect. Daarom opnieuw een korte samenvatting, ditmaal van wat hoe wij evolutie zien.
De evolutieleer à la Darwin stelt dat mutaties in geïsoleerde populaties zorgen voor snelle verspreiding van voordelige eigenschappen. Er bestaat echter geen a priori ontwerp voor toekomstige generaties en de individuen, die er deel van uitmaken.
Uitgaande van deze opvatting over evolutie geldt vervolgens dat cultuur bestaat zodra de levensvorm niet uitsluitend genetisch bepaald is. Dat veronderstelt communicatie tussen leden van generaties. Maar het cultuurgoed kan nog evenzogoed louter evolutionair ontstaan, dat wil zeggen zonder a priori ontwerp. Vanaf het moment dat een visie op een resultaat, beeldvorming dus, voorafgaat aan de handeling waarmee dat resultaat nagestreefd wordt, is er sprake van ontwerp. De handeling is als het ware het experiment waarmee iemand zijn gedachte uitvoert. Omgekeerd is de gedachte de simulatie van de handeling inclusief het effect ervan.
Met ontwerp ofwel architectuur geven wij de kenmerkende afwijking aan die systeemontwikkeling (lees dus vooral ook: organisatie‑ of cultuurontwikkeling) onderscheidt van louter evolutionaire ontwikkeling, dit laatste nota bene in de darwinistische betekenis die wij eraan toekennen.
Voor de informatiearchitect is het overigens een complicatie dat hij niet alleen als regisseur van een proces van gezamenlijke beeldvorming optreedt, maar tegelijkertijd als acteur in een belangrijke rol mééspeelt. Het is duidelijk dat zo'n dubbelrol om aangepaste methoden vraagt, dat wil zeggen om typische architectenmethoden.
Tot op grote hoogte gedraagt iedereen zich als architect. Want ieder mens ontwerpt voortdurend. Iemand neemt zich iets voor, simuleert dus vóórdat hij extern handelt. Voor een specifiek ontwerp is het overigens niet noodzakelijk dat er daadwerkelijk een handeling volgt. Maar in het algemeen is ontwerpen als subjectieve activiteit natuurlijk wel gericht op effectuering van gedrag.
Door zijn voortdurende ontwerpbezigheid is een mens zich er doorgaans niet van bewust dàt hij ontwerpt en dus in zekere zin architect is. In alledaagse situaties zijn de ontwerpaktiviteiten en de handelingen die daaruit volgen adequaat verenigd. Echter, wanneer een situatie voor hem onbekend is, is dat gauw anders. Zoals wij hier wat slordig, maar voor deze discussie afdoende, definiëren, valt onbekendheid vergaand samen met complexiteit. Zoals Herbert Simon in Psychologie en systeemtheorie al betoogde, noemen wij iets complex zodra we de structuur niet doorgronden. Verruiming van systeem tot cultuur maakt vaak de complexiteit manifest. Iemand is dan niet altijd zelf tot relevant ontwerp in staat. Zoals de vis de laatste zal zijn om het water te ontdekken, zo is een betrokkene in een cultuur vaak niet in staat om de relevante cultuurelementen te identificeren. Indien de behoefte tot daadwerkelijk handelen aanhoudt, wordt er iemand anders bijgehaald. Dat is dan de ontwerper of architect.
Tussendoor vermelden wij dat de titel architect inmiddels wettelijk is beschermd. Er is conform een Europese richtlijn ook in Nederland een Stichting Beheer Architectenregister. Wie de titel in het maatschappelijk verkeer voert, of dat nu de titel tuinarchitect, informatiearchitect of wat voor architect danook is, moet daar geregistreerd staan. En voor opname in dat register gelden op hun beurt formele eisen. Over die beschermingsmaatregel maken wij verderop nog enkele opmerkingen. Onze hoofdstelling is echter dat onderscheid tussen informatiearchitect en systeemaannemer nodig is.
Algemeen gesteld is een architect iemand die is gespecialiseerd in gedachten & communicatie over eventueel naderhand te realiseren handelingseffecten. Daarom is beeldvorming voor de architect van wezenlijk belang. Hij vormt een beeld van een toekomst. Omdat opdrachtgever en overige betrokkenen een keuze moeten bepalen, moet de architect proberen zijn beeldvorming met hun te delen. Daarbij blijft het niet bij dat ene beeld, zeg maar het ontwerp als een plaatje van hoe 'het' eruit moet gaan zien. Voor een hoog realiteitsgehalte van dat toekomstbeeld zijn tevens reële beelden van verleden, heden en veranderingsproces onontbeerlijk. De architect ziet, ontwerpt en communiceert, als het goed is, dus veel méér dan dat ene toekomstbeeld. Het uiteindelijke resultaat is het produkt van een gezamenlijke inspanning dat afhankelijk is van de betrokken personen; dezelfde opdrachtgever komt met een andere architect ongetwijfeld tot een ander ontwerp. Het omgekeerde is overigens netzo waar. Dezelfde architect komt met een andere opdrachtgever ook tot een ander resultaat, ook al wordt in beide gevallen gestart met hetzelfde programma van eisen. De rationeel denkende automatiseerder, een echte systeemaannemer dus, vindt dit niet leuk. Het betekent immers dat het hoofd van de ontwerpafdeling tegen de klant iets in de trant moet zeggen van "De oplossing van uw probleem is in belangrijke mate afhankelijk van de persoonlijke voorkeur van de ontwerper, die ik voor u beschikbaar stel." Veel investeringen in methoden zijn vermoedelijk, neen, vrijwel zeker geworteld in de behoefte van het management van automatiseringsafdelingen om dit probleem te ontduiken. Zij wensen dat de oplossing onafhankelijk is van het individu dat het werk oppakt. Hier is de wens de vader van de mislukking.
Introductie van het architectuurbegrip maakt voor opdrachtgevers eindelijk duidelijk dat een eenduidige relatie tussen enerzijds probleem, anderzijds oplossing onmogelijk is. Ook dit is een belangrijk argument om de titel van informatiearchitect te introduceren. Zoals in de bouwwereld wordt een opdrachtgever zich daardoor eerder bewust van de persoonlijke voorkeur van de architect en dat zal in het selectieproces een doorslaggevende rol spelen.
Voor de aannemer geldt dit natuurlijk niet. In principe mag het eindresultaat van het bouwproces niet afhankelijk zijn van de gekozen aannemer.
In het voorafgaande hebben wij de rol van een aparte informatiearchitect een logische plaats in veranderingsprocessen onder steeds complexere omstandigheden gegeven. Dat heeft alles met cultuur als dominante factor te maken. Maar wat valt concreter over de specifieke bijdragen van een informatiearchitect te zeggen? Wat is de toegevoegde waarde die hij levert?
Allereerst is het nuttig om te weten wanneer iets een vak mag heten. Welnu, een vak, dat heeft altijd te maken met een eigen, typische manier van kijken. Dat is een manier die ànders is, die afwijkt van de zienswijze volgens andere vakken. Met andere woorden, elk vak heeft een zogenaamd paradigma. Wij noemen dat populair ook wel een bril.
In dit kader is het nuttig om verschil te maken tussen enerzijds een informaticus, anderzijds een informatiekundige. De informatiekundige kijkt en ziet een organisatie als een informatieverwerkend systeem. Daarop is zijn beeldvorming karakteristiek gericht. Daarbij is voor hem informatieverwerking ruimer dan wat er geautomatiseerd gebeurt. Hij kijkt naar alle relevante informatie, dus ook naar wat mensen ermee doen. De informatiekundige oriënteert zich op het totale proces tot en met de cultuur. Zo'n manier van kijken, en als gevolg daarvan het resultaat, verschilt van wat de meeste andere mensen zien. De bril functioneert pas optimaal na lange opleiding en ervaring. Daarom is informatiekunde een apart vak.
Informatiekunde is gelet op de karakteristieke oriëntatie beslist geen informatica. Ook de informaticus ziet wat vele andere mensen normaal niet zien. Hij ziet echter iets anders dan de informatiekundige. De informaticus heeft informatieverwerkende hulpmiddelen en het efficiënte gebruik daarvan centraal in zijn paradigma. De informaticus bemoeit zich onder de noemer van zijn eigen vak dus niet bewust met de cultuur van organisaties.
Natuurlijk hebben informatica en informatiekunde vanalles met elkaar te maken. Het laatste, informatiekunde dus, ontstond als apart vak vooral uit het eerste. Pas toen informatietechnologie op een bepaalde schaal toegepast werd, brak behoefte aan en besef van een ruimere zienswijze door. Vergelijk dat met verkeerskunde. Dat is in precies dezelfde volgorde voortgekomen uit onder andere de autotechniek. Met weinig auto's is er geen behoefte verkeer expliciet te regelen. Zodra het er meer zijn, blijkt de kunde van hun samenhangende toepassing onontbeerlijk.
De rollen van informatiearchitect, respectievelijk systeemaannemer vallen niet samen met de vakken informatiekunde, respectievelijk informatica. Informatica en informatiekunde betreffen verschillende aspecten van de informatieverwerking in organisaties. Men kan in een concrete situatie de informatieverwerking door deze twee verschillende brillen beschouwen. De informatiearchitect en systeemaannemer verschillen vooral van elkaar omdat hun bijdragen, hun rollen, in het ontwikkelproces van elkaar verschillen. Zij houden zich bezig met verschillende aspecten van dat ontwikkelproces: beeldvorming en ontwerp, respectievelijk constructie en bouw.
Wat de informatiearchitect, een informatiekundige dus, toevoegt is een ruimere oriëntatie. Hij rekt de betekenis van het begrip systeem bewust op. Zoals gezegd, dat is zijn vak. Dan verandert méé wat ontwikkeling van 'het' systeem allemaal inhoudt. De verruiming tot organisatie, proces, cultuur enzovoort heeft allemaal praktisch zin. Want het resultaat van de verandering is uiteindelijk verhoging van de effectiviteit van informatievoorziening en daardoor van de organisatie waarvoor de opdrachtgever optreedt.
De informatiearchitect vraagt door zijn bijdragen vooral aandacht voor ontwikkeling van een visie, hij werkt aan beeldvorming. Zo'n visie kan hijzelf compleet aandragen. Hij kan echter ook meer als begeleider functioneren en zodoende de opdrachtgever en andere betrokkenen stimuleren om zelf hun visie tot uitdrukking te brengen en verder te ontwikkelen. Naar omstandigheden maakt de informatiearchitect een keuze voor zijn eigen bijdrage en zet daarvoor passende werkwijzen en methoden in. Het spectrum reikt vanaf directief tot en met non‑directief.
De associatie met strategie, visie enzovoort maakt bijdragen van de informatiearchitect moeilijk meetbaar. Het lijkt uiteindelijk vaak een kwestie van smaak. Een opdrachtgever die de bijdrage van de informatiearchitect 'mooi' vindt, is tevreden. Het gaat dus om indrukken die wij slechts vaag, bijvoorbeeld met de term beleving, kunnen aanduiden. Voor schoonheid bestaat geen absoluut criterium. Het is tenslotte de opdrachtgever, en in onze complexe samenleving steeds vaker samen met talloze andere betrokkenen, die hun subjectief oordeel over de toegevoegde waarde van architectuur vellen.
Wie oog heeft voor strategie, is eerder geneigd de bijdrage van een informatiearchitect naar waarde te schatten. In het oordeel spelen bewuste en onbewuste ervaringen uit het verleden en even bewuste en onbewuste verwachtingen en ambities voor de toekomst integraal een rol.
De subjectiviteit van het oordeel van zijn opdracht'veld' stelt de informatiearchitect voor bijzondere problemen. Acceptatie veronderstelt toereikende beeldvorming. Ons aforisme luidt dat een informatiearchitect in de praktijk zo goed is als het beeld waarmee hij zijn opdrachtgever en overige betrokkenen tot handelen met goed resultaat aanzet. Wie in de vorige zin twee maal 'goed' door twee maal 'slecht' vervangt, heeft meteen onze definitie van een slechte informatiearchitect.
Scherp onderscheid tussen informatiearchitecten en systeemaannemers, waaraan voor complexe veranderingsprocessen dus behoefte is, verduidelijkt diverse problemen zoals die thans vaak spelen. Wij schetsen enkele daarvan omdat er evenzovele obstakels bestaan voor een evenwichtige rolverdeling. Inzicht in dergelijke problemen is de eerste stap op weg naar gewijzigde verhoudingen. Tot en met de architectopleidingen moet er naar onze mening nog veel veranderen.
Er zou helemaal geen misvatting over systeemontwikkeling zijn, indien specialisatie tot bouw van programmatuur beperkt gebleven was. Dan was immers de betekenis van het begrip nooit verschoven. Inmiddels is er behoefte aan architectuur. Er bestaan echter voor informatievoorziening nog obstakels die belemmeren dat het architectuuraspect tot ontplooiing komt. Dat heeft met de geleidelijke groei van het besef van complexiteit te maken. In eerste aanleg had de arbeidsdeling betrekking op de uitvoerende werkzaamheden voor programmatuurontwikkeling. Wie dat als dienst verleent, heet naar analogie met de traditionele bouw een aannemer.
De crux is hier nu dat uitvoerend werk meestal eerder uitbesteed wordt dan het ontwerpen. Dat is bijna universeel. Zo is dat ongetwijfeld bijvoorbeeld ook in de traditionele bouw begonnen. Daar was het rollenpatroon met aannemers en architecten zeker niet van meet af aan gevestigd. Waar een systeemaannemer faalt door de complexiteit van de opgave, te weten omdat er voor ontwikkeling van de cultuur onvoldoende aandacht is, krijgt de informatiearchitect pas zijn kans.
Dergelijke mislukkingen vallen voor traditionele bouw buiten de menselijke herinnering. De piramides, bijvoorbeeld, zijn al door aparte architecten ontworpen. Daarom nemen wij nu de rolverdeling in de bouw als onomstotelijk aan. Voor alles dat complexer is dan een kippenhok weet iedereen dat het onverstandig is om meteen een aannemer aan de slag te laten. Eerst is een ontwerp nodig en dus is de informatiearchitect eerst aan de beurt.
Maar aanvankelijk luidt het motto voor arbeidsdeling slechts: Beleid in eigen huis, uitvoering op afstand. En daarmee beschikt de systeemaannemer over een bijna niet in te lopen voorsprong wat de relatie met de opdrachtgever betreft. Dat blijkt wanneer de opdrachtgever ook voor ontwerp behoefte aan externe dienstverlening krijgt. Zeker als het om informatievoorziening gaat, ziet de opdrachtgever ontwerp nog in het verlengde van de uitvoering die hij eerder uitbesteedde. Zo gaat de systeemaannemer ook als informatiearchitect aan de slag. Van de evenwichtige rolverdeling zoals die in de traditionele bouw gegroeid is en waar aandacht voor ontwerp terecht vóórafgaat aan aandacht voor uitvoering, is voor informatievoorziening helaas nog geen sprake.
Een ander obstakel voor erkenning van de noodzaak om ook voor informatievoorziening apart een informatiearchitect in te schakelen, is gebrekkig besef van technologische variëteit. Zonder alternatieven valt immers niets te ontwerpen. Er is, met andere woorden, nog geen alarmerende complexiteit. Zo hebben zgn mainframes lang de benadering van informatievoorziening gedomineerd. Daarmee, als ware het een paradigma, stonden talloze keuzen a priori vast. Er bestond toen reëel slechts één informatietechnologie, die van het mainframe. En omdat de verruiming tot cultuur nog niet aan de orde was, leek één uniforme methode voor systeemontwikkeling voldoende. Dit werd de data‑driven benadering, die uitstekend past in het paradigma van het mainframe denken. Niet alleen dringt nù dus het besef door dat de oriëntatie op cultuur noodzakelijk is voor goed resultaat. Ook de beschikbaarheid van de grotere diversiteit in de informatietechnologie, maakt duidelijke dat er keuzen moeten worden gedaan.
De criteria voor die keuzen worden niet zozeer aan de technologie zelf ontleend — hoewel er onmiskenbaar sterke wisselwerking bestaat —, maar worden bepaald door de omgeving waarin de technologie wordt toegepast. Ontwerpen wordt daarmee in de eerste plaats een proces van synthese. Dit is de kern van bijdragen van de informatiearchitect. Want een cultuur is domweg te complex om een verandering direct te baseren op analyse, hetgeen weer het sterke punt van systeemaannemers is. Allereerst, nogmaals, moet er ruimte zijn voor synthese. Daar is de informatiearchitect voor. Het onderscheid tussen analyse en synthese is illustratief voor het onderscheid tussen systeemaannemers en informatiearchitecten.
In onze opvatting is er geen sprake van een keuze tussen informatiearchitecten òf systeemaannemers. Er is behoefte aan beide en derhalve geen sprake van concurrentie. Dit betekent echter niet dat deze twee partijen in een concreet project zonder spanningen met elkaar zullen samenwerken. Hun verschillende normen‑ en waardenpatronen en de verschillende paradigma's staan bijna borg voor onbegrip in de verhouding. Een opdrachtgever die dit begrijpt kan deze spanning in een project functioneel inzetten en zodoende de partijen elkaar doen inspireren tot grotere prestaties.
De systeemaannemer is bij het project betrokken omdat hij uitvoerend gedrag optimaliseert. Hij heeft de mind set for doing things right. Zijn sleutelwoord — nota bene, altijd tov de opdracht — is efficiency. Zijn concurrentiepositie is sterk wanneer hij kosten beheerst en zodoende zijn eigen marge veilig stelt.
De invalshoek van de systeemaannemer verschilt sterk van hoe de informatiearchitect een situatie benadert. Voor de informatiearchitect gaat het allereerst om doing the right things. Wat zijn dat eigenlijk, de juiste 'dingen'? Pas nadat effectiviteit van het resultaat via ontwerp gesimuleerd is, is het de beurt aan efficiency van het uitvoerende gedeelte van het proces. Dat is een kwestie van begrip van de prioriteiten tijdens welk veranderingsproces danook.
Er is lang niet altijd een aparte informatiearchitect nodig. Hij is bijvoorbeeld overbodig wanneer de opdrachtgever en/of de systeemaannemer zich het resultaat al goed kunnen voorstellen, bijvoorbeeld doordat zij beschikken over een voorbeeld dat kan worden nagebouwd. Dus, zolang situaties betrekkelijk simpel zijn is er geen behoefte aan het onderscheid tussen informatiearchitect en systeemaannemer. Waar de grens ligt, is van vele factoren afhankelijk. Zoals gezegd, wat kan de opdrachtgever zich zonder hulp voorstellen van het resultaat inclusief veranderingsproces? Hoever gaat de verandering van de oorspronkelijke situatie voeren? In elk geval is boven de grens de inbreng van een informatiearchitect onmisbaar. De ervaring leert dat zowel in de informatievoorziening als in de bouwwereld een opdrachtgever na een eerste project sneller de grens bereikt dan hij aanvankelijk dacht.
Wat zou er gebeurd zijn wanneer niet de systeemaannemer, maar de informatiearchitect als eerste zijn voet tussen de deur bij de opdrachtgever gehad gezet? Volgens onze logica had de informatiearchitect dan geprobeerd de aannemerij erbij te doen. Dat gebeurt ook inderdaad. Soms is dat onvermijdelijk, bijvoorbeeld waar het ontwerpaspect overheersend is en blijft. Zo komen prototypes voor realisatie door de informatiearchitect in aanmerking; zij maken als het ware nog deel van de ontwerpactiviteiten uit. Waar de bouw van programmatuur tot efficiency noodzaakt, zouden als systeemaannemer vermomde informatiearchitecten snel door de mand moeten vallen. Efficiency is per definitie eenvoudiger toetsbaar dan effectiviteit (al was het maar omdat het laatstgenoemde uitgangspunt voor het eerste is).
Systeemaannemers kunnen hun praktijken als slechte architect veel langer voortzetten dan het informatiearchitecten als slechte aannemer lukt. Dat komt ook omdat het produkt van de informatiearchitect niet een constructie is in de fysieke zin van wat de systeemaannemer tijdens uitvoering levert. Juist het a priori‑karakter van een ontwerp, zeg ook maar dat het nog herroepelijk is, maakt het niet objectief toetsbaar. De grotere ongrijpbaarheid van het ontwerpaspect leidt de aandacht van harde confrontatie af.
Thans zijn in het vlak van informatievoorziening informatiearchitecten en systeemaannemers nog vergaand concurrenten van elkaar. Dat komt omdat er op korte termijn eigen belang bij gebaat is. Softwarehuizen, die zich bijna allemaal als systeemaannemer hebben ontwikkeld, komen concreet voor de keuze te staan: Zijn wij systeemaannemer of informatiearchitect? De directie kiest uit overwegingen over omzet meestal voor beide tegelijk.
De praktijk leert echter, zowel in de bouw als in de informatievoorziening dat een organisatie de twee extreem verschillende culturen niet kan omvatten. De keuze wordt onvermijdelijk. Voor de opdrachtgevers is er een eenvoudige regel: Ga er maar vanuit dat een softwarehuis dat niet kiest een systeemaannemer is.
Systeemaannemers menen stellig dat zij een positie te verliezen hebben. Zoals de traditionele bouw voor de zoveelste keer leert, is de veronderstelling van een concurrentieverhouding tussen informatiearchitecten en systeemaannemers echter onzinnig. Partijen moeten hun afwijkende rollen adequaat spelen.
Wie niet begrijpt dat er in de totale ontwikkeling van een organisatie, van een proces of van wat danook als 'het' systeem geldt een verschil bestaat tussen ontwerp en uitvoering, zal hetzij ontwerp, hetzij uitvoering ten onrechte voorrang geven. In de verouderde betekenis van systeemontwikkeling is het precies de uitvoering door systeemaannemers die overheerst. In de totale ontwikkeling is daar geen ruimte voor ontwerp, althans niet voor ontwerp zoals een echte informatiearchitect dat ziet. Hoogstens wordt de term ontwerp of zelfs de term architectuur in de beschrijving van de methode voor systeemontwikkeling gebruikt, maar ontdaan van de cultuurdimensie en daardoor zielloos. Ook in de informatievoorziening hebben systeemaannemers informatiearchitecten nodig, en uiteraard omgekeerd.
De marktpositie van systeemaannemers in de informatievoorziening is vooralsnog bevoorrecht ten opzichte van die van informatiearchitecten. In de bouwkunde is overigens al van een andere verhouding sprake, maar die economische sector is alweer zoveel rijper. Daar schijnt tegenwoordig slechts de zgn projectontwikkelaar goed te verdienen en spelen zowel architect als aannemer vaak ondergeschiktere rollen. Vele bouwarchitecten en ‑aannemers balanceren op de grens van het economisch verantwoord bestaan, met als grote uitzonderingen zij die in hun vak tot de, door opdrachtgevers erkende, top behoren.
Het is naar onze mening evident dat in het vlak van informatievoorziening voor complexe organisaties de informatiearchitecten en systeemaannemers er met hun concurrentie onderling niet uitkomen. De systeemaannemers zullen uit zichzelf nooit hun positie opgeven. Het gaat immers om geld en juist systeemaannemers vinden dat heel belangrijk. Dat klopt ook. Anders zouden zij de uitvoering niet efficiënt kunnen doen. Dat is op zichzelf dus een prima eigenschap.
Informatiearchitecten verwachten echter te worden beoordeeld op effectiviteit Zelfs de meest efficiënte uitvoering is hopeloos verspillend, indien het resultaat kant noch wal raakt. Wij durven gerust de stelling aan dat uitvoering orden van grootte minder efficiënt kan, als de effectiviteit van informatievoorziening maar gewaarborgd is. Het saldo is immers nog altijd gunstiger dan van een mooi gereedschap dat onbruikbaar is.
Alleen de opdrachtgevers kunnen een gezondere verhouding bewerkstelligen tussen informatiearchitecten en systeemaannemers. Een opdrachtgever moet inzien dat het uiteindelijke resultaat gebaat is bij evenwichtige samenwerking met zowel informatiearchitect, als systeemaannemer. Er moet een opbouwende spanning bestaan tussen wat de informatiearchitect, respectievelijk de systeemaannemer bijdraagt. Gelet op wezenlijke verschillen is het raadzaam hun rollen niet te vermengen. Als dat wel gebeurt, die vermenging, komt de spanning niet tot haar recht (en grijpt de projectontwikkelaar ook voor informatievoorziening zijn kans). Een goede informatiearchitect functioneert goed in een ander klimaat dan een systeemaannemer dat doet. Hieruit volgt onder meer dat een goede informatiearchitect nooit bij een aanneembedrijf, hoe goed dat op zijn beurt ook is, kan werken, en omgekeerd.
De doorbraak bij opdrachtgevers lukt uiteraard nooit, zolang iedereen zich als informatiearchitect presenteert. Zoals het nu is, schaadt de ellende die systeemaannemers in hun vermomming als informatiearchitect aanbrengen het imago van de architectenrol. Wanneer dat niet ophoudt, weet een opdrachtgever het natuurlijk ook niet. Helderheid over rollen tijdens complexe veranderingsprocessen is de voornaamste reden waarom wij vóór bescherming van de titel van informatiearchitect pleiten. Overigens zien wij aan dergelijke institutionalisatie tevens allerlei gevaren verbonden.
Zo'n negatief aspect is bijvoorbeeld de niet uit te roeien willekeur van de coöptatie. Maar vooralsnog zien wij praktisch meer voor‑ dan nadelen van bescherming van de positie van de informatiearchitect. Daar zijn allereerst de echte informatiearchitecten blij mee. Belangrijker is dat de kwaliteit van de informatievoorziening in complexe situaties ermee gediend is. De juiste informatiearchitect kan spectaculair bijdragen aan succes.
Het is immers, omgekeerd, het ontbreken van een goede informatiearchitect dat één van de belangrijkste oorzaken is van falende informatievoorziening en van alle frustraties bij de opdrachtgever en overige betrokkenen vandien.
Met erkenning van het onderscheid tussen informatiearchitecten en systeemaannemers is het probleem van informatievoorziening uiteraard niet zomaar opgelost. Het gaat er vervolgens om dat goede informatiearchitecten, respectievelijk systeemaannemers herkenbaar zijn. Wij menen dat herkenning van goede systeemaannemers eenvoudiger is. Over bijdragen van een informatiearchitect is het oordeel per definitie subjectiever. Zoiets als de ISO9000‑serie, die gericht is op proceskwaliteit, is naar haar aard van meer toepassing op systeemaannemers. Bij de systeemaannemers staat immers het proces en de beheersing daarvan centraal. Hun produkt is vanaf het begin van hun inbreng gespecificeerd. Dit gaat niet of nauwelijks op voor informatiearchitecten. Dit betekent niet dat een informatiearchitect geen aandacht hoeft te besteden aan de kwaliteit van het ontwerpproces. Toepassing van de ISO‑normen daarop levert echter geen enkele garantie voor een goed produkt. Integendeel, durven wij gerust te zeggen. Wat ons betreft is een informatiearchitect vooral ook dàn goed als hij zich open opstelt en zijn opdrachtgever aldus leert een passend oordeel over voorstellingen van de toekomst te vellen. Of omgekeerd geredeneerd, een informatiearchitect die niet opvoedt tot zo'n oordeel is o.i. verdacht.
De wettelijke bescherming van de titel informatiearchitect is nog geen waarborg voor kwaliteit. Juist voor de bijdragen van een informatiearchitect is een waarborg a priori onmogelijk. Wat redelijkerwijs van bescherming van de architecttitel valt te hopen, is dat er tenminste een verschijnsel is — te weten de informatiearchitect — waarover vervolgens in termen van goed en slecht geoordeeld moet worden. Wat goed of slecht is, kan trouwens ervaring slechts leren. Daarom moeten bij verreikende ontwerpen altijd ervaren informatiearchitecten betrokken zijn, op z'n minst voor toetsing van wat onervaren informatiearchitecten voorstellen.
Iedere gewoonte is eigenlijk een methode. De geconsolideerde ervaring behoedt in zekere mate voor fouten. Althans, dat lukt voorzover omstandigheden niet de grens overschrijden van waarin dat routinematig gedrag voorziet. Voorts is de snelheid van de handeling gebaat bij toepassing van methoden. In plaats van volledig 'ontwerp' van gedrag volstaat keuze uit het repertoire van methoden. Als zodanig hebben methoden voor iedereen grote waarde.
Zo beschouwd, dekt de term methode een ruime lading. Voor effectievere communicatie is dus een nuancering aan de orde. Overeenkomstig het onderscheid tussen informatiearchitecten en systeemaannemers neemt de duidelijkheid toe door niet meer over ontwikkelmethoden te spreken, maar over ontwerp‑, respectievelijk bouwmethoden. Of over architecten‑ en aannemersmethoden. Dit werkt verhelderend omdat daardoor van alles van wat nu nog ontwikkelmethoden heet aantoonbaar gebaseerd is op de invalshoek van de systeemaannemers. Dat zijn au fond dus, nauwkeuriger uitgedrukt, allemaal bouw‑ ofwel aannemersmethoden. Voorzover er daarin al van ontwerp sprake is, blijkt dat het oprekken van de oorspronkelijke aannemersmethode te zijn. Dat schiet echter altijd tekort. Ontwerp is kwalitatief ànders. De invalshoek van de informatiearchitect verschilt wezenlijk van die van de systeemaannemer. Uit een aannemersmethode kan nooit een geschikte architectenmethode ontstaan. Een ontwerp‑ ofwel architectenmethode moet uitgaan van de toegevoegde waarde van de informatiearchitect. Dat is, het woord zegt het al, ontwerpen, niet bouwen. Het is daarom hoog tijd dat systeemaannemers ophouden met hun pogingen om hun aannemersmethoden universeel geldig te verklaren voor de totale systeemontwikkeling. Nota bene, onder systeem verstaan wij hier dus niet een computerprogramma, maar een organisatie met een karakteristieke cultuur en processen.
Zowel de informatiearchitect, als de systeemaannemer moet beschikken over allerlei methoden als evenzovele gereedschappen. Voor uiteenlopende opgaven in de loop van de systeemontwikkeling kiest hij voor de voorliggende opgave steeds het gereedschap dat het best past. Zo zijn zowel architecten‑, als aannemersmethoden in vele soorten en maten herkenbaar.
Waar komen goede informatiearchitecten vandaan? Het staat vast dat gevarieerde ervaring belangrijk is. De basis wordt echter vroeg gelegd aangezien de rol van de informatiearchitect vooral een passende attitude verlangt. Hieruit volgen eisen waaraan onder andere de opleiding tot informatiearchitect moet voldoen. Want er bestaat natuurlijk eveneens voor architectopleidingen, inderdaad, een architectuur. Wij gebruiken deze recursiviteit om kortweg een manco bloot te leggen.
Het is o.i. onmogelijk om informatiearchitecten door systeemaannemers te laten opleiden. Helaas is dat nog precies wat er in het vlak van de informatievoorziening teveel gebeurt. Wat systeemaannemers uitstekend kunnen, is zoiets als constructieleer doceren. Dat is echter, nogmaals, fundamenteel anders dan architectuur. Constructieleer betreft noodzakelijke basistechnieken voor het bouwaspect van ontwikkeling. Architectuur omvat hun geïntegreerde toepassing waarbij het geheel ook nog eens méér is dan de som der delen. Tijdens de opleiding tot informatiearchitect, waar danook, moet integratie in cultuur daarom voorop staan. Dat gaat mis met accent op één of andere aannemersmethode. Zolang het onderwijs daarbij blijft, ontwikkelt de student niets meer of minder dan loyaliteit aan de methode die de voorkeur van zijn docent heeft. Netzo als met de band met een voetbalclub, komt hij niet eenvoudig van die besmetting met een aannemersmethode af. En op weg naar de rol van informatiearchitect is de student precies de verkeerde richting uitgestuurd.
Hoe moet het wel? Wat de informatiearchitect toevoegt is uiteindelijk zijn persoonlijkheid. In zijn persoonlijkheid heeft hij gedurende lange jaren allerlei ervaringen, houdingen, kennis en vaardigheden geïntegreerd. Omdat die integratie zo onnavolgbaar complex is, valt er niets deterministisch over het resultaat te zeggen. Nogmaals, daarom zeggen wij dat het uiteindelijk de totale persoon van de informatiearchitect is die telt. Vanuit dit besef zijn de consequenties voor de architectuur van de opleiding tot informatiearchitect duidelijk. Tijdens de opleiding moet de ontwikkeling van de persoonlijkheid centraal staan. De rest komt dan min of meer vanzelf.
Dit komt er allemaal op neer dat er maar één soort mensen is dat informatiearchitecten kan opleiden. En dat zijn ... informatiearchitecten. Wat er ooit misging, is dat uit behoefte aan beheersing van het ontwikkelproces nadruk op methoden kwam te liggen, en dan nog wel op aannemersmethoden. Dat was in de tijd dat systeem voornamelijk computerprogramma betekende. En toen was het best reëel ook. Zo kwamen de systeemaannemers als voornaamste opleiders in aanmerking. Ook voor moderne informatievoorziening zijn zij er helaas nog. In het vlak van de traditionele bouwkunde is dankzij eeuwenlange ervaring het evenwicht in de docentenstaf (alweer?) veel groter. Wij herhalen dat een principiële ontwerphouding voor de informatiearchitect van wezenlijk belang is. Zo'n houding valt niet passief te leren, maar kan de student slechts zelf en actief aan de hand van inspirerende voorbeelden opbouwen. Dat voorbeeld moet een goede informatiearchitect geven. Van een systeemaannemer leert de student niet ontwerpen, maar bouwen.
Architectuur wordt als studie weliswaar ook aan instellingen met de status van universiteit aangeboden, maar daarmee is het nog geen wetenschap in de afstandelijk beschouwende zin van allerlei ‑logieën. De wezenlijke houding van de ontwerper moet die van een ingenieur zijn. Het gaat erom iets te bedenken om dat vervolgens daadwerkelijk te laten realiseren. Dat is een instelling die bijvoorbeeld ook volstrekt afwijkt van onderzoek aan de kant van de humanitaire studies. Wie zo'n onderzoeker vraagt om een aanstaande ontwerper te begeleiden, maakt iedereen ongelukkig. Docerende systeemaannemers moeten dus beslist niet door sociologen en dergelijke vervangen worden. Daarmee krijgt de student nog steeds de relevante ervaringen niet geregisseerd en kan na afloop van zijn studie niet als informatiearchitect zijn kenmerkende bijdrage aan kwaliteit van informatievoorziening leveren. Er moeten echte, praktiserende informatiearchitecten bij de opleidingen tot informatiearchitect betrokken zijn. Daar ligt een sleutel tot verbeteringen. De opzet van opleidingen moet respecteren dat architectuur wezenlijk ànders is. Een andere sleutel hebben uiteraard opdrachtgevers in handen. Zij moeten ook voor informatievoorziening het belang van bijdragen van een goede informatiearchitect inzien. Vraag schept aanbod.
Hier komen wij even terug op de bescherming van de titel van informatiearchitect. Uit onze nadruk op de persoonlijkheid van de informatiearchitect volgt meteen dat certificatie problematisch is. Want wat is goed? Wat is de grondslag voor een oordeel. Vergelijk het met een vriend van ons die heel jong al mooi viool speelde. Dat was zo bijzonder dat hij in het beroemde Berliner Philharmoniker opgenomen werd. Zijn studie aan het conservatorium maakte hij niet af, dat hoefde niet. Daar is hij nu echter wel docent.
Nogmaals, wat zijn relevante criteria? Daar komen wij voor de informatiearchitect met een check list en eisen voor allerlei diplomaatjes niet uit.
Vanuit een darwinistisch vertrekpunt verkrijgt vanalles en nog wat in cultuur het stempel van architectuur. Want er is volgens onze definitie sprake van architectuur wanneer een ontwerp ten grondslag ligt aan het uiteindelijk gerealiseerde resultaat. Daarbij staat bewustzijn overigens nog los van de kwaliteit van dat resultaat.
In de vorige paragraaf hebben wij expliciet aandacht geschonken aan de architectuur van de architectopleiding. Dat zijn natuurlijk algemeen geldige opmerkingen, maar nu relevant voor informatiekundige architecten. Als de opzet van de opleidingen niet verandert, hoeft niemand verbaasd te blijven dat er weinig goede architecten voor informatievoorziening zijn.
Op dezelfde manier kunnen wij het verschijnsel methode aan een architectuurbeschouwing onderwerpen. Want op hun beurt zijn de talloze expliciete architecten‑ en aannemersmethoden resultaat van ontwerp. Met andere woorden, wat is de architectuur van de methode?
Antwoord op deze vraag is uitgebreid en verrassend. Maar hoe danook is allereerst nodig dat het onderscheid tussen informatiearchitecten en systeemaannemers inclusief hun respectievelijke methoden duidelijk is. Aan dat onderscheid hebben wij daarom dit hoofdstuk gewijd. Wij sporen de lezers aan over de architectuur van de methode eens hun eigen gedachten te laten gaan. Wie met zoiets als de architectuur van de voetbalclub of de architectuur van de supporter begint, zit wat ons betreft op het goede spoor.
Informatiearchitecten, in de zin van echte ontwerpers, zijn voor informatievoorziening in complexe organisaties en processen nog schaars. Dergelijke schaarste is overigens niet uniek voor informatievoorziening. Aan goede architecten is helaas op allerlei terrein gebrek. Systeemaannemers die zich tegelijk informatiearchitect noemen zijn er in het vlak van informatievoorziening des te meer.
Informatiearchitecten en systeemaannemers, mits ze goed zijn, verdienen elkaars respect. Daarvoor is reële erkenning noodzakelijk van hun wezenlijk onderscheid inclusief de methoden die zij hanteren. Heel praktisch staat het voor ons vast dat zij niet beiden in dezelfde organisatorische cultuur passen. Informatiearchitecten bij een aannemerij of, omgekeerd, systeemaannemers in dienst van een architectenbureau zijn verdacht. De opdrachtgever die opbouwende spanning wenst, haalt informatiearchitect en systeemaannemers er dus apart bij, nooit van dezelfde bron.
Voor de kwaliteit van de informatievoorziening valt het te hopen dat informatiearchitecten en systeemaannemers spoedig een evenwichtige vorm van samenwerking vinden. Dat is tenslotte, zij het soms pas na eeuwen, op andere gebieden zoals dat van de bouwkunde ook aardig gelukt.
Rees, J.R. van, 'De Methode Doet Het Niet,' in: Informatie, jaargang 24, nummer 2, 1982.
Simon, H., Psychologie en systeemtheorie,
Spectrum, Aula‑reeks nr 569.
Stimuleringsfonds voor Architectuur, De betekenis van
Architectuur, 1993.
Wisse, P.E., 'Architecten,'
infogram in: Informatie, jaargang 35, 1993, nr 3.
————, 'Van Rees over informatiekunde en
zijn constructieprincipes,' interview in: OT
Magazine, jaargang 1, nummer 5, 1994.
Wet op de architectentitel, Staatsblad van het Koninkrijk der Nederlanden, jaargang
1897, nr 347.
© 1994, webeditie 2002.
De tekst van dit hoofdstuk verscheen eerder als artikel in: Informatie, jaargang 37, nummer 4, april 1995 en De informatie-architect (Kluwer Bedrijfswetenschappen,
1995).