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.

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.

Zoals de naam doet vermoeden is SQLStream een zogenaamde streaming databaseserver, vergelijkbaar met IBM InfoSphere Streams en StreamBase Server. Het grote verschil tussen enerzijds SQLStream en anderzijds de meeste andere producten is dat eerstgenoemde volledig SQL ondersteunt. Ook de instructies om te streamen zijn volgens de SQL-standaard. De meeste andere gebruiken proprietary talen, zoals Spade of extensies.

Voor diegenen die zich nog niet zo in dit onderwerp verdiept hebben, een streaming databaseserver staat toe dat we queries formuleren op stromen van gegevens. Voorbeelden van stromen zijn logfiles van bepaalde systemen, messages die binnenkomen, of de weblogs. Nog voordat deze gegevens in tabellen zijn opgeslagen kunnen we ze al benaderen. Iemand heeft streaming databaseservers wel eens als volgt uitgelegd: een query in de contaxt van een klassieke databaseserver is als de vraag hoeveel vissen bevinden zich in deze vijver, en een query bij een streaming databaseserver is als hoeveel vissen er voorbij zwemmen in een bepaalde periode in een snelstromende rivier.

SQLStream is absoluut de moeite waard om te bestuderen. Het biedt zeer zker al de bovenstaande mogelijkheden. Met views worden streams gedefinieerd en dit soort streaming views kunnen invoer zijn voor andere streaming views. Via join- en union-operatoren kunnen de gegevens van verschillende bronnen integreren. In feite ondersteunt het de mogelijkheden van een ETL-tool, echter er wordt nu met streams en SQL gewerkt. Gegevensstromen worden live geïntegreerd op het moment dat ze binnenkomen. Het resultaat van een geïntegreerde stream kan naar een applicatie of datawarehouse gestuurd worden. Zie de volgende link waarbij uitgelegd wordt hoe SQLStream vanuit SQL Power gebruikt kan worden.

Opmerking: De eigenaren van SQLStream zijn tevens de oprichters van eigenbase.org. Deze organisatie levert een toolset waarmee databaseservers ontwikkeld kunnen worden. SQLStream is ook gebouwd met deze toolset.

Maar als je de verhalen over deze producten leest en aanhoort, ontstaat wel een déjà vu gevoel. We gaan daarom terug in de tijd om dit toe te lichten.

Begin jaren tachtig kwamen de eerste SQL-producten op de markt. Het duurde even voordat ze door de markt geaccepteerd werden, maar zeker aan het einde van de jaren tachtig waren ze de dominante database servers. Zo begon de hegemonie van SQL in de databasewereld, die tot op de dag van vandaag voortduurt.

De eerste applicaties die ontwikkeld werden, waren voornamelijk administratieve applicaties. Sommigen wilden echter meer technische applicaties ontwikkelen. Karakteristiek aan dat soort applicaties is dat de objecten die gemanipuleerd worden zeer complex zijn. Technische applicaties ontwikkelen op een SQL-database server was toentertijd een uitdaging. In diezelfde periode kwamen ook de eerste object oriented programmeertalen op de markt, die zeer snel door de technische wereld werden geadopteerd. Maar even snel werd duidelijk dat het huwelijk tussen OO-talen en SQL niet ideaal was. Sommige leveranciers brachten dan ook  speciale OO-database servers op de markt. Deze producten sloegen de gegevens niet als tabellen en kolommen op maar als objecten, en ondersteunden geen SQL maar vaak eigen proprietary talen. Hun marketing pitch was dat met deze database servers applicaties ontwikkeld konden worden die met SQL nauwelijks mogelijk waren.

In het begin hadden zij zeker gelijk, maar uiteindelijk werden de klassieke SQL-producten zodanig verbeterd, dat ze de technische applicaties wel konden ondersteunen. Dit leidde er toe dat de nieuwere OO-database servers toch uit de markt verdrongen werden. Momenteel kom je ze alleen nog in kleine nichemarkten tegen.

Hetzelfde gebeurde met datawarehousing in de jaren negentig. In het begin hadden de klassieke SQL-producten moeite om de zware en typisch datawarehouse-gerichte query’s snel te verwerken. Dus kwamen er database servers op de markt die gegevens op een andere wijze opsloegen (dus niet meer in tabellen en kolommen) en andere databasetalen boden. Dit worden ook wel OLAP- of multidimensionale database servers genoemd. Ondertussen zijn de SQL-producten uitgebreid met mogelijkheden om ook die zware query’s snel te verwerken. Zeker de zogenaamde datawarehouse appliances (die allemaal SQL gebaseerd zijn) leveren soms indrukwekkende prestaties. Hiermee is de behoefte aan speciale, niet-SQL gebaseerde database servers sterk afgenomen.

