Database Magazine Blog http://www.dbm.nl Database Magazine Blogs RSS (c) Array Publications <![CDATA[IJdele Mannen]]> Deze column gaat over een menselijk ICT-onderwerp: mijzelf. U moet weten dat ik recent 50 ben geworden, een leeftijd die voor veel mensen de scheidslijn vormt tussen ‘middelbaar’ en ‘plus’. De kalende, grijzende maffia waartoe ik nu behoor heeft speciale bladen en zelfs een politieke partij. Natuurlijk heb ik als rationele hardcore ICT’er niets met het arbitraire getal 50. Dat 50 toch bijzonder is komt door een stelling van mijn hoogleraar organisatiekunde van destijds. Prof. Twijnstra (inderdaad, van Twijnstra Gudde) vond dat leidinggevenden zouden moeten terugtreden op hun 50e en dan gaan vissen of hoogleraar worden. 50 plussers zouden volgens Twijnstra onvoldoende creatief en wendbaar zijn om leiding te geven aan veranderingen. De met de jaren toenemende ervaring en het toenemende vermogen om parallellen te zien tussen heden en verleden zouden de algehele geestelijke aftakeling niet compenseren, dixit de toen 60-jarige Prof. Twijnstra.

Ondanks mijn toenmalige respect voor autoriteit beschouwde ik Twijnstra’s stelling als een ego-statement van een ijdele ex-ondernemer op zoek naar zingeving in de luwte van het onderwijs. Toen ik afstudeerde wist ik dankzij het uitstekende organisatiekundige onderwijs dat ik had genoten zeker dat Twijnstra’s uitspraak een onzinnige overgeneralisatie was. De optimale leeftijd van een leidinggevende wordt, los van diens persoonlijke eigenschappen, primair bepaald door de mate en de aard van de veranderlijkheid van de bedrijfsomgeving. Een gezonde paus van 80 kan er best mee door, maar voor een ondernemer in de social media is 40 zonder meer oud. En naarmate een markt meer of minder veranderlijk wordt verschuift ook de optimale leeftijd van de leidinggevenden. Je kunt dat zelfs omdraaien: als de (top)managers in een bepaalde markt gemiddeld jonger worden is dat een aanwijzing dat de turbulentie in die markt toeneemt – en omgekeerd. Oudere managers zijn gemiddeld betere beheerders en saneerders. Jongere managers zijn beter in staat om fundamentele veranderingen het hoofd te bieden. Elke markt, elk bedrijf, elke afdeling heeft zijn eigen optimum.

De 50-jarige leeftijd bereiken is, terugdenkend aan de lessen uit mijn studietijd, toch een aardig moment om eens naar mijzelf als kleine ICT-ondernemer te kijken in de markt waarin ik mijn brood verdien. Allereerst blijkt dan veel van wat er wordt beweerd over de plusleeftijd waar: geestelijke vermogens zoals het geheugen worden bijvoorbeeld minder en het echte buffelen gaat ook niet meer zo goed als vroeger. Het klopt ook dat erecties langer aanhouden, maar dat terzijde. Wat echter op het eerste gezicht heel bijzonder is, is dat ik het gevoel heb steeds effectiever te worden in het oplossen van problemen en het herkennen van situaties op basis van eerdere ervaringen en redeneringen vanuit analogieën. Ik zeg dat niet om op te scheppen. Nee, het zegt iets over de markt waarin mijn bedrijf en ikzelf opereren. Die markt zit kennelijk dichter bij het Vaticaan dan bij Facebook. Ik vind dat triest voor de markt maar fijn voor mijzelf. Heel fijn zelfs, want ik beweer al sinds vele jaren in dit blad dat de technologische vooruitgang op het gebied van administratieve systeemontwikkeling schijn is en dat er zelfs sprake is van achteruitgang in technologie en menselijk kapitaal. De markt waarin ik opereer takelt kennelijk sneller af dan ikzelf. Mijn persoonlijke intellectuele tragiek en tegelijk mijn economische geluk is dat op mijn specialisme de wetenschappelijke ontwikkelingen nagenoeg stilstaan en de praktijk achteruit holt. Om met Liberace te spreken: “I cry all the way to the bank”.

Wat dan nog resteert is de ultieme zelfrespecttest: “Weet ik meer van mijn specialisme dan vroeger? Kan ik nog wezenlijk nieuwe ideeën ontwikkelen?” Tot mijn oprechte verbazing is het antwoord vooralsnog tweemaal “ja”. Ja, ik weet enorm veel meer van database-ontwerp dan ten tijde van mijn promotieonderzoek als jonge dertiger en zeker meer dan waarover ik sindsdien in dit blad heb gepubliceerd. En wat nog gekker is: het vermogen om werkelijk nieuwe ideeën uit te werken en te realiseren neemt vooralsnog alleen maar toe, al moet ik zeggen dat ik in mijn briljante collega Frido van Orden (een jonge 40’er) over een stevige intellectuele rollator beschik. Ik hoop de komende jaren in dit blad en bij mijn opdrachtgevers te laten zien waartoe een agile 50’er in een stagnerende markt in staat is. Godzijdank zit ik niet in de social media (en ben ik geen paus).

Voordat ik aan deze column begon heb ik Prof. Twijnstra even gewikipediaad. Twijnstra is overleden in 2007, op 85-jarige leeftijd. Ik lees met een sardonische grijns dat hij op zijn 55e moest terugtreden als topman van Twijnstra Gudde vanwege zijn dwaze stelling en dat hij daar later als hoogleraar grote spijt van had. Dat Twijnstra zijn stelling als hoogleraar is blijven uitdragen lijkt mij de ultieme consequentie van een teveel aan ijdelheid en zelfingenomenheid. Dank u, professor Twijnstra, voor deze les. Ik ben een gewaarschuwd mens.

