Slim is dom

019-Thumbnail elektriciteit
Toen wij ons huis kochten, was het een opknappertje, zoals dat heet.
En dat niet alleen, we wisten ook al dat er op enthousiaste maar weinig deskundige wijze in was verbouwd.
We waren dus voorzichtig toen we in een van de kamers de stroom er af moesten halen. Niet één, maar diverse stopcontacten controleerden we voordat we ervan uit durfden te gaan dat de elektriciteit werkelijk was uitgeschakeld.
Ja hoor, alles in orde!
We konden aan de slag.
Maar net toen we niet meer op onze hoede waren – TSJAK! – kregen we alsnog een schok.
Een van de stopcontacten, midden in de kamer, bleek niet te zijn aangesloten op de uitgeschakelde groep, maar doorgelust vanuit een stopcontact in de kamer recht eronder.
En terwijl we nog na zaten te sidderen, van de schok en van de schrik, zagen we voor ons geestesoog onze knutselende voorganger, innig tevreden met zichzelf en met zijn oplossing: ‘Slim!’
 
Zulke ‘slimme oplossingen’ zijn helaas niet voorbehouden aan amateuristische huisverbouwers.
Ook in de ICT kom je ze regelmatig tegen.
 
Zo was er het geval van de softwarerelease die, eenmaal in productie, een fout bleek te bevatten. Dat was vervelend voor de gebruikers, maar niet meer dan dat; hinderlijk was een groot woord, blokkerend was niet aan de orde en van een calamiteit was al helemaal geen sprake.
Dat er niet veel aan de hand was, was vooral omdat de betreffende functionaliteit op dat moment nog niet gebruikt hoefde te worden; een aantal weken later zou dat anders zijn. We konden daarom niet op de volgende reguliere release van de software wachten, maar hadden wel de tijd om het probleem netjes op te lossen.
Gelukkig was de leverancier in staat en bereid om binnen twee dagen nieuwe software te leveren waarin de fout zou zijn hersteld. Uitstekend!
Toen we de gebruikersorganisatie daarvan op de hoogte brachten, kregen we al snel een belletje van een danig met zichzelf ingenomen functioneel beheerder. Onze oplossing was niet meer nodig, meldde hij, want twee hele dagen, zo lang kon hij natuurlijk niet wachten. Gelukkig had hij goede contacten bij technisch beheer, dus hij had het allemaal al geregeld.
Allemaal al geregeld?
Ja, wat piefjes en palletjes omgezet in het rekencentrum en alles draaide nu als een zonnetje. Klaar!
Toen onze beller hoorde dat hij de wijzigingen weer terug moest laten draaien, was hij daar bijzonder verontwaardigd over.
Wat nou terugdraaien! Het werkte toch?
Ja, op dat moment wel. Waarschijnlijk.
Maar het was zeer de vraag wat er zou gebeuren bij een toekomstige release van de software of een technische update in het rekencentrum. Zouden de piefjes en palletjes dan nog in de juiste stand staan en de gewenste functionaliteit geven? En zo nee, zou er dan nog iemand weten wat er was gebeurd (over documentatie maken we ons maar helemaal geen illusies)? En daarmee dus ook hoe het ontstane probleem moest worden opgelost?
 
‘Slimme oplossingen’ kun je overal tegenkomen, maar een gebied waar ze zeker welig plegen te tieren is dat van de koppelingen, ofwel de gegevensleveringen tussen applicaties.
Want voor gegevensleveringen moet worden afgestemd.
Niet alleen inhoudelijk – wat wordt er precies geleverd en hoe gaat dat in zijn werk? – maar vooral ook tijdig, zodat de een klaar is om te leveren als de ander wil ontvangen of, andersom, de een klaar is om te ontvangen als de ander moet leveren.
 
Maar ja, afstemming hè.
 
Altijd lastig.
 
Gelukkig is er vaak nog wel een handige oplossing te verzinnen!
En dat resulteert dan bijvoorbeeld in een koppeling waarbij de benodigde gegevens niet worden gehaald uit het eigenlijke bronsysteem (want ja, dat onderhoud je als ICT-er toevallig niet zelf), maar uit een applicatie die ze weer uit dat bronsysteem ontvangt (want die onderhoud je toevallig wel zelf! Wat een mazzel!).
Een doorgeluste gegevenslevering, zeg maar.
Die werkt meestal heus wel, totdat er iets gebeurt.
Totdat bijvoorbeeld het laatst ontvangende systeem extra gegevens wil, die wel in het bronsysteem zitten, maar die het tussenliggende systeem niet nodig heeft.
Of de beide applicaties functioneel een heel verschillende richting op gaan.
Of de tussenliggende applicatie wordt uitgefaseerd, zonder dat  bekend is dat er nog andere software van afhankelijk is. Want dit soort oplossingen wordt meestal niet aan de grote klok gehangen.
 
Als je hier draait en er valt daar met een daverende klap iets om, dan heb je vaak te maken met een ‘slimme oplossing’.
Weliswaar lukte het met die oplossing om snel iets aan de praat te krijgen, maar wel door gebruik te maken van iets dat daar niet voor bedoeld was of door een aanpassing te doen op de verkeerde plek.
En wat heb je dan: een ICT-landmijn.
Zolang zulke potentiële explosieven niet worden geraakt, is er niets aan de hand. Maar op zekere dag wordt er druk op uitgeoefend en voordat iemand het doorheeft gaan ze dan af, met wie weet hoeveel schade tot gevolg.
Het kan jaren duren voordat dat gebeurt – totdat er niemand meer is die nog weet waar ze liggen en hoe ze onschadelijk kunnen worden gemaakt.
Juist dat maakt ze zo riskant.
 
‘Slimme oplossingen’ zijn daarom helemaal niet slim.
Die zijn kortzichtig en ontzettend dom.
 
Dus hoor je om je heen de woorden ‘slim’, ‘handig’ en ‘effe snel’, maar ook termen als ‘pragmatisch’ of ‘oplossingsgericht’, dan zouden al je alarmbellen moeten afgaan.
Je zou zomaar getuige kunnen zijn van de voorbereidingen voor toekomstige ellende.
In dat geval: doe iets!
 
Maar misschien drukken de sprekers in kwestie zich alleen een beetje ongelukkig uit en bedoelen ze eigenlijk ‘intelligent’, ‘goed doordacht’ en ‘elegant’.
Laat ze dan vooral ongestoord doorwerken.
Want dan zijn ze écht slim bezig.
 
019-Elektriciteit

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>