BI-platform Blog http://www.biplatform.nl BI-platform Blogs RSS (c) Array Publications <![CDATA[Programmeren anno 2012]]> Oude mensen, zoals ik, herinneren zich nog hoe je in de zeventiger jaren moest programmeren.
We kwamen er net achter dat het beter was voor het automatisch uitvoeren van functies een opzet of ontwerp te maken zodat de structuur van je programma ook op papier duidelijk was. Dat maakte je programma gestructureerd, onderhoudbaar en de onderdelen herbruikbaar. Een INIT sectie waarbij je alle te gebruiken parameters declareerde en initieerde, een Body met de eigenlijke verwerking en een SLUIT sectie waarbij je bijvoorbeeld de sommaties publiceerde of opsloeg.
Dat gebeurde getrapt en hiërarchisch, dus de BODY kon ook weer bestaan uit een INIT-BODY-SLUIT etc. Verder had je nog de CALL routines, meestal al door een andere programmeur geschreven die herbruikbaar waren voor de pool van programmeurs, bijvoorbeeld om datums op te tellen.
De functies scheidde je zoveel mogelijk vanwege de risicospreiding, modulair opzetten heette dat toen en dat geldt nu nog steeds.
Als je dat een tijdje deed, kon je, zoals ik, ook programmeurs opleiden. Behalve de kunst van het ontwerpen bestond die opleiding vooral ook uit het kunnen diagnosticeren van de fout. Breaks zetten en waardes uitlezen van parameters waarvan je verwachtte dat ze een bepaalde waarde hadden, maar getuige de loop van het programma bereikten ze die waarde blijkbaar nooit. Waar lag dat aan ? Samen met de leerling programmeur ging je tot op de bodem van het programma met de source uitgedraaid op tafel, om de werking ervan volledig te doorgronden.
Hoe is dat nu ? De collega’s en leraren bevinden zich in de “community”. Je source is zo ongelooflijk groot dat ie uitsluitend tegen hoge printkosten in zijn geheel is uit te draaien. Als je programma vastloopt, ga je naar de FAQ’s en als die geen uitkomst bieden publiceer je de regels die met een rood uitroepteken zijn gemarkeerd samen met een veelal onleesbare of nietszeggende foutboodschap op de community site. Enkele uren later antwoordt iemand uit pakweg Argentinië dat je voor het derde woord in zin 8 een “s” en een komma moet plaatsen en een regel moet toevoegen aan een ander verwant stukje source. Je doet ’t en het werkt. Als je veel van die trucjes en vele behulpzame wegen kent kun je andere programmeurs opleiden.
Als oudje voel ik weerzin tegen het feit dat je dan niet meer weet wat er precies aan de hand is en waarom het nu wel werkt. Ach, komop Karien, das war einmal…. Toen wij met derde generatie programmeertalen gingen werken waren er ook oudjes die alleen in machine taal en registers geloofden. Times are a-changing….
]]> Tue, 10 Jan 2012 13:44:50 GMT <![CDATA[Barbapapa en de diamant in de hooiberg]]>
Over het onderwerp big data is veel geschreven. De vertrekpunten zijn dan ook min of meer bekend. Er is steeds meer data en in die toegenomen hoeveelheid willen wij steeds sneller relevante informatie vinden. De bekende naald, of in dit geval dan diamant, in de hooiberg. Maar net als Barbapapa neemt big data steeds andere verschijningsvormen aan. Gestructureerd uit onze eigen bedrijfssystemen bijvoorbeeld maar ook ongestructureerde data zoals documenten of websites. Data die steeds vaker ook buiten onze eigen organisaties te vinden is.  BI is echter van oudsher hier niet op ingericht en zal dus moeten innoveren om hiermee te kunnen omgaan. Dat gebeurt gelukkig vol op. De opkomst van allerlei moderne technologische oplossingen getuigen hiervan. Denk aan zaken als solid state disk, 64 bit in memory technologieën en datawarehouse appliances met massive paralel processing. Maar er gebeuren gelukkig ook heel veel mooie dingen op het gebied van software ten behoeve van data integratie. Hierbij zijn innovatieve nieuwe spelers en methodieken in opkomst.  Een mooi voorbeeld van het structureren van ongestructureerde data is bijvoorbeeld  Ontology based text searching dat je bij diverse leveranciers ziet terugkomen. 