Deze column verscheen eerder in Database Magazine 4-2011

]]> Mon, 27 Jun 2011 14:33:15 GMT <![CDATA[ACID is niet heilig meer]]> Al tijdens mijn studie, een lange, lange tijd geleden, werd mij geleerd wat een transactie was. In het dikke boek van, wie anders, Chris J. Date getiteld ‘Introduction to Database Systems’ werd uitgelegd dat een transactie uit een aantal database-operaties bestond, zoals insert, update en delete, die allemaal al dan niet uitgevoerd moesten worden. En hier mocht niet mee gesjoemeld worden. En een transactie was pas een transactie als het aan enkele eigenschappen voldeed. Deze vier eigenschappen werden en worden met de afkorting ACID aangeduid. Later meer daar over. Elke zichzelf respecterende database server hoorde dit te ondersteunen. Punt.

De laatste jaren verschijnen er echter steeds meer database servers die wel transacties ondersteunen, maar die niet van ACID uitgaan. Tijdens mijn studie zou dit gelijk hebben gestaan aan vloeken in de kerk. Toch hebben de leveranciers hier een reden voor. Maar laten we bij het begin beginnen.

Waar staat de afkorting ACID ook al weer voor? A(tomicity) betekent dat als een transactie uit enkele database-operaties bestaat én als de database server aangeeft dat de transactie correct verwerkt is, dat alle of geen database-operaties verwerkt zijn. Met C(onsistency) wordt bedoeld dat na het uitvoeren van een transactie de database zich in een correcte toestand moet bevinden. I(solated) wil zeggen dat transacties geïsoleerd uitgevoerd moeten worden. Het mag niet zo zijn dat applicaties elkaars tussenresultaten kunnen zien. Tenslotte, D(urability) heeft te maken met dat het effect van een eenmaal afgeronde transactie permanent moet blijven; ook al gebeuren er rampen zoals het down gaan van de database server, de database-operaties moeten na herstel nog steeds zichtbaar zijn.

Bekende SQL database servers, zoals die van IBM, Microsoft en Oracle, ondersteunen allemaal ACID-transacties. Maar nieuwe database servers als CloudDB en MongoDB niet. Dit heeft alles te maken met schaalbaarheid.

Volgens de Amerikaanse professor Eric A. Brewer willen we allemaal van een database server een zo hoog mogelijk niveau van consistentie, schaalbaarheid en partitietolerantie. Perfecte partititietolerantie wil zeggen dat het systeem pas down is als alle netwerkpartities down zijn. Volgens Brewer bestaan er echter afhankelijkheden tussen deze drie eigenschappen. We kunnen maar twee van de drie eigenschappen verhogen. Dit wordt door hem het CAP (Consistency Availabality Partition Tolerance) principe genoemd. Bijvoorbeeld als we de consistentie van een database server verhogen, verlagen we daarmee waarschijnlijk de schaalbaarheid. Kortom, verhoog je er een, dan verlaag je een ander.

Het zijn vooral consistentie en schaalbaarheid die elkaar in de weg zitten. Bijvoorbeeld, als een database server ACID-transacties ondersteunt, kunnen applicaties elkaar blokkeren en dat kan ertoe leiden dat ze op elkaar gaan wachten. Tevens leidt het tot veel interne administratie voor een database server. Beide kunnen ertoe leiden dat een database server niet de schaalbaarheid haalt die een organisatie nodig heeft. Een oplossing zou dan kunnen zijn dat zo’n organisatie voor een database server kiest die wel de benodigde schaalbaarheid biedt, maar qua transacties wat water bij de wijn doet.

MongoDB van 10gen doet inderdaad water bij de wijn. Hier heeft de ontwikkelaar de keuze wat het consistentieniveau van transacties moet zijn. Er kan bijvoorbeeld aangegeven worden dat de mutaties alleen in het geheugen verwerkt moeten worden en pas later ook op disk. Als er in die tussentijd iets fout gaat, kan die transactie wel verloren gaan. Maar als dat niet het geval is, kunnen er zeer veel transacties per tijdseenheid verwerkt worden. Dus door het consistentieniveau iets te verlagen, kan de schaalbaarheid verhoogd worden. Het blijven dus wel transacties, alleen zijn het geen ACID-transacties meer. Het consistentieniveau is dus verlaagd.

Laten we eerlijk zijn, het is geen ramp als we in bepaalde omgevingen één of enkele transacties verliezen. Neem bijvoorbeeld een applicatie die al het verkeer op een website naar een tabel in een database schrijft. Stel dat er gemiddeld per dag ongeveer tien van deze schrijfoperaties verloren gaan. Is dat echt een ramp? Ik denk het niet.

Sommige omgevingen, zoals bijvoorbeeld de financiële wereld, hebben absoluut ACID-transacties nodig. Maar dit geldt niet voor alle omgevingen. Als we de schaalbaarheid naar een gewenst niveau kunnen verhogen door de consistentie te verlagen, dan is dit wellicht een prima oplossing. Kortom, als ontwerpers moeten we ACID dus niet meer als een gegeven zien, maar als een ontwerpbeslissing. Het wordt tijd dat Chris Date zijn boek hierop gaat aanpassen.
 

]]> Mon, 27 Jun 2011 14:29:14 GMT <![CDATA[Een nieuwe categorie BI-producten?]]> Jaren geleden waren gebruikers blij als ze een simpel rapport op hun monitor of PC konden opvragen. Maar al snel bleek dat niet voldoende. Gebruikers wilden over OLAP-mogelijkheden beschikken om dynamisch gegevens te bestuderen, ze hadden hun zinnen gezet op het maken van complexe statistische modellen om de toekomst te voorspellen en ook moesten er dashboards komen die inzicht zouden geven in de bedrijfs-processen. Het effect is dat er nu veel categorieën BI-producten bestaan waarmee gebruikers de gegevens kunnen bestuderen.

