Wat ik zelf erg interessant vond was een onderzoeksresultaat van de Engelse analist Nigel Pendse dat hij tijdens een Array evenement presenteerde. Zijn organisatie voert elk jaar een onderzoek uit naar het gebruik van datawarehouses; de BI Survey. Daarvoor stuurt zijn organisatie honderden enquêteformulieren op. Voor zijn presentatie had hij onderzocht hoeveel gegevens een BI-applicatie nodig heeft om te functioneren. De conclusie was dat dit rond de vijf Gigabytes ligt en dat die grootte door de jaren heen niet echt veranderd is. Om precies te zijn, honderden organisaties gaven aan wat hun BI-applicaties nodig hadden en de mediaan lag rond de vijf Gigabytes aan gegevens. Uiteraard waren er organisaties met BI-applicaties die heel veel meer gegevens nodig hadden, maar er waren er ook die minder nodig hadden.

Dit getal van vijf Gigabytes staat uiteraard in schril contrast met een getal als vijftig Terabytes. Ze horen eigenlijk niet bij elkaar. Want stel dat een organisatie een datawarehouse van vijftig Terabytes heeft opgebouwd, dan zijn er dus ongeveer tienduizend BI-applicaties. Let wel, al die applicaties moeten niet overlappende gegevensbehoeftes hebben, want anders zijn er nog veel meer nodig. De realiteit is uiteraard dat BI-applicaties juist wel dezelfde gegevens gebruiken. Hoeveel applicaties hebben we dan wel niet nodig om een datawarehouse van vijftig Terabytes te vullen?

Het probleem bij deze vergelijking is dat als er gesproken wordt over de grootte van een datawarehouse men over het algemeen de bruto grootte bedoelt, terwijl Nigel Pendse het over de netto grootte heeft. De bruto grootte van een datawarehouse is die hoeveelheid bytes die door de gehele datawarehouse-omgeving wordt ingenomen, dus inclusief het datawarehouse zelf, de datamarts, de kubussen, het ODS, enzovoort. Het omvat als het ware het totaal aan alle opgeslagen gegevens. Daarentegen is de netto grootte de hoeveelheid bytes die de gegevens zouden innemen als we het in een sequentieel bestand zouden opslaan zonder enige vorm van redundantie.

Het verschil tussen deze twee grootheden kan aanzienlijk zijn. De reden is de forse hoeveelheid redundante gegevens die opgeslagen wordt. Bijvoorbeeld, in veel gevallen zijn alle gegevens in de datamarts volledig redundant ten opzichte van wat er in het centrale datawarehouse ligt opgeslagen (mits die aanwezig is); dimensies worden soms in verschillende datamarts herhaald; vele kubussen zijn ook vaak volledig redundant; tussen een eventueel ODS en een datawarehouse bestaat veel overlap; en hetzelfde geldt voor datamarts en een eventuele persistent staging area. Daarnaast bevat een datawarehouse zelf ook veel redundantie. De gegevens in de indexen, die in de materialized views, en de kolommen met geaggregeerde gegevens; ze zijn allemaal redundant.

Ik zou wel eens willen weten wat nu gemiddeld het verschil is tussen de netto grootte en de bruto grootte van datawarehouses. Het zou mij niet verbazen als blijkt dat bij veel organisaties de netto grootte slechts 20 procent is van de bruto grootte. En dit is een hele conservatieve voorspelling, omdat we weten dat als we gegevens in een klassieke SQL database server laden, we al met een explosiefactor rekening moeten houden van tenminste drie.

Is dat belangrijk? Ik denk het wel. Het opslaan van redundante gegevens zal ongetwijfeld nuttig zijn om de performance van lastige query’s te versnellen, maar hebben we enig idee wat de kosten van al die redundante gegevens zijn? Hoe duur is eigenlijk een datamart? Wat kost het om die redundante gegevens bij te werken? In hoeverre vertragen ze het laadproces? Verminderen ze de flexibiliteit van een omgeving?

Zijn onze datawarehouses dus nu echt zo groot? Uiteraard zijn veel datawarehouses niet klein en uiteraard groeien ze hard, en uiteraard bezitten eBay en WalMart fenomenaal grote databases, maar het leeuwendeel van al die gegevens is gewoonweg redundant. Dus de cijfers zijn inderdaad wat misleidend. Onze gehele datawarehouse-omgeving, inclusief alle datamarts en kubussen, is inderdaad zo groot, maar de netto hoeveelheid gegevens is een stuk minder groot. Het wordt tijd dat we gaan bestuderen of al die redundantie nog wel nodig is en of onze architecturen misschien gesimplificeerd kunnen worden.

Opmerking: een werkelijke definitie van wat precies netto grootte is, moet wel wat preciezer zijn dan wat ik hier aangeef. Hierin moeten aspecten zoals onder andere compressie en het normaliseren van gegevens meegenomen worden.

Deze column verscheen eerder in DB/M 5-2010.

