Infrastructuur voor geautomatiseerde informatievoorziening

een beknopte plaatsbepaling

Pieter Wisse

Wat is infrastructuur? In dit geval, wat is infrastructuur voor geautomatiseerde informatievoorziening? Een redelijk, begrijpelijk antwoord op deze vraag is belangrijk om optimaal mogelijkheden van automatisering te benutten en beperkingen ervan te vermijden.

 

 

een brede vergelijking

Iedere vergelijking is gevaarlijk. Maar zolang de aandacht op hoofdlijnen gericht blijft, kan de voorstelling van een bekend verschijnsel licht werpen op wat voorheen nog ˛nbekend was.

Neem het verschijnsel: verkeer. Wie is daarmee niet vertrouwd? En stel dat er een unieke behoefte bestaat om bepaalde goederen niet op lokatie a, maar in plaats daarvan op lokatie b beschikbaar te hebben. Wie die behoefte ÚÚnmalig heeft, kan speciaal dßßrvoor verkeer inrichten. Dat wil zeggen, er moet een vervoermiddel komen. En een weg moet aangelegd worden (of slechts gebaand?) waarover het vervoermiddel bewogen kan worden. Voorts zijn op a en b los-, respectievelijk laadmiddelen nodig. Wie de behoefte nijpend ervaart, heeft er al die moeite voor over. Daar zijn voorbeelden genoeg van.

Voor zo'n unieke behoefte is het niet zinvol om de gezamelijke verkeersmiddelen infrastructuur te noemen. De hulpmiddelen worden eenmalig gebruik, vŔrbruikt dus, en daarmee is de kous af.

Een zinvol begrip 'infrastructuur' komt in beeld zodra hulpmiddelen hŔrgebruikt kunnen worden. Misschien is de bestemming een volgende keer niet b, maar c. Desondanks zouden weleens dezelfde laadmiddelen en hetzelfde vervoermiddel toepasbaar kunnen zijn. Wat nog ontbreekt, zijn dan de weg tussen a en c alsmede de middelen om de lading op c te lossen.

Naarmate dezelfde voorzieningen steeds weer ingezet kunnen worden, is er zinvoller sprake van infrastructuur. Op enig moment bestaat infrastructuur (dus) uit de voorzieningen voor verkeer die op dÓt moment a priori beschikbaar zijn. Bijvoorbeeld, een brug betekent dat voor een auto met zeker gewicht en zekere maten een voorheen bestaande hindernis (water, kloof of iets dergelijks) opgehouden heeft te bestaan.

 

 

gezichtspunten

De paragraaf hierboven maakt duidelijk dat infrastructuur altijd tussenstand binnen een ontwikkeling van voorzieningen/hulpmiddelen is. Wat voor verkeer nog niet a priori aanwezig is, moet per definitie aangevuld worden. Wat als aanvulling geldt, blijkt nu sterk afhankelijk van het gezichtspunt.

Het individu dat met zijn auto van a naar b wil reizen, zal ongetwijfeld wegen, stoplichten enzovoort als infrastructuur voor verkeer erkennen. Het is de vraag of hij zijn 'eigen' voertuig ook daartoe rekent. Waarschijnlijk niet. Als hij met de trein reist, luidt zijn antwoord alweer Ónders. Daar hoort meteen bij dat eigenschappen van de trein-als-infrastructuur als beperkingen ervaren worden.

De burger hecht aan 'zijn' auto. De planoloog heeft een wat andere kijk, tenminste als hij verkeer in het algemeen beschouwt. Zijn aandacht gaat uit naar voorzieningen voor mobiliteit. In die visie verschijnen nu ook de particuliere auto's als behorend tot infrastructuur. Het is een kwestie van beschouwingsniveau. Wat door allerlei individuen als variaties tussen merken en typen auto's opgevat wordt, beweegt zich voor de planoloog immer tussen strakke grenzen van vooral maten en gewichten zodat de auto-als-infrastructuur op andere onderdelen van de infrastructuur (zoals wegen, bruggen enzovoort) afgestemd blijft.

 

 

einde van de vergelijking

Het is tijd met het voorbeeld van verkeer op te houden, althans als een expliciete verwijzing. Zoals iedere, gaat ook deze vergelijking Ŕrgens mank lopen.

Wat de vergelijking hopelijk blijvend meedeelt, is (1) dat infrastructuur een dynamisch begrip is en (2) dat overeenstemming over de inhoud van infrastructuur weleens moeilijk is omdat er evenzovele gezichtspunten kunnen zijn als er betrokken partijen zijn. Dergelijke algemene conclusies gelden eveneens voor het bijzondere geval van infrastructuur voor geautomatiseerde informatievoorziening.

 

 

infrastructuur volgens gebruikers

Een gebruiker stelt zijn particuliere behoeften vˇˇrop. Hieruit volgt dat hij in eerste aanleg nauwelijks 'infrastructuur' ziet. Hij herkent vooral bijzondere hulpmiddelen die 'zijn' behoeften vervullen.