Het lijkt alsof we er een nieuwe categorie bij krijgen, de zogenaamde data discovery producten; ook wel data exploration producten genoemd. Bij veel van de andere categorieën zijn de gebruikers, voor wat betreft het stellen van vragen, beperkt door de structuren in de data en door de gedefinieerde relaties tussen tabellen. Bijvoorbeeld, als de technici zich niet gerealiseerd hebben dat de gebruikers op een bepaalde manier van de ene naar de andere tabel willen navigeren, dan zal het ook nage¬noeg onmogelijk zijn voor de gebruikers om dit pad te volgen.

Data discovery producten staan gebruikers volledig vrij door de gegevens heen te navigeren zonder enkele beperking. Relaties kunnen gelegd worden waar de technici niet aan gedacht heb¬ben. Dit soort functionaliteit is uitermate handig voor die proble¬men waarvan het initieel niet duidelijk is waar het antwoord gezocht moet worden. Als we bijvoorbeeld willen weten hoe de omzet er de laatste maanden uitzag, dan weten we welke tabel¬len we moeten benaderen en hoe. Maar wat als we weten dat er een probleem is, maar we geen idee hebben van wat de oorzaak is? Stel bijvoorbeeld dat de uitval in een fabriek aan het toenemen is en we willen weten waarom. Waar ligt dan het probleem? Afnemende kwaliteit van de aangeleverde grondstof¬fen? Bepaalde machines die vaker in de fout gaan? Minder ervaring bij de werknemers die de machines bedienen? Of wat als de verkoop van bepaalde producten in een regio tegenvalt? Is de toelevering van nieuwe producten te traag? Is er misschien een staking geweest? Is het weer zo slecht dat potentiële klanten amper hun huis uitkomen?
De intentie van data discovery producten is dat gebruikers vrij vragen mogen stellen. Er zijn nagenoeg geen beperkingen wat betreft het stellen van vragen. Samen vormen deze producten echter geen homogene verzameling producten, zoals alle SQL databaseservers dat wel doen. Ze proberen het allemaal op hun eigen wijze op te lossen.
Een interessant data discovery product is iCorrelate van illumi¬nate. Dit product biedt de gebruiker een simpele grafische inter¬face waarmee vrij vragen gesteld kunnen worden. Bijvoorbeeld, in iCorrelate kunnen we de vraag stellen: Zoek Rotterdam. Het antwoord zal bestaan uit alle records uit alle tabellen waar ergens het woord Rotterdam in voorkomt. Hierna kan gevraagd worden welke records dan te maken hebben met klant Jansen. Het antwoord kan klachten van deze klant bevatten, maar
ook bestellingen en facturen. Het product gaat hierbij uit van een dialoog; gebruikers kunnen vragen stellen op antwoorden van voorgaande vragen. iCorrelate onthoudt alle antwoorden in een sessie.
Kortom, de gebruiker kan vrij door de database heen wandelen, zonder dat ook maar één relatie vooraf gedefinieerd is.

Een geheel ander product is I.Know van InterSystems. Puur door middel van tekstanalyse kunnen gebruikers vrij tekst op een gestructureerde manier bestuderen en analyseren. Een derde die ik hier wil noemen is Exalead. Dit product zet search-tech¬nologie en natuurlijke taal in om gebruikers vrij te laten zoeken. Gebruikers kunnen vrij data in gestructureerde bronnen combi¬neren met data in ongestructureerde bronnen.
Er zullen ongetwijfeld nog meer producten bestaan die tot deze categorie behoren en er zullen er nog diverse verschijnen, want de categorie begint ‘hot’ te worden. Zeker nu Gartner erover publiceert. Als u zich hier nog niet in verdiept hebt, kan ik het wel aanraden. Data discovery of data exploration is een waarde¬volle aanwinst voor de Business Intelligence wereld.

Opmerking: Verwar data discovery niet met de term knowledge discovery. Laatstgenoemde term wordt momenteel in de BI-wereld niet veel meer gebruikt, maar enkele jaren geleden wel. Het werd toen gebruikt als een alternatief voor data mining.