Deze IT ontwikkelingen zijn allemaal bedoeld om meer waarde te kunnen toevoegen aan de organisatie en daarmee de kloof tussen business en IT wellicht weer een stukje verder te verkleinen. Mooie  ontwikkelingen die ik met veel plezier blijf volgen. 
]]> Tue, 28 Jun 2011 16:23: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.
 
Deze column verscheen eerder in Database Magazine 4-2011
 

]]> Mon, 27 Jun 2011 14:31:11 GMT <![CDATA[BI event revisited]]> Ik ben een fan van het BI Event. Om te beginnen is het gratis. Meestal moet je in ruil daarvoor de bekende oude opgebakte leverancierkliekjes aanhoren. Het BI event slaagt er wonderwel in om daar heel goed in te screenen. Nieuwe technologie, al of niet veelbelovend, leuke presentaties om de mogelijkheden te illustreren en als slagroom op de taart enkele grootse keynote speakers. Claudia Imhoff kende ik al en Donald Farmer was een revelatie. Rick van der Lans staat garant voor prikkelende uitspraken en veel humor. Wat te denken van one-liners als :
-          Supply is much easier to create than demand (Imhoff)
-          People don’t trust data, they trust other people (Farmer)
Overtuigend ook was het pleidooi om de term eindgebruiker te schrappen. Geen enkele gebruiker staat immers aan het eind van informatie. Als je informatie gebruikt (en dat is toch de bedoeling) gebeurt er iets, gebeurtenissen die an sich ook weer informatie genereren. Maak er maar gewoon gebruiker van.
Donald Farmer spreekt ook van de waarde voor BI van medewerkers die tussen de business en IT staan, weidt vervolgens uit over de kloof tussen aanbod en vraag en de noodzaak daartussen schakels te hebben, mensen met een neus voor informatie, medewerkers met information scent. Een prachtige herkenbaar beeld is dat. Ziet u ze ook voor u ?
Need I say more? Als was er verder niets meer gezegd dan dit, was het BI event al de moeite waarde geweest. Maar ja, zo’n blog geeft je maar beperkte ruimte.
]]> Tue, 31 May 2011 11:59:01 GMT <![CDATA[De goede dingen doen of de dingen goed doen?]]> Er zijn veel verschillende definities van Business Intelligence. Ook de experts op dit blog zullen hier wel een mening over hebben. In mijn eerste bijdrage voor het BI-platform wil ik ook wel een poging wagen. De meeste BI definities die ik ken of google hebben vaak een technische proces insteek. Bijvoorbeeld, het extraheren, transformeren en laden van data uit transactiesystemen in een eenduidige gegevensverzameling of datawarehouse. Mijn voorkeur gaat uit om te kijken naar het resultaat van BI: het meetbaar en beheersbaar maken van een proces, doel of strategie. De opbrengst bestaat dan uit het beter zaken kunnen doen. Bijvoorbeeld door meer te weten dan de concurrent of sneller te kunnen beslissen dan de competitie of dan de klant van ons verwacht. 
 
BI is daarmee een belangrijke kern competentie voor veel bedrijven. Veel projecten bevatten dan ook een BI component. Deze projecten starten vaak met het maken van een business case. Mogelijke kosten en opbrengsten worden meegenomen en alleen die projecten met een goede of positieve business case krijgen groen licht. Maar de donkere economische wolken hebben veel veranderd. Er worden niet alleen minder projecten gestart maar lopende projecten worden stopgezet, vertraagd of krijgen een scope aanpassing. Dat zijn dus de projecten waarvoor men in eerste instantie een positieve business case had opgesteld. Projecten die blijkbaar waarde toevoegen aan de organisatie maar die overweging lijkt ondergeschikt gemaakt te worden aan de keiharde realiteit van kostenbesparing. 
 
Om een juist oordeel te kunnen vellen over deze projecten moeten er antwoorden komen op vragen als: hoe draagt dit project bij aan onze strategische doelstellingen, doen we wel de juiste projecten of zijn er betere manieren om onze schaarse middelen in te zetten? Met andere woorden: is de business case nog steeds positief? Deze benadering noemt met ook wel portfolio management. Dit stelt organisaties in staat om inzicht te krijgen in de waarde van een bestaand of potentieel initiatief. Op deze manier wordt alleen geïnvesteerd in een project dat waarde toevoegt. De organisatie doet de goede dingen.
 
Maar minstens zo belangrijk als portfolio management is portfolio management informatie, BI over BI. Immers door de bestaande projecten portfolio continue te monitoren is een organisatie in staat om al vroeg gewaarschuwd te worden of een project bijvoorbeeld in de gevarenzone komt. Maar zij is dan ook in staat om actie te ondernemen voordat een project in waarde afneemt of zelfs een negatieve business case ontstaat. De organisatie doet de dingen goed. 
 
