Jaap van Rees en Pieter Wisse
Groot was in de loop van 1994 de opluchting in de automatiseringsbranche. Het leek erop dat de markt was ingestort en zich nooit zou herstellen, maar de groei kwam terug. Sneller dan verwacht. "Wij hebben de crisis krachtig overwonnen," zo luidt de trotse constatering van de overblijvers.
Maar niet overal heerst optimisme. Want dat herstel is allemaal onzin, menen wij. De crisis is helemaal niet voorbij. De economische opleving verhult fundamentele problemen met informatievoorziening. Zeker, de financiële omzetten zijn opnieuw interessant. De werkgelegenheid in de branche neemt weer toe. De kwaliteit is echter vaak belabberd, alle flitsende ergonomie ten spijt. De verspilling van mensen en middelen is vrijwel altijd schokkend. Economisch gezien is er sprake van kapitaalvernietiging. Dat komt omdat ingewikkelde vraagstukken nog steeds met versimpelde ideeën en oplossingen bestreden worden. Het is, bijvoorbeeld, alsof stadsplanning aan een stratemaker wordt overgelaten. Netzo geven bij informatievoorziening de programmeurs en hun directe afstammelingen de toon aan. Dat leidt tot slechte, dure resultaten. Het is allerhoogste tijd om ook informatievoorziening door èchte architecten te laten ontwerpen. Het is dus tijd voor informatiearchitecten. Wij zijn pas optimistisch als informatiearchitecten de nodige ruimte hebben voor hun bijdragen aan informatievoorziening in complexe processen en organisaties.
Een stedebouwkundige is niet een beter of een slechter mens dan een stratemaker. Het ene vak is ook niet beter dan het andere. Dat misverstand zetten wij daarom meteen maar recht. Zij hebben gewoon elk hun eigen vak. Het is dus net zo onverstandig om een stedebouwkundige een stoep te laten betegelen, als een stratemaker naar een omvattende visie op stadsontwikkeling te vragen. Dat wordt allebei niets.
Wij zijn van mening dat de vakgebieden die zich bezighouden met het ontwikkelen van informatievoorziening, te weten informatiekunde en informatica, toegegroeid zijn naar het invoeren van een rolverdeling tussen architect en aannemer zoals die al in de bouwwereld bestaat. Grofweg spreken wij naar analogie met de bouwwereld ook voor informatievoorziening over architecten en aannemers. Of preciezer: informatiearchitecten respectievelijk systeemaannemers. En dan geldt, als het vraagstuk tenminste voldoende ingewikkeld is, dat een goede informatiearchitect (lees ook: informatiekundig ontwerper) waarschijnlijk een slechte systeemaannemer (lees ook: informatica-ontwikkelaar) is, en omgekeerd. Niet voor niets heet het: Schoenmaker, houd je bij je leest!
Een kikker die in een pot kokend water gegooid wordt, springt er subiet uit; wie daarentegen het dier in koud water zet en dat geleidelijk verhit, houdt een gekookte kikker over. Blijkbaar is het gevaar van langzame verandering, dat actie uitblijft. Met andere woorden, het paradigma stagneert terwijl juist radicale verandering noodzakelijk is.
De problemen met informatievoorziening zijn vergelijkbaar met een hoeveelheid water die al behoorlijk warm aan het worden is. En de temperatuur stijgt verder. Desondanks gaat menigeen er voor zijn activiteiten nog vanuit dat het water steenkoud is. Ofwel, de programmeur die met een eenvoudige voorziening een vervelend probleem weet op te lossen, krijgt eveneens de gelegenheid om complexe informatievoorziening te realiseren. Ongemerkt komt hij daardoor terecht in situaties waarvan hij extra dimensies als variëteit en cultuur niet waarneemt. Het moet ànders als de situatie ingewikkelder is. Voor ontwerp volstaat het paradigma van de systeemaannemer/ontwikkelaar dan niet meer. Gevraagd is nu een informatiearchitect/ontwerper met zijn passende paradigma.
Het hangt er maar vanaf wanneer water koud is, of juist warm. De grens ertussen is helemaal problematisch. Maar hoewel onmogelijk te fixeren, helpt zo'n grens de uitersten scherper te stellen. Dat geldt dus ook voor het verschil tussen de informatiearchitect en de systeemaannemer.
Karakteristiek voor de aannemer is extrapolatie. Dat wil zeggen, méér van hetzelfde. De stratemaker legt netzolang dezelfde stenen totdat het totale oppervlakte bedekt is. Het maakt niet uit of één steen volstaat, of dat er 100.000 nodig zijn. De ontwerper daarentegen vraagt zich af, of de straatsteen wel het meest geëigende bouwelement is. Wellicht biedt asfalt een betere oplossing. Maar hij gaat vaak verder door naar de straatbedekking als middel voor een overkoepelend doel te kijken. Zijn er andere middelen denkbaar? Beter? Loont het om zelfs dat doel kritisch te onderzoeken? Enzovoort. Dat zijn allemaal vragen die een stratemaker meestal niet stelt.
Analoog hieraan kiest de klassieke programmeur er dikwijls voor om variabelen en instructies toe te voegen wanneer de relevante werkelijkheid daar aanleiding toe geeft. Vanuit een eenvoudig begin kan zo een onbeheersbaar informatiesysteem groeien. De ontwerper oriënteert zich juist op die werkelijkheid, verwerft inzicht in de complexiteit ervan. Wat voor de programmeur allemaal verschillende variabelen zijn, bijvoorbeeld, ziet hij eerder als verschijningsvormen van één variabele die waarden uit een beheerst domein aanneemt. Via abstractie neemt zowel het aantal variabelen, als het aantal instructies dramatisch af. Als zodanig is abstractie de remedie tegen op hol geslagen extrapolatie.
Princiële oriëntatie op de relevante werkelijkheid — en dat is in een notedop het paradigma van de ontwerper — levert méér op dan compacte informatievoorziening met alle voordelen van dien. Want behalve efficiënt is de informatievoorziening eerst en vooral effectief. De informatiearchitect/ontwerper is er om te mikken en de systeemaannemer/ontwikkelaar om te schieten. Ergens daartussen ligt de grens die informatiearchitecten van systeemaannemers scheidt.
De extrapolatie van de systeemaannemers is optimaal ... maar slechts vanuit de korte-termijn optiek van diezelfde aannemers. Er zit veel werk aan vast om informatievoorziening met een schier oneindige reeks variabelen en instructies vorm te geven. En zolang systeemaannemers werken op basis van uren-maal-tarief, leidt extrapolatie tot exponentieel hogere omzet. Want dat is immers dezelfde exponent waarmee de informatiearchitect de complexiteit vermindert door te abstraheren. Het is allemaal heel logisch voor wie als informatiearchitect kijkt.
Er is echter niet alleen korte termijn. En er zijn vooral opdrachtgevers. Het bestaansrecht op langere termijn, ook van systeemaannemers, is erbij gebaat dat opdrachtgevers passende oplossingen voor hun reële problemen krijgen. Informatievoorziening moet zowel effectief, als efficiënt zijn. Daarbij moeten systeemaannemers met hun informatica-achtergrond beseffen dat efficiency vooral het operationele stadium geldt. Beheersbaar onderhoud betekent voor de opdrachtgever een groot probleem minder.
Met de opdrachtgever uiteraard in een centrale positie, hebben informatiearchitecten en systeemaannemers alles bij onderlinge samenwerking te winnen. Een obstakel is onder andere de opdrachtgever die als een kikker in een waterbad langzaam verwarmd wordt. Als het te laat is, kan hij niet meer springen. Hoe komt hij ertoe zich voor ontwerp tot een informatiearchitect te wenden? Hiervoor moeten systeemaannemers boven zichzelf uitstijgen; zij kunnen een informatiearchitect aanbevelen. Het is echter twijfelachtig of dat zo snel gebeurt. "Het hemd is nader dan de rok" is een andere toepasselijke wijsheid die in de vorm van een spreekwoord gegoten is.
Waarom menen wij dat de interventie van de informatiearchitect toch vooral speels moet zijn? Dat heeft ermee te maken dat van aanwending van een methode onherroepelijk macht uitgaat. Dat is precies waarom de architect zichzelf niet al te serieus moet nemen. Die machtsuitoefening moet hij altijd blijven relativeren. Hij moet de verleiding weerstaan om bijvoorbeeld de positie van zijn opdrachtgever te vervullen. Met 'speels' bedoelen wij daarom, dat de architect snapt dat hij hij weliswaar onvermijdelijk invloed heeft, maar dat hij er zowel de tijdelijkheid als de dienstbaarheid van inziet. Hij oefent zijn macht immers uit bij de gratie van de uitnodiging door de opdrachtgever. De architect mag de gastvrijheid niet misbruiken. Dit kan allemaal verkeerd gaan, bijvoorbeeld met een architect die onverantwoord handelt. En natuurlijk zijn er slechte architecten, zoals er ook belabberde systeemaannemers zijn. De kans op compleet verkeerde uitkomst is zelfs groter indien een aannemer de rol van architect 'speelt.' Dat gaat altijd mis, vooral omdat de beleving van wat een methode is zo totaal verschilt tussen systeemaannemers en andere betrokkenen. Karakteristiek voor een goede aannemer is juist zijn oriëntatie op methoden en de efficiency die hij daardoor bereikt. Maar methoden zijn uiteraard betrekkelijk; zij verliezen buiten een beperkt domein hun geldigheid. Wie zulke betrekkelijkheid niet inziet, vormt een gevaar. De systeemaannemer mag best geldigheid van zijn methoden veronderstellen, maar uitsluitend in zijn rol als ... aannemer en onder regie van de opdrachtgever die zich daar eventueel door een architect in laat bijstaan. Een aannemer die voor zijn methode absolute geldigheid opeist heeft in de rol van architect een machtspositie verworven die gevaarlijk is. Want opdrachtgever en als architect vermomde aannemer kunnen hun verhouding zelden zo analyseren, dat er een uitweg is voordat ongelukken gebeurd zijn.
Het is twijfelachtig of opdrachtgevers al op grote schaal in staat zijn om de aparte rol van de informatiearchitect te erkennen. Als het om complexe informatievoorziening gaat, heeft besluitvorming tegenwoordig wel op de hoogste niveaus in de organisatie plaats, al is het maar omdat er veel geld mee gemoeid is. De praktijk wijst echter uit dat ervaring met en/of gevoel voor dergelijke informatievoorziening bij het zittend management vaak nog onvoldoende is voor een genuanceerd oordeel en passende sturing van veranderingen. Meestal blijft de voorstelling daar beperkt tot het uiteindelijke gereedschap. Het resultaat van het zogenaamde project is dan gedefinieerd in termen van computerprogrammatuur en -apparatuur. Met zo'n overzichtelijke doelstelling kan het project ook niet zo ingewikkeld zijn. Het is alweer een reden dat de aannemer in het allervroegste stadium zijn kans krijgt. De architect weet daarentegen dat techniek slechts één aspect bepaalt, een vaak ondergeschikt en meestal afgeleid aspect bovendien. Als resultaat van het veranderingsproces moet een andere organsatie, een ander proces of iets dergelijks gelden. Het probleem met de opdrachtgever is inderdaad dat de voorstelling van een andere organisatie met eventueel zelfs andere mensen veel moeilijker is dan die van iets dat tot een kastje met flikkerende lampjes beperkt kan blijven.
Dit probleem verklaart direct waaraan de informatiearchitect de meeste aandacht moet schenken. Dat zijn de voorstellingen, de beelden, de betekenissen en dergelijke die de opdrachtgever vormt. En het is niet alleen de opdrachtgever, maar iedereen die verder maar bij het veranderingsproces betrokken raakt. Mensen beginnen hun deelname aan zo'n proces met bepaalde betekenissen, gaandeweg brengen zij er verandering in. De architect stuurt het veranderingsproces, juist door invloed uit te oefenen op de ontwikkeling van betekenissen, beelden die de betrokken mensen hanteren. Hieruit volgt de primaire oriëntatie van de informatiearchitect. Hij kijkt naar wie allemaal met het uiteindelijke resultaat te maken krijgt. Dat is, populair gezegd, de doelgroep. De verantwoord handelende architect kan de doelgroep niet ruim genoeg zien. Wie ertoe behoort, is per definitie deelnemer aan het veranderingsproces. Waar dat door het aantal betrokken mensen onpraktisch is, zijn vertegenwoordigers nodig. Het contact met de totale doelgroep verdient echter voortdurend aandacht. Zonder minimaal contact dreigt mislukking.
Wat wil de opdrachtgever? Wat willen overige betrokkenen? Zoals gezegd begeleidt de informatiearchitect eerst en vooral de beeldvorming bij betrokkenen omtrent hun toekomstige organisatie, hun proces, hun cultuur in de toekomst enzovoort. In aannemerstermen heet bijvoorbeeld de organisatie inclusief informatievoorziening die gerealiseerd gaat worden een constructie. Het is dus iets dat gemaakt, geconstrueerd gaat worden. Of op z'n minst zullen betrokkenen op grond van een ontwerp enige invloed uitoefenen. Waar de architect op let is dat zo'n constructie voor iedereen, met de opdrachtgever en vooral de gebruikers voorop, iets reëels betekent. Als zodanig is de architect bezig met de semantiek van de constructie.
De constructie verwijst naar het uiteindelijk resultaat. De semantiek van die (te realiseren) constructie vormen deelnemers echter vaak al beslissend in de vroegste fasen van hun veranderingsproces. Niet in aannemerstermen maar nu in zijn eigen architectentermen, is de architect daar bezig met constructie van semantiek. In het vlak van betekenissen is de architect dus ook ... aannemer. De constructie van semantiek is evenwel van een andere orde dan de constructie van hulpmiddelen voor digitale informatieverwerking. Het eerste is informatiekunde, het tweede informatica. Vandaar dat ook voor het ontwikkelen van (gereedschappen voor) informatievoorziening het onderscheid tussen architecten en aannemers onverminderd nodig blijft.
Het dilemma voor de architect is dat hij zijn methoden niet tegelijk met zijn activiteiten van het communiceren kan verduidelijken. Zoals wij hierboven aangaven, laat de architect zijn (communicatie)methoden dus bij voorkeur impliciet. Dat is het spel. De aannemer kan explicieter zijn over zijn methoden. Hij kan ermee toelichten dat de opdrachtgever en de architect kunnen vertrouwen op de kwaliteit van het resultaat en op de doelmatigheid waarmee dat bereikt wordt. Dat is niet verwarrend zolang de communicatie uitsluitend in het teken van het vestigen van dat vertrouwen staat. Als er andere beelden en betekenissen gaan meespelen, gaat het mis. Dat vertroebelt onder meer het uiteindelijk beeld van de opdrachtgever.
De architect is gewend aan grote variëteit. Want vooral de architect kan in uiteenlopende situaties komen te verkeren. Maar met toenemende variëteit wordt iedereen in de maatschappij geconfronteerd, dus ook aannemers. Onzekerheid, onvoorspelbaarheid en dergelijke nopen tot flexibiliteit. Daarbij past steeds minder een begrip dat een werkwijze veronderstelt die a priori vastligt. Met groeiende variëteit neemt dus vooral de betekenis af van wat een methode in traditionele zin is. Daarentegen wijst variëteit op de behoefte aan algemeen geldige uitgangspunten, die naar concrete omstandigheden aangepast toepasbaar zijn. Een ander woord voor zulke uitgangspunten is principes.
Sleutelwoorden in de architectuurprincipes blijven uiteraard hetzelfde als bij methoden. Het gaat om oriëntatie op deelnemers aan het veranderingsproces, om hun beeldvorming, om de ontwikkeling van betekenissen, om communicatie. Hiervoor is de benaming principe zelfs geschikter dan methode.
Voor aannemers gelden dan constructieprincipes. Hier belooft overgang van methode naar principe wel wezenlijke verandering. Met duidelijke principes wint de aannemer aan vrijheid tijdens zijn constructiewerkzaamheden. Zolang hij zich aan die principes houdt, is de kwaliteit van het resultaat kennelijk voldoende gewaarborgd. Hoe de aannemer die principes daadwerkelijk effectueert, al dan niet met methoden bijvoorbeeld, is verder zijn eigen zaak. De uitkomst is aan de hand van constructieprincipes voldoende controleerbaar. Een groot voordeel is voorts dat de aannemer via constructieprincipes simpeler aan de opdrachtgever kan uitleggen dat het met de kwaliteit wel goed zit. Hij hoeft de opdrachtgever in zijn uitleg immers niet met details van uitvoering te vermoeien. Ook is met constructieprincipes een compacte taal gevestigd tussen architect en aannemer. Als de architect stipuleert waar de aannemer bepaalde constructieprincipes beslist moet volgen, bestaat daarmee een basis voor kwaliteitsinspectie.
Een voorbeeld van een constructieprincipe werkt wellicht verhelderend. Zoals: Onzichtbare Koppelingen Zijn Verboden. De noodzaak van dit principe is uiteraard meteen helder. Alleen zichtbare koppelingen maken programmatuur (of wat dan ook) fatsoenlijk onderhoudbaar. De consequenties van dit constructieprincipe zijn echter vèrreikend. Er volgt onder meer een verbod op klakkeloze overerving met objecttechnologie uit. En juist overerving vinden vele aannemers thans zo interessant, omdat zij daarmee goedkoper programmatuur kunnen ontwikkelen. Ja, initiële ontwikkeling is wellicht sneller en zodoende in dat stadium goedkoper, ook voor de opdrachtgever als die tenminste een deel van het voordeel krijgt. De rekening wordt echter tijdens onderhoud dubbel en dwars gepresenteerd. Naar verborgen koppelingen kan het lang zoeken zijn, terwijl nooit zeker is of ze allemaal gevonden zijn. Er zijn toepassingen waarbij zo'n risico ontoelaatbaar is. De architect moet zijn opdrachtgever op zulke consequenties wijzen. Doet hij dat goed, dan zal de opdrachtgever in dergelijke opzichten niet op de opdracht aan de aannemer willen bezuinigen. Want uiteindelijk moeten de belangen van opdrachtgever, architect en aannemer natuurlijk parallel lopen.
Opdrachtgevers weten nog onvoldoende de weg naar architecten te vinden. Hoewel op langere termijn ook systeemaannemers belang hebben bij samenwerking, valt op korte termijn niet te verwachten dat zij vrijwillig plaatsmaken voor informatiearchitecten. Extrapolatie levert hun immers veel omzet op. Als er dus iets moet gebeuren, moeten informatiearchitecten dat zèlf doen.
Het ligt voor de hand de organisatiegraad te verbeteren. En dat is in het maatschappelijk verkeer dan weer een stap op weg naar vestiging en verbetering van het imago van de informatiearchitect. Een voordeel hierbij is dat de titel architect wettelijk beschermd is. Dat wil zeggen dat niet iedereen zich zo mag noemen, of het nu een bouwkundig architect, een tuinarchitect of een informatiekundig architect is. De beschermde titel geeft houvast om beroepsbeoefenaren serieus te verzamelen. Wat zijn de criteria waaraan een informatiearchitect moet voldoen? Onlosmakelijk gekoppeld aan een beschermde titel is immers de certificatie van wie de titel mag voeren.
Op de wezenlijke vraag naar criteria geven wij hier geen antwoord. In plaats daarvan beperken wij ons tot een eerste oproep. Wie meent als informatiearchitect te werken, kan zich in de discussie mengen. Wij plaatsen de oproep aan informatiearchitecten overigens met gemengde gevoelens. Het middel van een beschermde titel is immers niet zaligmakend. De geschiedenis van andere beroepsgroepen leert dat meestal reeds de tweede generatie beoefenaren ná verkrijging van formele status het eigenbelang voorop gaat stellen. Het beroep is er dan niet meer om primair opdrachtgevers met hùn problemen te helpen en het vak op een hoger niveau te beoefenen, maar ter optimalistie van de eigen maatschappelijke positie. Hoe blijft een gezond evenwicht behouden nadat noodzakelijkerwijs idealiste eerste generatie de macht binnen de beroepsgroep overdraagt? Voorts zetten wij op voorhand enige vraagtekens omdat juist voor ontwerpers formele criteria voor certificatie problematisch zijn. Criteria staan op gespannen voet met openheid, met creativiteit. Er bestaat pas behoefte aan bijdragen van een (informatiekundig) architect, indien geen voorgekookte oplossing bekend is. Het wezen van ontwerp is vernieuwing. Vanuit deze opvatting zijn a priori criteria tegennatuurlijk.
Kortom, informatiearchitecten staan voor een dilemma. Zonder organisatiegraad blijven zij in isolement verkeren en krijgen minder kans aan kwaliteit van informatievoorziening bij te dragen en de werkelijke crisis te bestrijden. Tegelijk betekent een beroepsvereniging of iets dergelijks met een groot woord verraad tegen de anarchistische instelling waarover de architect grotendeels moet beschikken. Als uitweg kiezen wij voorlopig voor de stelling dat de beroepsvereniging evenzo 'vrij' van vooringenomenheid opgezet moet zijn, als de informatiearchitect idealiter tijdens de uitvoering van zijn opdrachten is. Maar, inderdaad, dan zijn criteria problematisch.
Een kant en klare oplossing voor de optimale samenwerking tussen opdrachtgever, informatiearchitect en systeemaannemer schetsen wij niet. In onze ogen bestaat die oplossing ook niet in standaardformaat. Daarvoor is de variëteit aan opgaven voor informatievoorziening in complexe organisaties en processen te groot. Samenwerking is daarom steeds maatwerk. Alle betrokkenen moeten verder gaan kijken dan hun neus lang is. Daar zien opdrachtgevers en systeemaannemers hopelijk de informatiearchitect staan.
Laat er geen misverstand over bestaan dat ook informatiearchitecten gewoon een boterham willen verdienen. Tegenover elk overdreven idealisme is achterdocht gewettigd. Dat betekent omgekeerd echter allerminst dat een pleidooi vóór de informatiearchitect louter cynisme verdient. Kwaliteit van ontwerp leidt op alle aspecten tot hogere kwaliteit van de resulterende informatievoorziening.
© 1995, webeditie 2002.
Eerder verschenen in: Informatie Management,
1995, nummer 4 en — gedeeltelijk — in: De
informatie-achitect (Kluwer Bedrijfswetenschappen, 1995).