Deze column verscheen eerder in Database Magazine 3-2011.

 

]]> Wed, 11 May 2011 15:55:18 GMT <![CDATA[Spookburgers en Hinkende Huwelijken]]> “Als u deze column leest weten we hopelijk meer.” Zo eindigde ik mijn vorige column over de strijd om persoonsgegevens tussen Amsterdam en het UWV. Sindsdien heeft RTL de Nederlandse taal verrijkt met het woord ‘spookburger’, waarvan er 400.000 zouden rondlopen. De spookburger staat bij de gemeente geregistreerd als ‘VOW’: Vertrokken Onbekend Waarheen. De spookburger komt niet uit Amsterdam maar uit Rotterdam, waar een initiatiefrijke ambtenaar dossiers van ondergedoken uitkeringstrekkers handmatig tegen de Polisadministratie heeft aangehouden. En ja hoor, horden VOW’ers zijn ergens legaal aan het werk. Hun werkgevers melden maandelijks aan UWV waar deze administratieve Swiebertjes woonachtig zijn en die gegevens zijn gewoon te raadplegen door tienduizenden ambtenaren en incassojagers. En nu is de Tweede Kamer functioneel boos. Het laatste gerucht is dat Amsterdam straks 5.000 gevallen gaat krijgen die volgens UWV “verdacht” zijn. Waarom de andere 126.000 [!] Amsterdamse gevallen niet verdacht zijn blijft onduidelijk maar het is een begin. Ook jammer is dat er allerlei onzin wordt ver¬teld. Zo meldt RTL in een heuse handleiding voor spookburgers dat spookburgers niet worden belaagd door incassobureaus. Niets van waar: zo moeilijk als UWV het de gemeenten maakt, zo gemakkelijk kunnen incassobureaus de Polisadministratie leegtrekken. En dat gebeurt ook: dit jaar worden er op de Polisadministratie 1.200.000 (één-komma-twee miljoen!) opvra¬gingen voor loonbeslag gedaan. En alles helemaal gratis en bijna controlevrij! Recent kreeg ik zelf een aankondiging van loonbeslag binnen voor de meneer van wie ik mijn huis heb gekocht. Die pensioneert in Spanje, maar omdat hij de water¬schapsheffing niet heeft betaald wordt binnenkort zijn pensioen gekort. En dat geldt dus net zo hard voor al die andere spook-burgers die wel in de Polisadministratie zitten. Allemaal onzin dus. Maar het is oorlog en oorlogen worden gevoerd in de mist. Het vergt misschien nog jaren van inter-ambtelijk geziek in Q-koorts stijl, maar de geest lijkt uit de fles: de gemeenten gaan met persoonsgegevens van andere overheden hun bevolkings¬administratie serieus verbeteren.
Als ICT’er word ik vooral zo blij van wat er nu gebeurt omdat het idee van basisregistraties weer iets verder van de grond komt. Er komt hopelijk een dag dat de overheid mijn persoons¬gegevens maar op één plek bijhoudt. Die plek is niet bij de Belastingdienst, het UWV of, godforbid, de politie maar de bevolkingsadministratie (GBA). Het ideaal van één waarheid in één systeem komt zo weer een beetje dichterbij. Alhoewel … daarvoor moet eerst de GBA worden gemoderniseerd. Pas dan kunnen die miljoen mensen met een Sofinummer worden vast¬gelegd als ‘niet ingezetene’. Pas dan ook komt er een einde aan de situatie waarin de lokale gemeentelijke GBA databases die elkaar vaak tegenspreken zijn vervangen door één landelijk dekkende centrale administratie, de Basisregistratie Personen (BRP). Er loopt nu een groot programma om deze BRP van de grond te tillen (www.moderniseringgba.nl). Dat is alweer de vierde poging in tien jaar tijd, maar gelukkig is viermaal scheepsrecht. En dus kunnen over een paar jaar 418 gemeenten hun lokale waarheden gaan samenvoegen tot één Nationale waarheid. Als het zover komt dan wordt deze supermerge een enorme uitdaging. Maar vóór het zover is moet er nog even een centrale database worden ontworpen en geïmplementeerd. En daarbij zou best eens kunnen blijken dat het hele idee dat er één waarheid bestaat niet klopt. Ja dat klinkt gek en dus geef ik twee voorbeelden uit vele. Stel, u verhuist en meldt dat twee weken van tevoren netjes bij de gemeente. De ambtenaar regis¬treert dan uw verhuizing op de door u opgegeven datum. Gaat u twee dagen na uw verhuizing bij het loket langs dan wordt dat feit als terugwerkende kracht mutatie vastgelegd. Tot zover geen probleem. Maar stel dat u door vergeetachtigheid drie weken te laat uw verhuizing komt melden dan wordt automa¬tisch vastgelegd dat u vandaag bent verhuisd. De dag waarop u echt bent verhuisd mag uitdrukkelijk niet worden geregistreerd. Creepy? Een ander, grappiger voorbeeld is dat van het zoge¬naamde hinkende huwelijk. Het is nu door de fragmentatie van lokale GBA’s mogelijk dat iemand bij de ene gemeente staat geregistreerd als gehuwd en bij de andere als ongehuwd. Typisch zo’n anomalie die bij een centrale database verdwijnt. Niet dus. In de centrale BRP moeten de verschillende lokale waarheden gewoon geregistreerd blijven. Die BRP wordt daar¬mee een van de meest uitdagende databases om te ontwerpen en integer te krijgen: véél ingewikkelder dan al die andere over¬heidssystemen die falen omdat de complexiteit de ontwerpers boven het hoofd groeit. Het staat as we speak natuurlijk nog maar te bezien of de vierde poging om de GBA te moderniseren wel gaat lukken. Maar als het resultaat is dat de juridische realiteit boven de werkelijkheid gaat, dan is misschien straks de slag om de persoonsgegevens gewonnen maar de oorlog om de basisregistraties verloren. Wordt vervolgd.

Deze column verscheen eerder in Database Magazine 3-2011.
 
 

]]> Wed, 11 May 2011 15:43:55 GMT <![CDATA[Oorlog om persoonsgegevens deel 2]]> De Gemeente Amsterdam heeft inmiddels genadeloos toegeslagen en daarmee meteen het beeld rechtgezet dat zij door eigen schuld hun administratie niet op orde hebben:

RTL-nieuws link 1 

RTL-nieuws link 2

RTL-nieuws link 3 