Om een maximale Return-On-Intelligence (ROI) te realiseren zullen bedrijven de goede dingen goed moeten doen. Met andere woorden, de BI oplossing moet blijvend waarde blijven toevoegen aan de organisatie. Het zou mooi zijn als deze component ook terug blijft komen in de BI definities. Hopelijk kunnen mijn toekomstige publicaties op dit blog hier een steentje aan bijdragen. 
 
]]> Fri, 27 May 2011 11:31:13 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:46:55 GMT <![CDATA[Is het de schuld van de loodgieter als ik de badkamer niet gebruik ?]]> Eind Maart bezocht ik een lezing van Stephan Peij, lector bij Inholland. Hij besprak ‘Governance’. Niet IT governance maar besturingsmodellen van bedrijven in het algemeen en de governance in het bijzonder. Hij onderscheidde in een bedrijf drie partijen : de strategie, de operatie en de controle of de governance. Dat lijkt op de Trias Politica van Montesquieu die voor een machtsevenwicht moet zorgen. Dat doet zij door een wetgevende, een uitvoerende en een rechtsprekende macht te onderscheiden.
Deze gedachte projecterend op het Steady State model zet het strategisch management de kaders, de systeemgrenzen, de normen en de beleidslijnen uit. Wetgevend dus. De operatie voert het bedrijfsproces uit, zo optimaal mogelijk maar binnen de door de strategische macht uitgezette kaders. De operatie is de uitvoerende macht. De “governance”, het controle mechanisme meet, rapporteert, evalueert en beveelt sancties of verbeteringen aan. Het is de rechtsprekende macht. Ook in het Steady State model staat een evenwichtige besturing centraal.
IT en de BI intelligence specialisten faciliteren het meten van de procesuitvoering en eventueel nog (met CPM) het modelleren van nieuwe modellen, op grond waarvan het strategisch management beleid of kader kan bijstellen. IT faciliteert dus met techniek de governance.
Die rol van IT is dus uiterst bescheiden. IT-ers trekken een veel te grote broek aan als het aankomt op hun rol in een BI project. Ze moeten worden afgerekend op hun technische bijdrage aan die controlecyclus en niet meer dan dat. Of al die techniek ook gaat renderen hangt natuurlijk niet van IT af maar van een correcte inzet van al die prachtige middelen. Oftewel : Is het de schuld van de loodgieter als ik de badkamer niet of verkeerd gebruik?
 
]]> Thu, 31 Mar 2011 16:31:42 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 10:58:42 GMT <![CDATA[Assange bedankt]]> Zag U premier Rutte ? Hij beweerde  in het nieuws dat er geen enkele concessie of bindende afspraak is gemaakt met het bewind van Khaddaffi ? “Geen enkele voorwaarde?” . “Nee” was zijn korte en bondige antwoord.
In het pre-Assangetijdperk keek je naar zo’n uitspraak in het bange vermoeden dat ergens in geheime stukken was vastgelegd dat Nederland zich verplicht had buiten een gewapend ingrijpen, op Lybië gericht, te blijven. Of erger nog: dat er een kleine uitzondering gemaakt zou worden op de internationale wapenboycot via een geheime route.
In het post-Assangetijdperk zal meneer Rutte vreselijk op zijn gezicht gaan als over een jaar de WIKI Leaks worden gepubliceerd die onthullen dat hij op de hoogte was van geheime afspraken. Het duurt geen jaar meer voordat geen enkele politicus het nog waagt zo’n stellige uitspraak te doen. Wat zou Rutte over een jaar antwoorden : “Voor zover ik weet zijn er geen afspraken gemaakt.”? Nee, dat klinkt te zwak. Alsof de premier niet goed op de hoogte zou zijn. “Jawel, maar dat houden we liever nog even onder de pet in het belang van u, de burger”.
Assange bedankt. De toekomst is aan integere politici, die bovendien blind moeten kunnen varen op al hun ondergeschikten. De tijd breekt aan dat ook premiers eerlijk zeggen dat ze natuurlijk een onvoorwaardelijke vrijlating hebben nagestreefd, maar dat hij als premier opdracht heeft gegeven om de helikopter af te staan inclusief de inhoud, een grote hoeveelheid munitie….. . Het kon niet anders. Begrip daarvoor.
]]> Wed, 16 Mar 2011 13:57:06 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 14:56:31 GMT