Tenslotte hebben we in de afgelopen jaren wederom een nieuw type workload gekregen: het opslaan, bewerken en terugzoeken van XML-documenten. Ook dat ging in het begin lastig met SQL. Dus werden er weer speciale database servers gebouwd, speciaal ontwikkeld voor XML. Echter, in de huidige versies van DB2, Oracle en SQL Server, is ondersteuning voor XML prima geïntegreerd met SQL. Wederom werd een groep niet-SQL database servers langzaam verdrongen.

Kortom, in de historie van SQL-database servers hebben we nu al minstens drie keer gezien dat deze producten een nieuw type workload initieel niet aan kunnen. Er worden dan database servers ontwikkeld die speciaal voor dat type workload bestemd zijn. Ze zijn niet gebaseerd op SQL en slaan hun gegevens niet in tabellen en kolommen op. Iedereen is daar dan in het begin laaiend enthousiast over. Wat logisch is, want eindelijk kunnen bepaalde organisaties dan hun gewenste applicatie ontwikkelen. De producten krijgen dan enkele jaren volop aandacht, totdat de leveranciers van de SQL-producten een acceptabele oplossing bedenken, waardoor de niet-SQL producten langzaam uit de markt gedrukt worden.

De grote vraag is nu: gaat dit nu ook weer met de NoSQL stroming gebeuren, is ook deze een kort leven in de spotlights beschoren en worden ook zij straks weer uit de markt verdrongen? Als we naar de geschiedenis kijken, dan is het antwoord duidelijk: ja. Of vormen zij de bekende uitzondering? Over twee of drie jaar zullen we het waarschijnlijk wel weten. Ondertussen zou ik organisaties aanraden voorzichtig te zijn met het adopteren van deze technologie. Want als u er nu in investeert en over enkele jaren blijken ze toch verdrongen te worden, dan heeft u applicaties ontwikkeld die niet portable zijn, want ze gebruiken een proprietary databasetaal. Maar ik zou ze niet negeren, want er zijn nu applicaties die we momenteel niet met de huidige SQL-producten kunnen ontwikkelen en dan is een dergelijke NoSQL-oplossing het enige antwoord.

Rick F. van der Lans is zelfstandig IT-consultant.

Drie jaar geleden ontwierp ik voor Database Magazine een grote poster van ongeveer 1 m2 met de titel 'Het Business Intelligence Framework'. In deze poster werd enigszins op schematische wijze weergegeven hoe data van de bronsystemen via veel producten en technologieën terecht komen in diverse soorten rapporten en voor analyse beschikbaar komen. Tevens werden de verbanden tussen verschillende termen aangegeven.

Deze zomer ben ik begonnen met een vernieuwde versie van deze poster. Na enkele weken stoeien, besloot ik de insteek te wijzigen. In de nieuwe poster worden nu alleen maar technologieën en producten opgenomen die mogelijkerwijs door leveranciers geboden zouden kunnen worden om een datawarehouse-omgeving op te bouwen. Dus zaken als methodes en aanpakken komen er niet meer in voor. Vandaar dat de naam enigszins aangepast is: het 'Business Intelligence Technology Framework'. Het voordeel van deze gewijzigde aanpak is dat het eenvoudiger wordt om de BI-stack van een leverancier in kaart te brengen, ofwel het staat toe om de volledigheid van een leverancier’s BI-stack te controleren. Tevens kunnen we de BI-stacks van leveranciers hiermee vergelijken.

Ondertussen is voor enkele leveranciers gekeken in hoeverre ze alle producten in het BITF ondersteunen. Wat dan direct in het oog springt is dat leveranciers als IBM, Microsoft en Oracle, die zeer complete BI-stacks aanbieden, wat betreft het geïntegreerd beheren van metadata matig scoren. Uiteraard slaan al hun producten, dus hun ETL-producten, rapportageproducten, database servers en datakwaliteitproducten, ergens metadata op. Echter, er is geen product of module waarmee al die metadata geïntegreerd getoond en geïntegreerd bestudeerd kunnen worden.