En dan hebben ze alleen maar de categorie "spookburgers" besproken. RTL kan met de andere categorieen ook nog een week lang het journaal vullen.
Trots om een kleine bijdrage aan de discussie te hebben mogen leveren.

RV

]]> Thu, 31 Mar 2011 12:06:10 GMT <![CDATA[Oorlog om persoonsgegevens]]> Maar toen kwam er een nieuwe burgemeester (Job – rooibosthee – Cohen) en een nieuwe DPG chef. Iedere gemeentelijke dienst die persoonsgegevens registreert haalt deze nu verplicht uit de bevolkingsadministratie, dus geen aparte adresjes meer voor de bijstandsuitkering en de parkeervergunning. En DPG neemt ook niet zomaar genoegen met wat de burger zegt. Het gevolg is een enorme kwaliteitsverbetering van de bevolkings­registratie. Ik begrijp dat een van de grotere problemen nu is dat mensen hun kinderen op een ander adres inschrijven om ze op een witte school te krijgen. Tja.
Ergens eind 2009 las een gemeenteambtenaar een artikel in DB/M over de Polisadministratie waarin werd gemeld dat dit systeem de persoonsgegevens bevat van 14 miljoen mensen, waaronder zo’n 600.000 die helemaal niet in de bevolkingsadministratie voorkomen. Tel er de kinderen bij en je hebt zomaar een miljoen mensen die we in Nederland administratief niet kennen – toch wel gênant voor een ontwikkeld land. We hebben het hier over legal aliens die van de Belastingdienst een sofinummer hebben gekregen, maar de Belastingdienst is …, euhhh …, nogal gesloten. De alerte ambtenaar tipte de baas van DPG die daarna aan UWV vroeg om eens te kijken hoeveel
verschillen er waren tussen de bevolkingsadministratie en de Polisadministratie. Een dag later lagen de cijfers op tafel: circa 60.000 onbekenden en nog eens circa 30.000 mensen die volgens hun werkgever ergens anders wonen dan ze de gemeente hadden wijsgemaakt. Vreugde bij de gemeente die wéér een slag kon maken in het verbeteren van de bevolkingsadministratie. Vreugde ook bij deze columnist die als gegevensarchitect, burger en belastingbetaler zijn zorg had uitgesproken over het verschijnsel dat UWV en Belastingdienst feitelijk bezig waren om een soort eigen bevolkingsadministratie op te zetten en dit diplomatiek had aangeduid als een ‘lekkende hartklep’.
U begrijpt hoe het verder liep: UWV leverde Amsterdam de 90.000 ontbrekende c.q. afwijkende personen. De gemeente sloeg een enorme slag richting boefjes en fraudeurs en betaalde daarmee het gat van de Noord-Zuidlijn. Ook werden achttien voortvluchtige Engelse criminelen thuis opgepakt, want Amsterdam is voor Engelsen dé plek om onder te duiken tussen 3.500 ongeregistreerde landgenoten in Amsterdam. En uw columnist kreeg natuurlijk een lintje.
Nou, niet dus. Wat er wel gebeurde was een escalerende ambtelijke strijd tussen Amsterdam enerzijds en UWV en Belasting­dienst anderzijds. Waarom weet ik niet, maar werkelijk alles werd door deze organisaties uit de kast getrokken om de persoonsgegevens onder zich te houden. Vlak voor de deadline van deze column werd de strijd opeens zichtbaar toen verontruste Kamerleden van PvdA en CDA lastige kamervragen begonnen te stellen. En laat de nieuwe minister van Binnenlandse Zaken, Mr. J.P.H. Donner, nou tot voor kort verantwoordelijk zijn geweest voor het UWV. Dat komt dus wel goed, zou je zeggen; helemaal nadat De Telegraaf een voorpagina-artikel aan het gedoe wijdde. Jammer genoeg dacht de wakkere krant dat UWV alleen uitkeringstrekkers kent en dus ging het verhaal over 30.000 frauderende Mokumse uitkeringstrekkers. Vervolgens ging Geenstijl er nog even overheen om het beeld van een incompetente, verspillende, rooibosthee drinkende, linksdragende gemeente nog even te onderstrepen. FAIL natuurlijk. Maar als niemand deze persprietpraat corrigeert blijft het beeld overeind dat er een probleem is bij Amsterdam in plaats van bij UWV. Het staat dus nog maar te bezien hoe de oorlog om de persoonsgegevens gaat aflopen. Wie hart heeft voor zaken als een betere en kleinere overheid en/of privacy moet hopen dat Amsterdam het pleit gaat winnen. Maar dit is Nederland.
Als u deze column leest weten we hopelijk meer.