Verkeerd hoeft zo'n houding beslist niet te zijn. Als zijn behoefte inderdaad bijzonder is en/of er is geld genoeg om aparte voorzieningen te treffen, waarom zou er dan een (gemeenschappelijke) infrastructuur moeten zijn?

Anders ligt de zaak wanneer diverse gebruikers elkaar met hun bijzondere voorzieningen in de wielen rijden. De lage autobrug belemmert scheepvaart. En dan is er altijd het feit dat geld slechts ÚÚn maal uitgegeven kan worden. Door schaarste zijn gebruikers eveneens op elkaar aangewezen, hoewel zij dat niet altijd (willen) beseffen.

 

 

infrastructuur volgens co÷rdinatoren

Iemand die co÷rdineert neigt vaak tot een omgekeerde benadering. Dan moet infrastructuur zovÚÚl mogelijk voorzieningen omvatten. En natuurlijk botst hij met zo'n opvatting met gebruikers indien hun behoeften inderdaad bijzonder blijken.

De verstandige co÷rdinator probeert op de hoogte te geraken Ŕn te blijven van de behoeften van Ólle gebruikers waarvoor hij meent dat een (gemeenschappelijke) infrastructuur zinvol is. Het is het probleem van de co÷rdinator, en niet van de diverse gebruikers, dat betrokken partijen verschillend over de inhoud van infrastructuur (kunnen) denken. Daarom moet de co÷rdinator vˇˇrlichten, moet aangeven waar reeds aanwezige voorzieningen een gebruiker helpen zijn behoefte te vervullen. En dit laatste dan eenvoudiger, sneller, goedkoper enzovoort. Infrastructuur moet per saldo toegevoegde waarde voor iedere gebruiker hebben. Het gaat om het saldo zodat alle gebruikers eventuele nadelen accepteren; er staan immers grotere voordelen tegenover.

 

 

basisfouten van co÷rdinatoren

Vele co÷rdinatoren handelen niet verstandig wanneer zij in strijd met hierboven afgeleide conclusies over (de aard van) infrastructuur handelen. Zij ontkennen vaak dat infrastructuur steeds ontwikkelt. In plaats daarvan gaan zij uit van maximale inhoud die zij volgens de stand der techniek mogelijk achten. Het probleem daarmee is niet eens zozeer dat hun ontwerp weleens niet uitvoerbaar zou kunnen zijn, maar dat gebruikers er niets van snappen. Vele co÷rdinatoren ontkennen dus, en dat is dan de tweede grote fout, dat zijzŔlf verantwoordelijk zijn om het verschil in opvattingen over infrastructuur te overbruggen. Dat lukt niet met een eenzijdig voorstel en mobilisatie van hiŰrarchische steun. De wŔrkelijke steun komt altijd van gebruikers die h¨n belangen reŰel erkend zien. Dat is immers de bedoeling van infrastructuur.

De enige manier om realisatie van infrastructuur vooruit te laten lopen op acceptatie ervan door gebruikers, is onafhankelijke financiering. Een visionaire chef wil zo'n weg weleens bewandelen. Een gemachtigd co÷rdinator mag hiervan echter niet afleiden dat contacten met gebruikers overbodig geworden zijn. Integendeel. Als infrastructuur aangelegd wordt om daadwerkelijk te gebruiken, zijn en blijven het de gebruikers waarom het gaat.

 

 

 (in)variantie

De verstandige co÷rdinator definieert een infrastructuur als dynamisch. Hij probeert dan met de (stand van de) infrastructuur steeds voorzieningen aan te bieden die invariant zijn ten opzichte van de eventuele aanvullingen van gebruikers. In gewoon nederlands betekent dit dat een gebruiker (1) enkele voorzieningen kant-en-klaar aantreft, (2) van voorzieningen die hij niet gebruikt ook geen last heeft en (3) minimale inspanningen aan zijn bijzondere, aanvullende voorzieningen behoeft te besteden. Vooral het tweede punt moet de co÷rdinator erop attent maken met infrastructuur niet dˇˇr te schieten.

Afhankelijk van de behoefte van een gebruiker heeft de aanwezige infrastructuur hem nog niets te bieden of juist Ólles, maar waarschijnlijk iets ertussenin. Naarmate de infrastructuur zich gunstig ontwikkelt verschuiven de mogelijkheden voor de gebruiker zich van helemaal niets naar alles. Erdoorheen (tegenin?) speelt uiteraard de ontwikkeling van de behoeften van de gebruiker. Wie mÚÚr wil, vindt niet langer alles kant-en-klaar aanwezig.