Willen wij dus een geïntegreerd beeld krijgen van alle metadata, dan zullen we zelf metadata bij elkaar moeten brengen. In feite betekent dit dat we eenzelfde exercitie moeten ondernemen als die we voor onze data moeten uitvoeren. Naast integratie van data krijgen we dan ook integratie van metadata. Doen we dit niet en kunnen we dit niet, dan worden impactanalyse en lineage erg lastig.

Let wel, het geldt niet voor alle leveranciers. Als we bijvoorbeeld de BI-stacks van SAS of Information Builders bestuderen, zien we dat die veel meer de metadata van al hun producten centraal opslaan, met alle voordelen van dien. Uiteraard hebben SAS en Information Builders het voordeel dat ze bijna alle software zelf gebouwd hebben. Terwijl zeker IBM en Oracle erg veel modules gekocht hebben en het kost een leverancier uiteraard tijd om die serieus te integreren met de reeds bestaande producten.

Het blijft vreemd dat we nu al minimaal dertig jaar weten hoe essentieel metadata zijn en dat het belangrijk is dat deze ook centraal beheerd worden, dat we nu al dertig jaar bezig zijn om metadata goed georganiseerd te krijgen, maar toch moeten we concluderen dat het zelfs bij relatief nieuwe producten nog steeds niet ideaal geïmplementeerd is. Waarom blijven metadata toch altijd het kind van de rekening? Door de jaren heen zijn er al legio standaarden beschikbaar gekomen om metadata te registreren en uit te wisselen, maar ook dat heeft niet erg geholpen.

Voor veel klanten zou het beter zijn als leveranciers hun aandacht tijdelijk zouden verschuiven. In plaats van hun portfolio uit te breiden met zelfontwikkelde producten en met producten van andere leveranciers, zouden ze zich moeten richten op het ontwikkelen van een geïntegreerde metadata oplossing. Hierbij zouden alle metadata geïntegreerd bestudeerd en geanalyseerd moeten kunnen worden. Hoe ze dat doen is van ondergeschikt belang, als ze het maar doen. Het zou voor gebruikers het leven een stuk eenvoudiger maken.

Rick F. van der Lans is zelfstandig IT consultant.
Deze column verscheen eerder in Database Magazine 8-2009.

Dus voor de duidelijkheid, deze organisaties hebben geen datawarehouse, geen datamarts, geen ETL, niets. Alle gegevens liggen één keer opgeslagen en wel in de productiedatabases; eigenlijk zoals het hoort, zoals het in de schoolboekjes staat. Wat een eenvoud en wat een visie hadden deze ontwerpers jaren geleden!

Hebben deze organisaties geen last van performance verstoring? De ene organisatie meldt daar geen problemen mee te hebben. Bij de ander lijkt het alsof een bepaald rapport wat langzaam begint te draaien. De ontwerpers van Aorta hadden bij het begin al bepaald dat ze Oracle BI Server zouden inzetten om de rapportage los te koppelen van de werkelijke gegevensopslag. In feite is wat zij gedaan hebben in lijn met de ideeën van het Data Delivery Platform waarover ik recentelijk gepubliceerd heb. Als ze willen, kunnen ze een datamart, kubus, of datawarehouse toevoegen zonder dat de rapporten aangepast moeten worden. Het is puur een performance versus kosten overweging. Misschien kunnen ze het probleem ook oplossen door een snellere server aan te schaffen. Dit is een mooi voorbeeld waaruit blijkt het Data Delivery Platform als architectuur in de praktijk werkt: ontkoppel de opslagstructuur van de rapporten.

Maar het mooiste was wel dat toen aan de klant gevraagd werd of ze blij waren met hun moderne Operational BI-omgeving, zij vroegen wat daar precies mee bedoeld werd. Zij zagen het speciale van Operational BI niet in. Het waren ‘gewoon’ hun rapporten. Beide organisaties hebben per ongeluk Operational BI in gebruik.

Wat we hier zeker van kunnen leren is dat we in onze cursussen over database-ontwerp, en dan bedoel ik het ontwerp van productiedatabases, moeten doceren dat historie altijd bijgehouden moet worden; gooi geen gegevens weg. Misschien zijn die historische gegevens initieel niet van belang, maar ze later toevoegen is een hels karwei. We voorkomen hiermee dat we alsnog complexe datawarehouses moeten ontwikkelen of andere constructies moeten optuigen om de gewenste rapporten te kunnen ontwikkelen.