Deze column verscheen eerder in Database Magazine 2-2011

]]> Tue, 22 Mar 2011 11:06:25 GMT <![CDATA[Wat drijft de IT-specialist?]]> Hier en daar lopen IT-projecten nog wel eens fout. Het ene project blijkt wat duurder te zijn dan gepland, een ander duurt veel langer dan verwacht en een derde levert geheel niets op. Vreemd, want in de afgelopen dertig jaar zijn heel wat nieuwe technologieën en technieken zoals SOA, OO, MDM, NoSQL, Cloud en CBD geïntroduceerd die allemaal beloofden dat alle problemen als sneeuw voor de zon zouden verdwijnen.
Zijn falende projecten moeilijk te vinden? Niet echt. Tik maar eens bij Google in ‘mislukt IT project’. Je vindt dan al snel een forse lijst, zoals het ministerie van VROM dat eind 2007 het automatiseringsproject VIDI staakte. De teller stond toen al op 16,6 miljoen euro. In juni 2008 blies het UWV een grootschalig ICT-project af ter waarde van 80 miljoen euro. In 2008 en 2009 schreef Bankier Van Lanschot 55 miljoen af op een mislukte modernisatie van de back-office systemen. En in 2010 stopt het Belgisch ministerie van Justitie met de ontwikkeling van het nieuwe gevangenissysteem Cajis, waaraan al 12 miljoen euro was uitgegeven. Als u grotere bedragen wilt zien, ga dan naar spectrum.ieee.org/computing/software/why-software-fails.
Maar waarom lopen IT-projecten soms zo glansrijk fout? Wie is schuldig? Zijn het de gebruikers, onze producten, slecht gespecificeerde gebruikerswensen, veranderende wensen, of managementtechnieken? In het boek Crash, ten easy ways to avoid a computer disaster geeft Tony Collins elf redenen waarom projecten mislukken.
Eigenaardig genoeg wordt zelden gewezen naar ons, de specialisten. Wij doen dat in ieder geval niet. Zou het niet nuttig zijn als wij onszelf eens aandachtig in de spiegel bestuderen? Mijn mening is dat als we kritisch naar onszelf kijken, we kunnen concluderen dat een aantal principes ons leidt. Die principes zouden ook wel eens de reden kunnen zijn van het falen van een project.
Specify-once. Er is een sterke neiging om systemen te ontwikkelen waarbij elke specificatie maar één keer wordt ingevoerd (en uiteraard meerdere keren gebruikt). Het grote voordeel hiervan is dat als de specificatie aangepast moet worden, dat maar op één plek hoeft te gebeuren. Maar is er wel eens uitgerekend wat de kosten en baten hiervan zijn? Krijgen we hierdoor niet teveel afhankelijkheden en een inflexibel systeem? Het hele idee is trouwens een idee-fixe, want de organisatie hoeft maar te fuseren en we hebben weer overal duplicaten.
Tool-addiction. Veel specialisten hebben hun favoriete ontwikkeltalen, producten, methoden. Veel zijn er zelfs aan verslaafd. Zij zullen altijd proberen welk probleem dan ook met hun favoriete speeltje op te lossen. Ik weet zeker dat dit ook tot mislukkingen kan leiden, puur omdat het verkeerde product is ingezet.
Free-of-charge. Vaak weten wij niet wat de kosten van een technische oplossing zijn. Vraag maar eens aan honderd BI-specialisten wat een datamart ongeveer kost. De meesten
hebben geen idee, zelfs de bouwers niet. Toch nemen we dagelijks architecturale en ontwerpbeslissingen die enorme financiële consequenties hebben. Maar daar kijken we amper naar. Alsof er aan een oplossing geen prijskaartje hangt.
Performance-dictates. Veel argumenten om een bepaalde oplossing te verdedigen worden vaak van de tafel geveegd als het gevoel bestaat dat het ten koste van de performance gaat. Performance is heilig. Alles moet hiervoor wijken. Maar weet de organisatie wat de prijs is die zij moet betalen om die snellere oplossing te krijgen? Specialisten kiezen altijd voor de snelste oplossing, maar maken het daardoor soms onnodig duur. Zouden ze dat thuis ook doen?
Hype-sensitivity. Het is u waarschijnlijk al opgevallen: we willen vaak direct de nieuwste technologie inzetten. Maar dat brengt risico’s met zich mee. Hoelang iets duurt en hoeveel het gaat kosten, is meestal niet goed duidelijk, want eerst moet er ervaring opgebouwd worden.
Wat ik met deze column niet wil zeggen, is dat IT-specialisten altijd de schuldigen zijn, maar dat we eerlijk moeten zijn en moeten toegeven dat wij wel ons steentje bijdragen. Laten we eens beginnen ons eerst wat bewuster te worden van de bovengenoemde principes. Misschien moeten we aan sommige daarvan iets minder waarde schenken. Het hoeft niet altijd met een nieuw product, het hoeft niet altijd de snelste oplossing te zijn, en het hoeft niet altijd de mooiste oplossing zijn. Goed is vaak goed genoeg.

Deze column verscheen eerder in Database Magazine 2-2011

 

]]> Tue, 22 Mar 2011 11:03:45 GMT <![CDATA[Niemand wil een datawarehouse]]>  

Op mijn bureau in ons kantoor staat, net als bij velen, een telefoontoestel. Hiermee kan ik bellen naar onder andere klanten en collega’s. Deze telefoon zit met een snoer vast aan een of ander stopcontact dat aan de muur is vastgeschroefd. Hoe daarna verder alle techniek werkt, dat weet ik niet en ik ben er ook niet in geïnteresseerd. Of er vanuit het kantoorgebouw weer onder de grond kabels naar een centrale lopen of dat mijn gesprekken draadloos via een satelliet verlopen, dat maakt mij niet uit. Wat mij interesseert is dat ik mensen kan bellen, dat de ‘lijn’ goed is, dat ik er op kan vertrouwen dat het toestel altijd functioneert en dat de prijs niet te hoog is. Maar nogmaals, hoe de techniek werkt, dat maakt mij niet uit.

 

 

Ik denk dat veel gebruikers waarvoor Business Intelligence-omgevingen opgetuigd worden, dezelfde gevoelens hebben voor wat betreft hun rapporten. Zij weten dat er ergens gegevens bijgehouden worden en ze willen die gegevens kunnen bestuderen en analyseren. Ze vragen om rapporten die aan hun eisen voldoen. En uiteraard krijgen ze die rapporten, maar ook wordt er een zeer complexe, vaak database-gedreven architectuur opgebouwd. Een architectuur bestaat uit diverse databases, zoals datawarehouses, datamarts, operational data stores en staging areas, aangevuld met een gehele omgeving om gegevens van de ene naar de andere database te kopiëren. Daar hadden de gebruikers niet om gevraagd, maar dat hebben de specialisten in al hun wijsheid besloten.

 