Twee voorbeelden kunnen het begrip invariantie toelichten. In de eerste plaats, stel dat er behoefte bestaat om een bijzondere berekening door een centraal opgestelde computer te laten maken. Er is een beeldschermstation en verbinding met die computer. Deze behoefte is invariant ten opzichte van de aanwezige infrastructuur, maar inspanningen voor aanvullende voorzieningen (nota bene het rekenprogramma) kunnen aanzienlijk zijn. Stel ten tweede dat een medewerker automatiseringsmiddelen voor tekstverwerking en electronsche post wil gaan gebruiken. Hij beschikt reeds over de benodigde computer met aansluiting op een netwerk. Zijn behoefte is evenzo invariant als de behoefte uit het eerste voorbeeld. Het verschil zit 'm in de inspanningen die nodig zijn om het effect te bereiken. Invariantie zegt niet dat geen aanvullingen nodig zijn, maar wŔl dat ze gelet op de stand van de infrastructuur onvermijdelijk en minimaal (derde punt van invariantie) zijn en dat (tweede punt van invariantie) infrastructuur tenminste niet contra-produktief is. In het gunstigste geval blijft, zoals gezegd, een gebruiker met het aanbod uit de infrastructuur niets te wensen over. In jargon wil dit zeggen dat hij blijkbaar niets dan (enkele) basisdiensten gebruikt. De dynamische kijk op infrastructuur wijst erop dat steeds uitgebreid kan worden wat dergelijke basisdiensten zijn. Nu gaat het om tekstverwerking, electronische post, programmatuur voor zgn. spread-sheets en dergelijke. Als de berekening uit het eerste voorbeeld in een spread-sheet past is er de situatie dat de behoefte eveneens geheel door reeds aanwezige infrastructuur gedekt is.

 

 

evenwichtig beheer

Een begin van infrastructuur blijkt vaak achteraf benoembaar. Dat is een begin om Ŕrgens in lokale behoeften te voorzien. In een later stadium van ontwikkeling draait de oriŰntatie om. In plaats van een agglomeraat van afzonderlijk gegroeide voorzieningen wordt infrastructuur qua opzet eerst geco÷rdineerd en ontworpen en pas vervolgens gerealiseerd.

Omdat het begrip infrastructuur meestal nß zo'n heroriŰntatie ter spake komt, wordt het geassocieerd met centralisatie. Het woord co÷rdinatie zegt het reeds; een volwassen infrastructuur heeft centralistische trekjes. Dat is onvermijdelijk omdat belangen van diverse gebruikers afgewogen (moeten) zijn. Centralisatie vermindert wanneer de gebruikers zŔlf de afwegingen maken of tenminste erover beslissen. Dit is soms moeilijk te realiseren omdat gebruikers denken dat infrastructuur een 'technisch' onderwerp is en dat zij 'het' beter aan specialisten kunnen overlaten. Dat is een drogreden. Hun eigen belang loopt gevaar als zij afzijdig blijven. In zoverre is het nodig dat gebruikers op de hoogte zijn van de basisfouten die co÷rdinatoren met infrastructuur kunnen begaan. Zij moeten er terdege op letten dat infrastructuur op h¨n eigen (ontwikkelende) behoeften afgestemd is en blijft. Dat is evenwicht, te weten het resultaat van Ólle nodige inbreng.

Er dreigt nog een derde fout die co÷rdinatoren dikwijls maken. Zij menen dat een infrastructuur slechts aangelegd behoeft te worden. Daarmee zou alles klaar zijn. Ook nu is niets minder waar. Aanleggen is ÚÚn, functioneren is twee.

Gebruikers ondervinden pas toegevoegde waarde van een infrastructuur als het functionerende voorzieningen zijn. Er is onderhoud, beheer nodig om infrastructuur functionerend te houden.

Geheel in lijn met centralistische ideeŰn over infrastructuur geven vele co÷rdinatoren de voorkeur aan een centrale beheerorganisatie. Dßßr kan de nodige expertise gewaarborgd zijn, is de redenering. Welnu, dat is een beetje waar. Maar ˇˇk waar is dat gebruikers vervreemd raken van helpers die er misschien wel zijn, maar die niemand weet te vinden en die evenmin zŔlf op hun 'rondjes' gebruikers opzoeken. Evenwichtig beheer betekent voor ieder onderdeel van infrastructuur een aangepaste keuze tussen noodzakelijke expertise en optimale contactmogelijkheid met gebruikers. Voor vele, zo niet de meeste onderdelen van infrastructuur geldt dan dat beheerders/helpers niet centraal, maar juist decentraal opgesteld moeten zijn. Interessant is dat belangrijke decentralisatie van beheer absoluut niet inhoudt dat er mÚÚr medewerkers voor nodig zijn. Want zoals overal geldt ook voor geautomatiseerde informatievoorziening dat oplossing het minste werk vergt wanneer het probleem zo vroeg mogelijk gesignaleerd is. Zelfs vele problemen kunnen Řberhaupt vermeden worden met preventieve aandacht, en dat is aandacht op de plek waar problemen eventueel zouden kunnen optreden. Voor problemen die gebruikers veroorzaken is die plek dus .... bij de gebruikers.

Een voordeel van decentrale beheerders is voorts dat dynamiek van infrastructuur tot gelding kan komen. De gebruiker die 'zijn' beheerder vertrouwd, laat zich door hem voorlichten Ŕn, omgekeerd, deelt hem eerder mee hoe hij over informatievoorziening van a tot z denkt. Dit laatste is onmisbare informatie voor co÷rdinatie. De enige nuttige plaats van infrastructuur bestaat er immers uit in reŰle behoeften van gebruikers te voorzien.

 

 

ę januari 1992, webeditie 2002.