In de literatuur doet men erg moeilijk over Operational BI. Operational BI hoeft niet moeilijk te zijn, mits je maar de correcte architectuur voor de datawarehouse-omgeving opzet.

Rick van der Lans is zelfstandig IT-consultant.

Wat is BIAAS eigenlijk? De gebruiker neemt in feite een abonnement op het gebruik van een BI-omgeving. De genoemde leveranciers hebben allemaal hun eigen BI-omgeving ontwikkeld. Deze nieuwe generatie BI-tools is volledig ontwikkeld om in een internet browser te draaien. Over het algemeen zijn dit zeer modern ogende BI-tools met alle functionaliteit die je vandaag de dag van een BI-tool verwacht. Ze zien er prachtig uit omdat ze allemaal met Flash gemaakt zijn en ze zijn eenvoudig in gebruik. De meeste ondersteunen ook geavanceerde mogelijkheden voor collaboration. Voor opslag maken de BIAAS-leveranciers voornamelijk gebruik van bekende database servers, zoals MySQL en Oracle. Al heeft PivotLink eigen databasetechnologie ontworpen. De klant stuurt periodiek nieuwe gegevens naar de BIAAS-leverancier toe en deze zorgt dat ze in het datawarehouse geladen worden.

Betekent dit nu dat de BIAAS-leveranciers zalen vol hebben staan met grote machines waarop voor talloze klanten warehouses geïnstalleerd zijn? Nee. Ook zij outsourcen dit. Bijvoorbeeld, Blink Logic en PivotLink maken gebruik van Upsource, een leverancier van cloud computing. Dit soort leveranciers heeft op diverse plaatsen in de wereld grote rekencentra staan. De BIAAS-leveranciers maken daar weer gebruik van. Dus waar de gegevens van de BIAAS-klanten precies opgeslagen liggen, is zeker voor de klant niet bekend, maar ook niet relevant.

BIAAS is een serieus alternatief. Het is goedkoop, de BI-omgevingen zijn zeer snel op te tuigen en een klant hoeft zich met weinig technische zaken te bemoeien. Ik zou organisaties zeker aanraden eens te bestuderen wat BIAAS voor hen zou kunnen betekenen.

Rick van der Lans is zelfstandig IT-consultant.
 

Na een enorm verfrissende sessie moest ik naar de overkant van de baai naar het altijd plezante Pleasanton. In deze stad is Transpara gevestigd, wederom een tamelijk kleine en ditmaal ook jonge leverancier. Ze hebben maar één product: Visual KPI. Met Transpara kunnen we razendsnel KPI's op een mobile device, zoals de BlackBerry en de iPhone, plaatsen. Bekende BI-leveranciers hebben de afgelopen jaren ook getracht hun zware BI-producten te downsizen, zodat ze in die kleine apparaatjes passen. Transpara is daarentegen speciaal ontwikkeld voor mobile devices. Visual KPI is een extreem lichtgewicht oplossing. Verwacht dus ook geen honderden mogelijkheden om statistische analyses uit te voeren of om drilldowns uit te voeren. Nee, het is bedoeld om naar KPI’s te bekijken. Een gebruiker start zijn apparaat op en kan met één oogopslag zien hoe bepaalde processen er voor staan. Het ontwikkelen van dit soort omgevingen is met Transpara erg simpel. Een kind kan de was doen. Als u gebruikers kent die baat zouden kunnen hebben bij ‘mobiel BI’, dan is Transpara absoluut de moeite waard om te bestuderen; lichtgewicht en simpel.

Tijdens deze laatste meeting had ik ook een intrigerende discussie met Transpara’s oprichter en CEO, Michael Saucier, over het feit dat we in de BI-wereld iets teveel nadruk leggen op analytics en te weinig op het dagelijkse decision making proces. Zijn voorbeeld was: hoe vaak zal een winkelketen nadenken over het openen van een nieuwe zaak en hoe vaak zal men bezig zijn met beslissingen rond het op tijd aanleveren van de producten naar de winkels? Uiteraard is dit laatste essentieel voor een bedrijf om te overleven. Het is inderdaad een vraag die we ons zelf moeten stellen. Zijn we bij het opzetten van onze complexe warehouse-architecturen niet iets teveel gericht op het zware werk en zouden we ons niet eerst moeten richten op de ondersteuning van de dagelijkse bedrijfsprocessen? In ieder geval is Transpara daar klaar voor.