Net zoals ik niet vraag om een geheel telefoonnetwerk bestaande uit kabels, satellieten en centrales, zo vragen gebruikers niet om datawarehouses. Niemand wil eigenlijk een datawarehouse. Een datawarehouse is een technische oplossing die onderdeel is van de complete oplossing om rapporten te maken. Het is dus niet DE oplossing, het is één van de mogelijke oplossingen. Al is het wel duidelijk dat sommige BI-specialisten moeite hebben om zich voor te stellen dat het anders kan. Er is een tendens om standaard database-gedreven architecturen te ontwikkelen, alsof het niet anders kan.

 

In dit nummer van DB/M staat een artikel van Bill Inmon waarin hij uitlegt hoe zijn architectuur, genaamd de Corporate Information Factory, gecombineerd kan worden met Ralph Kimball’s datamart-gebaseerde architectuur. Een interessant artikel, maar wederom wordt er een database-gedreven architectuur voorgesteld. Jaren geleden waren dit soort architecturen waarschijnlijk noodzakelijk. Het waren de enige oplossingen die werkten. Ik denk dat dit nu niet meer altijd het geval is. De hardware- en softwaremogelijkheden zijn zo sterk verbeterd dat we andere oplossingen kunnen bedenken. Waarom nog een fysiek datamart bouwen als de BI-tools een in-memory database opbouwen? Waarom nog gekopieerde gegevens opslaan nu er sterke datavirtualisatie- en datafederatiemogelijkheden op de markt verschenen zijn?

In hetzelfde artikel wordt het begrip ‘single version of the truth’ diverse malen genoemd. Op zich een interessant idee om hier naar te streven. Maar ook hier wordt weer gesuggereerd dat er maar een goede oplossing is en dat alles eerst opnieuw opgeslagen moet worden; wederom een database-gedreven oplossing. Alsof we niet uit dit keurslijf kunnen stappen.

 

Ik denk dat het tijd wordt dat we het idee moeten loslaten dat rapporten alleen maar gecreëerd kunnen worden door middel van een complexe database-gedreven architectuur. De technologie van vandaag maakt het mogelijk om voor (deels) virtuele oplossingen te kiezen. We hebben tegenwoordig ook veel meer query power waardoor we minder databases hoeven op te bouwen en te beheren, waardoor de architectuur gesimplificeerd kan worden.

 

Ik vroeg om een mogelijkheid om met anderen te bellen, ik vroeg niet om een geheel telefoonnetwerk. Hetzelfde geldt voor onze gebruikers. Zij hebben nooit om een datawarehouse gevraagd, ze vroegen om rapporten die hun beslissingsproces ondersteunen en misschien zelfs verbeteren. Het maakt hen niet uit wat de oplossing is. Laten we terug gaan naar de oervraag van de gebruikers en opnieuw nadenken over welke mogelijke oplossingen er vandaag de dag allemaal zijn.
 
Deze column verscheen eerder in Database Magazine 1-2011.

 

]]> Thu, 17 Feb 2011 15:07:59 GMT <![CDATA[Lekken als gekken]]> Weet u het nog? Er zit een meneer in de Tweede Kamer die zijn buren gedreigd heeft om door hun brievenbus te urineren. Deze buurt-ogre (hij lijkt zelfs op Shrek) is op zijn beurt door heel beschaafd Nederland zwart gemaakt. Een van de mensen die dat heeft gedaan werkt incassobureau en heeft toegang tot de systemen van het UWV. Eind november 2010 meldt de Volkskrant namelijk dat “het lid” zwaar in de schulden zit, achtervolgd wordt door gerechtsdeurwaarders en behalve zijn riante salaris als Kamerlid ook een UWV-uitkering heeft. Wie er precies achter dat lek zit is niet met zekerheid te zeggen maar uit welke hoek de info komt is duidelijk. Onder de vele tienduizenden overheidsdienaren die bij de inkomensgegevens in de UWV Polisadministratie kunnen zitten ook de gerechtdeurwaarders. Die hebben formeel een ambtelijke status maar zijn feitelijk medewerkers van commerciële incassobedrijven. Vrijwel zeker heeft een incassomedewerker een centje bijverdiend door de Volkskrant een uitdraai te geven van het incassodossier, inclusief de dienstverbandgegevens uit de UWV Polisadministratie. Goede journalistiek, dat wel.

Deze casus en nog meer de Wikileaks casus laten het eens temeer zien: overheden en bedrijven zijn niet in staat en/of bereid om gevoelige digitale gegevens te beheren. Bij Wikileaks konden duizenden mensen bij de gelekte documenten. Wat vooral verbaast is dat niemand van die mensen eerder informatie heeft gelekt of gestolen. Even serieus: natuurlijk is de Wikileaks info al veel eerder gelekt aan of gestolen door veiligheidsdiensten, maar die zijn daar anders dan meneer Assange erg discreet over. Bij overheidssystemen zoals de bevolkingsadministratie of de Polisadministratie is het niet anders: legioenen ambtenaren en incassomedewerkers kunnen ongezien bij uw persoonsgegevens en mijn inkomensgegevens, dus reken maar dat er heel wat in stilte wordt gejat en verkocht. Het punt is dat we het niet willen weten, zeker niet als er sappige info wordt gelekt of wanneer het slachtoffer een buurt-bully van een andere politieke partij is.