Tijdens de Ronde Tafel bijeenkomst die na het BI Event op 18 mei plaatsvond, vertelde Bill Inmon over zijn ervaringen met Wikipedia. Die zijn niet onverdeeld gunstig. Zo vertelde hij op zijn normale ´Gee Bill´-manier dat hij erachter kwam dat er inmiddels een entry op Wikipedia over zijn persoontje was verschenen. Aardig, zult u denken. Echter, Bill kwam erachter dat er een aantal onwaarheden en/of onnauwkeurigheden werden vermeld. Als ´father of the data warehouse´ ben je dan niet te flauw om dat even te corrigeren. Zo gezegd, zo gedaan. Wat schetst zijn verbazing toen hij erachter kwam dat zijn correctie was verwijderd en de oorspronkelijke tekst weer in volle glorie was hersteld. Niet voor een kleintje vervaardigt corrigeerde Inmon opnieuw, met gelijk resultaat. Sterker, na verloop van tijd werden zijn wijzigingen zelfs tegengehouden. Bill Inmon kan de tekst over Bill Inmon op Wikipedia niet wijzigen.

Een week geleden vertelde Don Tapscott (onder andere bekend van boeken als ´Wikinomics´ en ´Growing up digital´) een soortgelijk verhaal. Zijn boek Wikinomics, uitgebracht in 2006, werd goed ontvangen en was aanleiding voor velen om zich spontaan op internet rondom het thema te organiseren. Een entry op Wikipedia was daar uiteraard ook een onderdeel van. Ook Tapscott kwam er op een goed moment achter dat hij op Wikipedia werd vermeld. En ook in zijn geval was hij het niet eens met de beschrijving, waarop hij wijzigingen wilde doorvoeren. Het antwoord aan Tapscott: ´Wie ben jij dan wel dat je denkt dat je dit kunt veranderen?´. Ik vermoed dat Tapscott in digitale zin zijn vinger heeft opgestoken en heeft geantwoord: ´Eh, Don Tapscott?`.

Ik weet niet waar de ´wisdom´ in deze gevallen ligt. Zowel Inmon als Tapscott gebruikten de anekdote om een handelswijze aan te geven die ze niet terecht vinden. Waarschijnlijk zouden u en ik precies zo denken als het om ons ging. Aan de andere kant: stel dat Inmon zichzelf zou beschrijven als een goed gebouwde, inspirational leader die telkens weer vernieuwende inzichten brengt en aan de andere kant hadden we een groep mensen die hem eerder beschrijft als een tamelijk compact gemodelleerde expert die met gesloten ogen hetzelfde verhaal oplepelt als het jaar ervoor, gelardeerd met verwijzingen naar zijn website – voor welke beschrijving zou u dan gaan? Wat is hier wijsheid? Langzaam wen ik aan de wisdom of crowds…

Toch lieten de congresgangers zich niet intimideren door de files; ruim 200 mensen waren aanwezig bij de aftrap van het BI-event, een half uur later dan gepland.

Dat betekent meestal dat de de dagvoorzitter (ik, zei de gek) zijn spreektijd in moet leveren. Zo ook nu. Jammer, want ik had weer zo’n fameuze ‘keiharde aanval op BI’ voorbereid .

Opvallend vond ik dat het dozijn parallelsessies bijzonder goed werd bezocht en dat zelfs de afsluitende keynote, die van Rick van der Lans, nog voor een zeer goed gevulde zaal werd gepresenteerd. Chapeau voor het uithoudingsvermogen van de congresgangers!

Viel er veel interessants te beleven? Absoluut. Was er veel nieuws? Ja en nee. Om met dat laatste te beginnen: Mr ‘Gee, Bill’ Inmon presenteerde zijn oplossing om ook tekstuele data op te slaan in een relationele database. De eerste vraag die dan rijst is: ‘waarom zou iemand dat willen?’ Die vraag stelde ik hem na afloop voor de camera. Dat filmpje ziet u binnenkort op BI-platform.

Wel vrij nieuw, althans in het vakgebied BI, is de toepassing van de semantische wiki. Amerikaan Mark Greaves, werkend bij het bedrijf Vulcan (heeft niets te maken met IJsland, maar wel met Paul Allen, ex-Microsoftmaatje van Bill Gates). Greaves wist in een goede presentatie het fenomeen helder neer te zetten. De Semantic MediaWiki is feitelijk ook een oplossing om tekstuele data, en dan vooral van het web, bij de informatievoorziening te betrekken. Ook met Greaves sprak ik achteraf op camera.

Frank Buytendijk sloeg al jaren geleden af van het technologie-pad en concentreert zich nadrukkelijk op het toepassingsgebied van BI binnen de business - en daarbuiten. Wie mij kent, weet dat dat mij bijzonder aanspreekt. BI zonder strategische, in de organisatie ingebedde aanwending is als zaad op de rotsen. Buytendijk presenteerde een aanpak waarbij de management-processen – en dus niet de business processen – in kaart zijn gebracht. Ook demonstreerde hij het fenomeen Selectieve Perceptie op hilarische wijze.

De slot-presentatie over Saas BI van Rick van der Lans zal menig BI-specialist flink aan het denken hebben gezet. In zijn keynote legde hij verband tussen de vigerende trends zoals Cloud- en Self-service BI en het imago van ICT. Het feit dat de business BI – en eigenlijk geheel ICT -naar zich toetrekt, zou wel eens een rechtstreeks gevolg kunnen zijn van de heersende onvrede bij de gebruikers over de bruikbaarheid van de prestaties van ICT. En dat zou eigenlijk iedereen in de ICT ongerust moeten maken.

Ook de parallelsessies waren van hoog niveau en mochten zich – ik zei het al in het begin – verheugen in een grote belangstelling. Ook hier was er niet zozeer een technische insteek, maar werden meer de strategische en de menselijke aspecten besproken. Interessante materie!

Na afloop toog een kleine groep genodigden, waaronder de keynote-sprekers,  naar het kantoor van de VX Company in Baarn, om daar in een soort Pauw & Witteman-achtige setting de besproken onderwerpen nog eens aan een discussie te onderwerpen. Dat duurde tot 11 uur die avond.

Al met al een vermoeiende, maar heel lekkere BI-dag!

Hans Lamboo is Hoofdredacteur Database Magazine en BI-platform.

Begin maart 2010 organiseerde BI Dutch, een special interest group gericht op Business Intelligence, een middag over dit onderwerp en, zoals te voorspellen was, kwamen daar veel mensen op af. Het thema was Self Service BI en de middag begon met drie sprekers die elk het onderwerp vanuit een ander perspectief belichtten en het werd afgesloten met een door mij geleide paneldiscussie.

Een vaak gestelde vraag is voor wie SSBI eigenlijk bestemd is, ofwel voor welk soort gebruikers? Wouter van Aerle van Capgemini gaf hier een helder antwoord op. Hij onderscheidde de volgende vier toepassingen:

- voor analytische vragen die eenmalig of slechts een paar keer gesteld zullen worden;

- voor het ontwikkelen van prototypes waarmee de informatiebehoeften duidelijk gemaakt kunnen worden;

- voor het geval een korte time-to-market gewenst is, ofwel bij acute vragen;

- voor het voortbrengen van structurele BI-toepassingen, dus als verlengstuk van het BI-ontwikkelteam.

Kortom, SSBI is niet bedoeld voor elke gebruiker en niet voor elke vorm van analyse. De vraag is alleen of de leveranciers zich ook tot deze vier toepassingen beperken als ze met de gebruikers in gesprek gaan.

De afsluitende paneldiscussie werd een levendige discussie waaraan het publiek ook volop meedeed. Hier staan enkele punten die bediscussieerd werden.

Voordat we met datawarehouses aan de slag gingen (een lange, lange tijd geleden), hadden veel organisaties een wirwar aan rapporten ontwikkeld en iedereen deed maar wat. Er was weinig controle op de kwaliteit en consistentie van gegevens en iedereen kopieerde er luchtig op los. Het effect was dat de betrouwbaarheid van de gegevens waarop de rapporten gebaseerd waren dubieus en inhoudelijk inconsistent was. De datawarehouse architectuur moest hierin verandering brengen. In feite was dit al SSBI, maar dan SSBI oude stijl.

Met SSBI nieuwe stijl lopen we in principe een vergelijkbaar risico, ook al zetten we alle gegevens keurig klaar en zorgen we dat ze geïntegreerd, geschoond en correct zijn. Als de gebruikers er daarna gewoon mee kunnen doen wat ze willen, dan kan dat uit de hand lopen. In feite lopen we dan het risico dat we net zo'n slechte rapportage-omgeving krijgen als vroeger. Het enige verschil is dat we er een datawarehouse en leuke nieuwe tools bij gekregen hebben.

Ook bij deze architectuur worden taken van de interne BI-specialisten afgenomen. Interessant dat twee populaire trends in de BI-wereld gemeenschappelijk hebben dat taken bij de BI-specialisten weggehaald worden. Wat moeten we hieruit concluderen? Zijn de gebruikers ons zat, of zijn ze niet tevreden over wat wij normaliter voor hen ontwikkelen? Of misschien een combinatie van de twee? Ik vermoed dat het gedeeltelijk te maken heeft met onze eigen prestaties. Sommige van onze architecturen zijn gewoonweg niet flexibel genoeg. Als een rapport snel ontwikkeld moet worden, loopt de gebruiker tegen allerlei beperkingen en procedures aan waardoor het niet kan. Of als een bestaand rapport gewijzigd moet worden, moet vaak een hele keten van specificaties aangepast worden.

Samenvattend, de middag georganiseerd door BI Dutch was nuttig en interessant en riep veel goede discussies op. Deze door BI Dutch georganiseerde middagen zijn zonder meer aanraders.

Rick van der Lans is zelfstandig IT-consultant.

Deze column verscheen eerder in Database Magazine 3-2010.