Het bezoeken van kleine leveranciers geeft verrassende inzichten; zij zijn in staat om vernieuwende producten te introduceren. Of die nieuwe technologieën de markt zullen aanspreken, de tijd zal het leren.

Rick van der Lans is zelfstandig IT-consultant.

Mijn eerste bezoek was aan zo’n kleinere leverancier: Kapow Technologies, een Deens bedrijf met het hoofdkantoor in Palo Alto. Met Kapow Mashup Server kunnen we een module met een API creëren op een HTML-gedreven website. Als de module klaar is, kunnen we via de API op zeer eenvoudig wijze gegevens van de betreffende website afhalen. We zouden een module kunnen maken die als invoerparameter een productnummer heeft en als uitvoerparameter de prijs waarvoor deze op de website verkocht wordt. Deze technologie kunnen we bijvoorbeeld gebruiken om op gestructureerde wijze van www.kieskeurig.nl gegevens op te halen over hoe onze producten geëvalueerd worden. Een ander voorbeeld zou kunnen zijn dat een price fighter met behulp van Kapow via websites van de grotere vliegtuigmaatschappijen prijzen ophaalt en dan die van haarzelf daaraan aanpast.

Een ander voorbeeld is dat een retailer de prijsontwikkeling van haar concurrenten kan bestuderen. Als die prijzen zijn opgehaald, kunnen deze met de eigen prijzen vergeleken worden en dit weer relateren aan de verkoopaantallen. Maakt het uit dat onze prijs de afgelopen maand 5 procent hoger was dan die van de concurrent? Als we de verkoop niet zien teruglopen, dan misschien niet. Wordt er misschien gestunt met de prijzen van bepaalde producten? Websites bevatten een schat van informatie, alleen zit deze meestal in HTML en JavaScript verstopt. Met Kapow maken we de informatie beschikbaar voor verwerking.
Met Kapow Mashup Server kunnen we op zeer flexibele en eenvoudige wijze een dergelijke module creëren. Als de module klaar is, is deze vanuit elke omgeving aan te roepen. We kunnen dus een BI-applicatie creëren die periodiek externe gegevens ophaalt en deze in het datawarehouse opslaat waarop we dan analyses kunnen uitvoeren. Dit type product zien we helaas nog zelden in BI-omgevingen toegepast worden. Het is een zeer eenvoudige manier om externe gegevens aan ons datawarehouse toe te voegen.

Kortom, deze afspraak bevestigde weer dat het bezoeken van kleine leveranciers verrassende inzichten geeft en dat zij in staat zijn om vernieuwende producten te introduceren. Of die nieuwe technologieën de markt zullen aanspreken, de tijd zal het leren.
 

Als u het niet kent, het is een Enterprise Information Integration product. Het staat toe dat een heterogene groep datasources als één logische database getoond wordt. Queries die aan een EII-product worden gesteld worden door het product gesluisd naar de onderliggende datasources. U vindt dat waarschijnlijk niet zo spectaculair, want er zijn veel producten op de markt die in staat zijn een virtuele laag over een verzameling heterogene datasources te leggen. Het krachtige aan dit product is dat we vandaag een query kunnen stellen die aan een SQL databaseserver, zoals DB2 of MySQL, doorgegeven wordt en morgen aan een MDX server, zoals Microsoft Analysis Services. Intern wordt dan de binnenkomende query niet naar SQL vertaald maar naar MDX. En hiervoor hoeft de query geheel niet aangepast te worden, dus ook het rapport niet. Dit geeft een enorme onafhankelijkheid en verhoogt de flexibiliteit.

Uiteraard kunnen we met de Universe van Business Objects iets vergelijkbaars realiseren, maar die specificaties en mogelijkheden kunnen we niet gebruiken als we ook rapporten met andere producten ontwikkelen.

Het vreemde is echter dat velen zich niet realiseren wat de kracht van Oracle BI Server is. Het wordt vandaag de dag zeker ingezet, maar het verdient eigenlijk meer aandacht. Kortom, een positieve verrassing. Hopelijk komen er de komende tijd meer van dit soort producten op de markt, want ze maken het mogelijk onze datawarehouse-architecturen technologie-onafhankelijker op te zetten.