Als professioneel betrokken burger zit alle desinteresse en incompetentie mij zo hoog dat ik nu zelf eens wat ga lekken in Q&A vorm. Q: Hoe kan een incassobureau bij de gegevens van een willekeurige burger komen? A: Gewoon door een collega gerechtsdeurwaarder met een ambtenarenstatus in de Polisadministratie te laten kijken met behulp van het goede Burgerservicenummer. Q: Hoe komt die incassomedewerker aan een BSN? A: Op allerlei onwettige manieren, bijvoorbeeld omdat het bureau ook werkt voor overheidsorganen die aan incasso doen. Q: Controleert dat incassobureau niet wat hun medewerkers doen? A: Meestal niet want de toegang tot de gegevens is helemaal kosteloos. Q: Wordt er niet gelogd wie de gegevens opvragen? A: Ja, maar daar heb je niks aan wanneer gegevens worden opgeslagen in een eigen deurwaardersdatabase en vervolgens voor Jan en alleman beschikbaar zijn. Q: Oké, maar wordt er gelogd welk deurwaarderskantoor de gegevens opvraagt? A: Ja! Q: Waarom gaat niemand dan achter dat foute incassobedrijf aan? A: Tja… Waarom eigenlijk niet? Zou het kunnen dat het ons eigenlijk niet interesseert wie onze gegevens raadpleegt?
Zou het kunnen dat we geloven dat er niets aan gegevensdiefstal is te doen? Misschien. Misschien moeten we gewoon wachten tot er mensen worden benadeeld die we wel sympathiek vinden, onszelf bijvoorbeeld.

Wat in elk geval speelt is dat de betrokken overheidsorganisaties vaak opvallend weinig interesse hebben in het beschermen van de aan hun toevertrouwde gegevens. Neem weer de Polisadministratie: dat systeem beschikt over een ultrakrachtig mechanisme voor autorisatie en logging (zie DB/M 2009/3). Dat mechanisme is er echter niet gekomen omdat de specificaties dat voorschreven, maar omdat de bouwers het onverantwoord vonden om een basisadministratiesysteem te ontwikkelen dat zonder enige vorm van controle zou kunnen worden leeggetrokken. Toen het systeem in productie was kwam de vraag op of het ook actief zou worden gebruikt om de privacy van burgers te beschermen. Het antwoord was “nee”: intern gold het beleid dat de eigen medewerkers werden vertrouwd tot het tegendeel bleek en de integriteit van de externe afnemers was (en is) een zaak van het management van die organisaties. Fijntjes werd er nog aan toegevoegd dat het sowieso de vraag was of het systeem wel moet loggen, want zoiets kan ook leiden tot aansprakelijkheid. Welkom bij de Nederlandse overheid.
Voordat er een verkeerd beeld ontstaat: het is niet overal zo. Bij de bevolkingsadministratie staat gegevensgebruik wel op de agenda. Maar het probleem is dat dat niet veel helpt in een wereld waarin gevoelige gegevens van database naar database worden gepompt en er altijd wel ergens een zwakke schakel is.

Terug naar het Kamerlid. Ik hoop dat het gegevenslek rond het Kamerlid alsnog boven water komt. Alle logging-gegevens zijn beschikbaar bij het UWV, bij de koepelorganisatie van de gerechtsdeurwaarders en wellicht bij het incassobureau van waaruit is gelekt. Je moet alleen willen kijken en daar zit het probleem.
Stuurt u deze column door naar Geert Wilders of doe ik het?

Deze column verscheen eerder in Database Magazine 1-2011.
 

]]> Thu, 17 Feb 2011 14:52:01 GMT <![CDATA[I.Know, tekstanalyse zonder gedoe]]> Afgelopen week had ik een zeer interessante bespreking met de mensen van InterSystems over hun nieuw tekstanalyse-product genaamd I.Know. I.Know was een kleine zelfstandige start-up uit België (www.iknow.be) , maar is recentelijk overgenomen door InterSystems, een Amerikaans bedrijf dat de meesten kennen van de databaseserver Caché en het ESB-product Ensemble.

Bij veel bestaande tekstanalyse producten moet er eerst heel wat voorwerk gedaan worden voordat werkelijk de tekst geanalyseerd kan worden. Als we bijvoorbeeld alle tekstberichten van een call center willen analyseren en willen bepalen hoeveel berichten positief en hoeveel negatief zijn, dan moet het product eerste verteld worden welke woorden geassocieerd kunnen worden met positief en welke negatief. Dit kan een tijdrovende exercitie zijn. In feite moet het product vertrouwd gemaakt worden met de gebruikte terminologie.

Bij I.Know is dit niet het geval. Het kan teksten analyseren zonder dat vooraf enig werk plaatsvindt. Door een totaal afwijkende aanpak kan het product toch heel wat intelligents melden over de teksten die hij aantreft. Om die reden zou je het een instant tekstanalyse product kunnen noemen.

De query mogelijkheden van het product staan toe dat gebruikers op zeer simpele wijze vrij door de teksten heen kunnen navigeren waarbij het product zijn analyseresultaten gebruikt ter ondersteuning van de navigatie. Vanuit dit perspectief zou je het een text discovery tool willen noemen.

Hoe we het ook gaan noemen, als u zich interesseert in business intelligence en tekstanalyse, dan is dit een product om te bestuderen.

 

]]> Fri, 21 Jan 2011 14:04:37 GMT