Is het de onvolwassenheid van het vakgebied, of toch een soort beroepsdeformatie? Hoe dan ook: het behoort tot de folklore van BI-land dat inhoudelijke discussies gemakkelijk uitdraaien op een jacht op de technisch-inhoudelijke “single version of the truth”. Voor- en tegenstanders voeren strijd over zaken als de juiste datamodelleertechniek, het aantal lagen dat je in een datawarehouse-architectuur kan, mag of moet onderkennen, de vraag of operationele systemen wel of geen BI-capabilities mogen bevatten (en of dat dan BI mag of moet heten), en ga zo maar door – vaak vanuit een impliciete gedachtengang dat er maar één goed antwoord is op iedere architectuurvraag.

Architectuurproces

Zolang het om wat vrijblijvend gediscussieer gaat, is dat niet zo erg. Maar het architectuurproces in concrete projecten ziet er helaas vaak niet veel anders uit. In mijn ervaring worden architectuurkeuzes eerder bepaald door de voorkeur en stijl van de architect in charge, dan door de specifieke eisen die de organisatie stelt aan zijn BI-omgeving. En het komt al helemaal zelden voor dat architectuurkeuzes gedurende de life cycle van het systeem gereviewd en bijgesteld worden om eventuele gewijzigde eisen te kunnen bedienen.

Goed beschouwd is dat een nogal contraproductieve manier van architectuur bedrijven. Vrijwel iedere aanpak, methode of techniek die ooit bedacht is, heeft wel ergens zijn nut en toepasbaarheid; de kunst is om te begrijpen welke aanpak je in welke omstandigheden het beste kunt volgen.

Niet-functionele eisen

Om de juiste aanpak te bepalen, moet de architect vraag en aanbod tegen elkaar afwegen: enerzijds moet hij weten welke alternatieven er voorhanden zijn en wat hun sterke en zwakke punten zijn, anderzijds moet hij weten welke eisen de omgeving stelt aan de oplossing. We hebben het dan niet alleen over functionele eisen: juist voor architectuurkeuzes zijn de niet-functionele eisen de belangrijkste driver.

Deze afweging zie ik in BI-projecten maar zelden gemaakt worden. Mindset speelt daarbij een grote rol: wie zich niet realiseert dat niet-functionele eisen voor iedere BI-omgeving verschillend kunnen zijn, zal daar geen ook energie in steken. En een one trick pony-architect zal uit zichzelf geen vraagtekens zetten bij de toepasbaarheid van dat ene truukje (ook al moet hij zich af en toe in de raarste bochten wringen om dat truukje toch maar tegen heug en meug te kunnen blijven gebruiken).

Voor architecten met een breder repertoire kan het ontbreken van inzicht in de toepassingskarakteristieken van relevante alternatieven een probleem vormen. Over de sterke kanten van een oplossing is meestal genoeg te vinden, maar de zwakke kanten blijven nog weleens onderbelicht. (Dat is overigens niet altijd een kwestie van onwil of verkooptactiek: vaak worden de nadelen pas duidelijk nadat een oplossing eerst een paar keer in verschillende omstandigheden is toegepast).

Professionalisering

Er vallen dus nog wel een paar slagen te maken in de verdere professionalisering van het BI-architectuurproces.
Om te beginnen moeten we ons de terminologie en het gedachtegoed van niet-functionele eisen eigen maken. We hoeven dat wiel niet zelf uit te vinden, maar kunnen de kunst afkijken bij aanpalende IT-disciplines: een kwaliteitsmodel als ISO 9126, of het daarop gebaseerde Quint zou (wellicht met enige aanpassing) prima onderdeel kunnen gaan uitmaken van de BI body of knowledge.

Verder moet het boven tafel krijgen van de niet-functionele eisen een vast onderdeel van het BI-architectuurproces worden.
(Het zou evident moeten zijn dat je die – net als de functionele eisen – ophaalt bij de opdrachtgever. Dat dat kennelijk niet voor iedereen voor de hand ligt, blijkt uit een recente uitspraak van een collega-architect: “ja hoor eens, de business snapt niet eens wat een niet-functionele eis is. Dus daar moet je ze helemaal niet naar vragen. Volgens mij moet je dat gewoon zelf een beetje proberen in te schatten.” Nou… volgens mij niet.)

En natuurlijk hebben we ook meer inzicht nodig in de impact van niet-functionele eisen op BI-architecturen, en in de manier waarop de verschillende alternatieven de gestelde eisen al dan niet kunnen adresseren. Eigenlijk wil je dus bij iedere oplossing (concept, architectuurstijl, methode, techniek) een bijsluiter hebben die aangeeft wat zijn doel is, wat de bijwerkingen zijn, en wat de contra-indicaties zijn. Aan de bedenkers en toepassers van nieuwe oplossingen de uitdaging om hun ervaringen te delen met de BI-community.

Tussen de oren

Maar uiteindelijk begint het allemaal bij de mindset: bij het inzicht dat niet alles een spijker is. Hopelijk gaan steeds meer BI-architecten de voordelen inzien van een gereedschapskist die meer bevat dan alleen een hamer.

©2010 42 Versions of the Truth. All Rights Reserved.

“Single version of the truth” vs “system of facts”

Bij traditionele datawarehouses, waar het centrale datawarehouse (CDW) de single version of the truth representeert, wordt binnenkomende data direct omgevormd naar een (generiek) bedrijfsmodel. Om als bedrijfsmodel te kunnen fungeren, moet het datawarehouse-datamodel op zichzelf staan, en zo min mogelijk bepaald worden door de bron.

Dit in tegenstelling tot het next gen EDW: daar is het CDW een “system of facts”, dat zich in hoge mate richt naar de modellering van de feiten in het bronsysteem.
Maar wat zijn dan die “feiten”? De gebeurtenissen in de werkelijkheid? Of de technische events in het systeem?

Interface vs implementatie

Dat klinkt als een non-issue: een bronsysteem wordt geacht te registreren wat er in de werkelijkheid gebeurt, dus werkelijkheid en systeem moeten wel 1:1 zijn. Maar wat het systeem naar buiten toe laat zien, hoeft niet overeen te komen met hoe e.e.a. onder de motorkap geregeld wordt.
Neem als voorbeeld een CRM-systeem: als de gebruiker in het systeem een klant laat verhuizen, en daartoe dus zijn straatnaam, huisnummer, postcode, woonplaats en telefoonnummer wijzigt, is dat in zijn beleving één feit: “klant 12345 verhuist van X naar Y”. Het is echter niet ondenkbaar dat het systeem dat ene feit in zijn data access layer implementeert als 5 verschillende databasetransacties. Wat registreren we nu als feit: 1 verhuizing, of 5 updates?
(Andere afwijkingen tussen interface en implementatie die je zoal kunt tegenkomen, zijn bijvoorbeeld slordige modelleringen - denk aan het opslaan van relaties tussen entiteittypen d.m.v. een onvolledige foreign key, zodat de bedoelde occurrence afgeleid moet worden in de applicatielogica - of performance-optimalisaties die de modellering en/of de data-inhoud beïnvloeden.)

Wat moeten we in het CDW vastleggen om het system of facts zuiver te houden? Kiezen we voor een technische of een functionele benadering?

Technische benadering

Bij een technische benadering richt je je naar de implementatie, oftewel: naar de systeemgebeurtenissen. Je haalt de data 1:1 uit de brondatabase, en slaat die op in het CDW. Je hanteert dus het technische datamodel als basis voor het CDW-model.

Collega en co-auteur Ronald Damhof heeft al eens over dit onderwerp geblogd, en toonde zich daarbij groot voorstander van de technische benadering. Het klinkt ook aantrekkelijk: je weet tenminste zeker dat je altijd alles binnenkrijgt, en nog op het laagste granulaire niveau ook, dus je kunt alle kanten op. Ook prettig: je hoeft je eigen project niet on hold te zetten tot de beheerders van het bronsysteem tijd hebben om een interface voor je te maken – gewoon een image copy trekken of een replicator laten meelopen, en klaar is Kees.

Tenminste, als Kees toevallig een bronsysteem aan het ontsluiten is wat alle informatie-inhoud in zijn data vastlegt. Want bij systemen waarvan interface en implementatie uit elkaar lopen, boet de data aan betekenis in als deze niet door de bril van de applicatielogica bekeken wordt. Wat je in dat geval binnenhaalt is geen granular data, het is less-than-granular: meer data, minder informatie-inhoud.
Er is dan ook geen sprake van dat je bij een technische benadering “no source-related programming” nodig hebt. René Veldwijk zei ‘t al: “technische trucs lossen geen logische problemen op”. Je ontkomt er niet aan om in het EDW - in de Big T, om precies te zijn - de ontbrekende applicatielogica alsnog op de data los te laten: niet eens om “extra” informatie te creëren, maar om überhaupt de informatiewaarde van de binnengehaalde data te reconstrueren. (En dan heb je toch weer die bronbeheerders nodig om je te vertellen hoe de data geïnterpreteerd moet worden.)

Functionele benadering

Bij een functionele benadering baseer je je op de interface van het systeem, ofwel: de gebeurtenissen in de werkelijkheid. Het conceptuele datamodel van de bron is dus het uitgangspunt voor het CDW-model. In de interfacing wordt eerst de real-world feiten gereconstrueerd vanuit de implementatie, door er de bijbehorende applicatielogica op los te laten; pas na die vertaalslag worden ze doorgesluisd naar het EDW.

Het EDW wordt daarmee bevrijd van een stuk complexiteit waar het sowieso niet de beste papieren voor had; en de Big T, van nature al geen lichtgewicht, wordt qua processing en beheerbaarheid in ieder geval niet extra belast.
Bovendien zal het weinig betoog behoeven dat een functioneel georiënteerd model een stuk robuuster c.q. veranderbestendiger is dan een technisch georiënteerde variant. De functionele benadering sluit aan bij diverse principes van goede software-architectuur, zoals information hiding en loose coupling.

En verder?

Zelf heb ik een sterke voorkeur voor de functionele benadering, maar misschien zijn er goede redenen om toch te kiezen voor de technische benadering. Ik ben zeer geïnteresseerd in de afwegingen die daarbij een rol spelen.
Ook zegt het bovenstaande nog niets over hoe de doelstellingen van het next gen EDW het beste gerealiseerd worden – is bijvoorbeeld traceerbaarheid beter gediend met een functionele of een technische benadering?

Ik ben benieuwd naar jullie mening over dit onderwerp.

©2010 42 Versions of the Truth. All Rights Reserved.

Om te beginnen pleit hij ervoor om het debat vanuit een positieve insteek te voeren. Juist nu we middenin een crisis zitten, is niemand gebaat bij een negatieve beeldvorming omtrent BI. Het leidt er alleen maar toe dat bedrijven de strategische voordelen van een excellente informatievoorziening mislopen, omdat ze BI afserveren als een dure hobby van IT die toch niets concreets gaat bijdragen. Zonde, en nergens voor nodig.

Waar zouden we zijn zonder…?

Verder zet hij scherp neer waarom de hele discussie eigenlijk een verkeerd uitgangspunt heeft: als uit onderzoek blijkt dat 33% van de topbestuurders twijfelt of zijn of haar bedrijf wel de juiste keuzes kan maken in het bestrijden van de gevolgen van de economische crisis, hoe kun je dan ooit onderbouwen dat BI voor hen geen toegevoegde waarde zou hebben?

Ik heb niet veel met de eeuwig terugkerende vraag naar de ultieme definitie van BI, maar als ik er een moet kiezen, dan die van Andries Bottema: “het inzetten van informatie als productiemiddel”. Zo bekeken, is het onzin om te stellen dat BI zich niet terugbetaalt. Het zou een no-brainer moeten zijn dat je niets kunt bereiken zonder informatie: hoe wil je anders je organisatie sturen? Hoe wil je operational excellence of customer intimacy bereiken zonder informatie?

De vraag of BI zich wel terugbetaalt, kan wat mij betreft dan ook met een wedervraag beantwoord worden: kan een organisatie eigenlijk wel zonder?

Ruimte voor verbetering

Dat vaststellen, is één – er handen en voeten aan geven is een tweede. Een valide vervolgvraag is dan “betalen concrete BI-implementaties zich altijd terug?” Daarmee opent zich een heel andere discussie. (De vraag of ROI eigenlijk wel altijd gemeten kan worden, en of BI nog andere voordelen heeft dan alleen financiële, laat ik maar even buiten beschouwing. Evenals de vraag of de gekozen onderzoeksopzet wel voldoende basis biedt voor het trekken van zulke stellige conclusies.)

Feit is dat BI-implementaties nog steeds niet altijd opleveren wat ervan verwacht werd. Deels komt dat doordat BI-projecten niet alleen maar een ICT-kant hebben, maar, zoals Daan van Beek in een latere nuancering zegt, “een mengeling van gedrag, managementmodellen en technologie [zijn], waarbij de kritische succesfactoren niet aan de technische, maar vooral aan de gedragskant liggen”.
Maar wat de oorzaken ook zijn, er is ruimte voor verbetering: we zouden veel waarde voor onze klanten kunnen toevoegen, maar kennelijk realiseren we die niet altijd. Waarom niet, en hoe kan het beter?

Dat lijkt me een mooi onderwerp voor vervolgonderzoek.

©2010 42 Versions of the Truth. All Rights Reserved.

De opgeworpen bezwaren snijden echter naar mijn mening geen hout in een datawarehouse-context. Om een modellering voor datawarehouses te beoordelen, zul je daar op z’n minst met een datawarehouse-bril naar moeten kijken. Dat lijkt een open deur, maar in dit geval lijken de auteurs eerder een OLTP-bril op te hebben. Het resultaat is een vertekend beeld van de sterktes en zwaktes van Data Vault.

Datawarehouse != OLTP

Het datamodel van een datawarehouse heeft een totaal andere rol dan dat van een OLTP-systeem.
Een datawarehouse doet niets anders dan elders gecreëerde gegevens ontvangen, opslaan en weer afstaan – en dat in grote hoeveelheden. Daarbij speelt verwerkingssnelheid een belangrijke rol, want de totale verwerking moet meestal binnen een beperkt batchwindow plaatsvinden. Verder weten we inmiddels dat het ETL-proces 70% van de totale ontwikkel- en onderhoudsinspanning en -kosten in beslag neemt; hoe beheer(s)baarder het proces is, hoe meer dat scheelt in de kosten.

Deze factoren bepalen de inrichting van het datawarehouseproces. Dat vertaalt zich in uitgangspunten als:

• liever vele simpele, gestandaardiseerde ETL-procedures dan een klein(er) aantal complexere, customized procedures
• inserts hebben de voorkeur boven updates
• eventuele datakwaliteitscontroles op de invoer doe je niet met database constraints, maar in het ETL-proces (aangezien dat meestal beter performt)
• zo min mogelijk onderlinge afhankelijkheden tussen laadprocedures: enerzijds om het proces overzichtelijk en onderhoudbaar te houden; anderzijds om maximaal te kunnen parallelliseren, wat bijdraagt aan de schaalbaarheid van het proces

Het datawarehouse-model is sterk bepalend voor de mate waarin deze uitgangspunten gerealiseerd kunnen worden. (Data Vault is speciaal ontworpen om maximale ondersteuning te bieden). Niets in het artikel wijst er echter op dat de auteurs deze rol van het datamodel hebben laten meewegen in hun beoordeling.

Laten we eens enkele van hun bezwaren onder de loep nemen.

Geen constraints

Verhagen en Vrijkorte zien het als een risico dat Data Vault relaties tussen entiteiten altijd weggeneraliseert naar n:m-cardinaliteit: daarmee valt immers de controle in de database op invoer van de juiste cardinaliteit weg.

Zoals gezegd: als je die controle al wilt uitoefenen, dan doe je dat in je ETL-proces, niet in de database (in tegenstelling tot wat de auteurs suggereren, is dat geen Data Vault-bedenksel, maar een geaccepteerde best practice in datawarehouseland).
De Data Vault-filosofie gaat echter nog verder: het centrale datawarehouse wordt beschouwd als een system of fact, dat *alle* aangeleverde gegevens moet kunnen verwerken – het oordeel “deugdelijk of niet” wordt pas onderweg naar de datamart geveld, op basis van de criteria van de eindgebruiker. Aan de poort worden dus überhaupt geen controles uitgevoerd (behalve om gegevens uit te filteren waar het systeem technisch niet mee uit de voeten kan, bijv. vanwege verkeerde gegevensformaten).
Een Data Vault-model moet dus kunnen omgaan met gegevens die eigenlijk een verkeerde cardinaliteit hebben. En dan is het juist heel verstandig – zo niet noodzakelijk – om a) zo min mogelijk constraints in het model op te nemen, en b) deze daar waar ze onvermijdelijk zijn zo ruim mogelijk te definiëren. Het gebruik van linktabellen, waardoor iedere relatie per definitie de ruimste cardinaliteit krijgt, is dan de meest logische maatregel.

Linktabellen vs foreign keys

Verder stellen Verhagen en Vrijkorte dat in sommige situaties¹ het gebruik van een linktabel “weinig toegevoegde waarde lijkt te hebben” (waarom dat zo zou zijn, wordt niet nader onderbouwd), en zijn van mening dat het “het beste lijkt” om maar gewoon een foreign key te gebruiken.

Ook nu wordt niet de impact meegewogen die modelkeuzes hebben op het ETL-proces. De meerwaarde van de linktabel zit hem nl. in de modelmatige ontkoppeling van de hubs, en daarmee van de bijbehorende laadprocedures. Hierdoor wordt het aantal synchronization points in het proces geminimaliseerd: eerst worden alle hubs parallel geladen, daarna alle links parallel, daarna alle satellites parallel. (Als er voldoende processing power voorhanden is, is het zelfs mogelijk om de hub-satellites gelijktijdig met de links te laden.)
Doordat de onderlinge wachttijd tussen jobs minimaal is, worden het batchwindow en de beschikbare resources optimaal benut; dit komt de schaalbaarheid van het proces ten goede.
Verder is het voor ontwikkeling en onderhoud van ETL-processen een voordeel als laadprocedures zo min mogelijk onderling afhankelijk zijn: de processen worden er flexibeler en minder complex van.

Door de hubs aan elkaar te knopen via foreign keys loop je al die voordelen mis, omdat de hubs nu noodgedwongen serieel moeten worden geladen. Het beslag op het batchwindow wordt daarmee groter dan nodig, en de schaalbaarheid van het proces loopt eveneens terug. Bovendien maakt de onderlinge afhankelijkheid het ETL-proces complexer, en dus slechter onderhoudbaar.

End user access?

Tenslotte noemen de auteurs nog als bezwaar dat Data Vault-modellen lastig bevraagbaar zijn door eindgebruikers. De observatie klopt - maar is het ook een probleem? De modellering is specifiek bedoeld voor het centrale datawarehouse, en daar heeft de eindgebruiker sowieso niets te zoeken. Is het een nadeel als in een restaurant de keuken niet even sfeervol is ingericht als de eetzaal?

Conclusie

Data Vault heeft zijn sterke en zwakke kanten; omdat het concept nog maar net in opkomst is, zijn met name over de zwaktes nog weinig ervaringsfeiten voorhanden.
Bij afwezigheid daarvan, kan discussie een uitstekend middel zijn om onze beeldvorming aan te scherpen - maar dan moeten we die wel voeren met geldige argumenten.

©2010 42 Versions of the Truth. All Rights Reserved.

Brononafhankelijkheid

Een datawarehouse moet (zo) brononafhankelijk (mogelijk) zijn: wijzigingen in de bronsystemen moeten zoveel mogelijk worden losgekoppeld van wijzigingen in de BI-omgeving.
Traditioneel wordt het datamodel van het centrale datawarehouse beschouwd als een belangrijke enabler voor brononafhankelijkheid. Het is een best practice om dit model niet te baseren op de datamodellen van de bronnen, maar op bedrijfsmodellen: informatiemodellen die de kern van het bedrijfsproces weten te vangen, ongeacht hoe dat proces op enig moment geïmplementeerd is. Daardoor wordt het datawarehouse-model in zekere mate generiek: er wordt als het ware op voorhand al rekening gehouden met toekomstige wijzigingen in de bron, zodat die geen aanpassing van het datamodel vereisen. Aanpassing van het ETL-proces is echter niet te vermijden, de brongegevens moeten immers omgevormd worden naar het generieke model.

Omslag

De Data Vault-aanpak staat daar haaks op. Er wordt geen poging gedaan om achterliggende bedrijfsprincipes te achterhalen en de feiten daar naartoe te modelleren: de feiten worden vastgelegd zoals ze binnenkomen. Op basis van een set vuistregels wordt een Data Vault-variant van het bronmodel geconstrueerd (en ook de ETL daar naartoe kan op die manier bepaald worden), maar inhoudelijk wordt er niets gewijzigd aan de gemodelleerde begrippen.
Met andere woorden: een Data Vault wordt volledig bronafhankelijk gemodelleerd!

Dat druist lijnrecht in tegen alles wat we weten over datawarehousing. In mijn huidige opdracht ben ik heel lang bezig geweest om die brongestuurde modellering te verenigen met het idee van een generiek datawarehouse-datamodel – we willen toch brononafhankelijkheid? Nou dan!
Totdat ik me realiseerde dat het in de Data Vault-architectuur zinloos is (zo niet contraproductief) om het centraal datawarehouse generiek te modelleren, omdat het in de overall omgeving een totaal andere rol speelt dan bij de traditionele aanpak.

Een andere kijk op het datawarehouse

We zijn gewend het centrale datawarehouse te beschouwen als de kern van de totale datawarehouse-omgeving, dé plek waar het allemaal gebeurt. Binnenkomende brongegevens worden onderweg naar het centrale datawarehouse omgemodelleerd, losgekoppeld van de bron, geïntegreerd, geschoond, etc. Het zwaartepunt van de processing, de “Big T” (als in: Transformatie met een grote T) bevindt zich dus aan de ingang van het datawarehouse.

In de Data Vault-architectuur daarentegen, speelt het centrale datawarehouse eigenlijk maar een ondergeschikte rol. De Big T, die in deze architectuur tussen het datawarehouse en de datamarts is gepositioneerd, is de kern van een Data Vault-datawarehouse: daar voeren we alle business logica uit, daar integreren we, daar schonen we.
En daar ligt ook het ontkoppelpunt met de bronnen. Als de bronnen wijzigen, moeten de gewijzigde gegevens nog steeds probleemloos ingelezen kunnen worden in het datawarehouse; maar wat er daarna mee gebeurt, wordt volledig bepaald in de Big T. Geheel in lijn met de Data Vault-principes, worden ook de gewijzigde gegevens niet zonder meer automatisch doorgeladen naar de datamart, maar alleen als de gebruiker daarom vraagt.

Impact

Maar als het ontkoppelpunt tussen bronnen en BI-omgeving binnen het datawarehouse komt te liggen, hebben bronwijzigingen toch wel degelijk impact op het datawarehouse-model?
Jawel – maar hoe erg is dat eigenlijk? Laten we eens bekijken hoe een en ander in de praktijk uitpakt.

Om de gewijzigde brongegevens in te passen in het datawarehouse-model, halen we ze door de modelleringsregels van de Data Vault: we zetten ze rechtstreeks om naar corresponderende hubs, satellites of links. (Een bronaanpassing zul je in een Data Vault vaak terugzien als nieuwe attributen in een bestaande satellite, of als nieuwe links en satellites die worden toegevoegd tussen de bestaande structuren.) Daardoor kan ook de ETL-verwerking het datawarehouse in rechttoe-rechtaan zijn; de gegevens kunnen vrijwel 1:1 geladen worden. (Dit deel van de ETL kan zelfs gegenereerd worden.)
De Big T, het meest complexe proces, hoeven we pas aan te passen als de gebruikers de gegevens in de BI-omgeving willen zien. Die klus doen we in ons eigen tempo, los van de bronwijziging.

Ook in een traditionele omgeving moet het ETL-proces aangepast worden. Maar daar wordt de zwaarste verwerking al aan de ingang van het datawarehouse gedaan: willen we dus de nieuwe gegevens überhaupt kunnen laden, dan hebben we geen andere keus dan direct de Big T onder handen te nemen – ook als we de nieuwe gegevens nog niet naar de datamarts hoeven door te zetten. En voor het uitvoeren van die complexe aanpassing, hebben we dan ook nog de releasedatum van het bronsysteem als deadline – want zodra de nieuwe interface operationeel wordt, moet het datawarehouse deze netjes kunnen verwerken, anders loopt het ETL-proces stuk.

Oftewel: in een Data Vault moet het datawarehouse-model weliswaar aangepast worden, maar de totale impact op de datawarehouse-omgeving is een stuk beter te beheren en beheersen. En dat is toch uiteindelijk de reden waarom we brononafhankelijkheid nastreven.

©2010 42 Versions of the Truth. All Rights Reserved.

Must have?

Zo stelt Erwin Vorwerk in het DB/M-themanummer dat volgens analisten meer dan 80% van alle beschikbare data in de categorie “ongestructureerd” valt: “[...] steeds meer directies realiseren zich dat hun Business Intelligence zich beperkt tot slechts 20 procent van de binnen een onderneming aanwezige data en dat men dus op basis van een beperkte blik beslissingen neemt. Daarmee neemt de vraag naar geïntegreerde data toe.”
Leidt ontsluiting van slechts 20% van alle data automatisch tot een beperkte blik? Anders gezegd: leidt 100% gegevensontsluiting automatisch tot betere besluitvorming? Ook als de percentages kloppen (hoe zijn die eigenlijk bepaald? Welke grootheden zijn er met elkaar vergeleken? aantallen bytes? aantallen records versus aantallen documenten?), zeggen ze op zichzelf nog niets: meer is niet altijd beter. Veel belangrijker is de kwaliteit en het relatieve belang van de gegevens, en daarmee de waarde die ze toevoegen aan de BI-omgeving.
Gestructureerde data ontsluiten we niet zomaar voor de heb, dat doen we alleen als we denken dat we er een concrete informatiebehoefte mee denken te vervullen, nu of in de toekomst. Voor ongestructureerde data zou hetzelfde moeten gelden - welk percentage van het totaal ze uitmaken, is daarbij niet relevant.

First things first

Daarmee wil ik overigens niet zeggen dat ongestructureerde informatie per definitie nutteloos is voor informationele doeleinden - hoewel ik er nog geen requirement voor ben tegengekomen, kan ik me voorstellen dat die er wel degelijk kan zijn. Maar ik vraag me af of we niet te veel tegelijk willen: de meeste organisaties hebben immers nog hun handen vol aan het leggen van een solide informationele basis met gestructureerde data (en lopen daarbij tegen de nodige moeilijkheden op). Zelfs de organisaties die op dat gebied voorop lopen, zijn nog maar net begonnen met het uitnutten van hun BI-omgeving. Want hij mag dan “maar” 20% van de totale gegevensverzameling omvatten, het is wel een goudmijn aan onontdekte informatie. Eentje die zich bij uitstek leent om er advanced analytics op los te laten, om maar iets te noemen.

Zijn we wel aan nieuwe avonturen met ongestructureerde data toe? Het is al een uitdaging op zich om het maximale uit de reguliere BI-omgeving te halen - ook zonder ongestructureerde gegevens valt daar voorlopig nog voldoende return on investment te oogsten.

©2010 42 Versions of the Truth. All Rights Reserved.

#1: “Zonder single version of the truth loopt alles in de soep”

Alles? Welnee. De salesmanager noemt iedereen aan wie hij ooit offerte heeft uitgebracht, een klant; de onderhoudsafdeling beschouwt alleen bedrijven met een supportcontract als klant, en de administrateur heeft het over klanten als hij eigenlijk debiteuren bedoelt. Allemaal kunnen ze prima hun werk doen, ondanks de mismatch tussen hun klantbegrippen.
Het wordt pas lastig als ze met elkaar in gesprek moeten over hun klanten: de communicatie tussen twee partijen wordt bemoeilijkt als beide een ander begrippenkader hanteren.

Toch hoeft het ontbreken van een gemeenschappelijk kader geen onoverkomelijk probleem te zijn. In informationeel opzicht hebben we wel vaker te maken met multiple versions of the truth die vreedzaam naast elkaar bestaan. Zo zijn boekhouding en datawarehouse meestal niet exact met elkaar in overeenstemming; maar in de praktijk is dat nauwelijks een probleem, omdat we (als het goed is) weten wat de verschillen zijn en hoe ze veroorzaakt worden.
De aanwezigheid van meerdere versies van de waarheid hoeft dus op zich geen problemen te geven. Zolang we in staat zijn om alle verschillende versies van de waarheid te onderhouden, ze nauwkeurig te definiëren, en het verschil tussen twee versies te herleiden en te verklaren, is er niets aan de hand. Pas als niet duidelijk is wat de verschillende versies precies betekenen, hoe ze afgeleid zijn, en hoe ze van elkaar verschillen, is er reden tot zorg.

#2: “Als we alles in het datawarehouse zetten, hebben we een single version of the truth”

De term “single version of the truth” wordt vaak vertaald naar een notie van een soort BI-universum: een informationele omgeving (meestal op basis van een datawarehouse) waarin alle mogelijke en bekende interpretaties van de bedrijfsbegrippen worden ondergebracht, allemaal met een heldere definitie en onder een eigen, unieke benaming. Daardoor is voor alle gebruikers van de omgeving duidelijk welke begrippen er in omloop zijn; wat ze precies betekenen; en op welke begrippen een bepaalde rapportage betrekking heeft.
Zoveel duidelijkheid in een informationele omgeving is al een hele stap in de goede richting - maar mogen we ook echt spreken van een single version of the truth?

Laten we als voorbeeld een BI-omgeving voor een winkelorganisatie in gedachten nemen. In de organisatie worden zo’n 14 verschillende definities voor het begrip “omzet” gehanteerd, allemaal met een net iets andere afleiding.
In lijn met de hierboven beschreven “BI-universum”-aanpak analyseren we wat ieder begrip betekent en hoe het afgeleid wordt; vervolgens geven we er een unieke, onderscheidende benaming aan: klantomzet, weekomzet, actieomzet, enzovoort. We kunnen nu alle omzetbegrippen naast elkaar beschikbaar maken in onze fictieve BI-omgeving.
So far so good. Maar zijn we nu ook iets opgeschoten als het gaat om onderlinge verstaanbaarheid en vergelijkbaarheid? “Hoera, de omzet per klant is met 20% gestegen! ” “Nee, het gaat hartstikke slecht, want de weekomzet is met 10% gedaald!”. Mars en Venus in de BI-omgeving: iedereen richt zich nog steeds naar zijn eigen setje begrippen, zijn eigen waarheid. Om echt te kunnen spreken van één versie van de waarheid, is meer nodig dan het hernoemen en samenvoegen van alle begrippen tot één grote verzameling definities.
En daarmee hebben we het derde misverstand te pakken:

#3: “Het creëren van een single version of the truth is een IT-probleem”

Veel datawarehouseprojecten krijgen bij aanvang de inrichting van een single version of the truth mee als doelstelling. De BI-afdeling is echter niet de juiste partij om dit probleem aan te pakken. Zolang iedereen zijn eigen stukje van de verzameling blijft gebruiken, is er van één versie van de waarheid geen sprake, hoe veelomvattend je de verzameling ook maakt. De enigen die daar verandering in kunnen brengen, zijn de gebruikers van de definities zelf. De BI-afdeling kan geen unanieme adoptie van werkelijk gemeenschappelijke definities afdwingen; het creëren van een single version of the truth is daarmee in de kern een businessvraagstuk. Zolang onze gebruikers het onderling niet eens zijn over hun gezamenlijke definities, kunnen wij niet meer doen dan al hun waarheden ondersteunen.

#4: “Zonder single version of the truth zullen we elkaar nooit begrijpen”

Als het op onderlinge verstaanbaarheid en vergelijkbaarheid aankomt, zijn gebruikers meer gebaat bij een “common version of the truth” dan bij een single version. Het is niet nodig om alle definities te vervangen door die ene canonieke set waar iedereen mee door de bocht kan - als zoiets al haalbaar zou zijn. Het doel wordt al bereikt als men tot overeenstemming weet te komen over een verzameling van standaarddefinities die gehanteerd kan worden voor alle afdelingsoverstijgende en bedrijfsbrede rapportages. Op afdelingslokaal niveau kan iedereen dan gewoon als vanouds zijn eigen versie van de waarheid blijven hanteren; de “common version of the truth” wordt dus één van de vele ondersteunde waarheden.

Implementatie van een single version of the truth is niet de enige manier om de informatiebehoeften van onze gebruikers optimaal te ondersteunen, en al helemaal niet de enige juiste. Hoog tijd dus om het begrip zijn mythologische status te ontnemen.

©2010 42 Versions of the Truth. All Rights Reserved.

Real-time - really?

Zo vraag ik me af of het belang van “real-time” informatielevering in de praktijk wel zo groot is als het kennelijk gevoeld wordt door de ondervraagden. Dat gegevens op het juiste moment beschikbaar moeten zijn, spreekt vanzelf; maar “actueel” en “just-in-time” is niet hetzelfde als “real-time”.
Real-time informatie is noodzakelijk als er op de (zeer) korte termijn beslist en gehandeld moet worden. Als een vrachtwagen na een uur wachten bij het magazijn nog steeds niet gelost is, dan moet de juiste persoon gealarmeerd worden, zodat die direct actie kan ondernemen. In zo’n geval heb je niets aan een rapportje wat dagelijks om 9 uur ververst wordt.
Daarentegen heeft het type informatie waar in het artikel sprake van is, nl. marktontwikkelingen en veranderende regelgeving, in het algemeen een langere invloedshorizon; we spreken dan eerder in termen van dagen, weken, zo niet maanden. Als uit onderzoek blijkt dat de consument het laatste halfjaar steeds vaker en gemakkelijker van telefoonaanbieder wisselt, dan wil je daar als provider natuurlijk op inspelen – maar maakt het daarbij verschil of die informatie vandaag, morgen of na het weekend op het juiste bureau terechtkomt? Het is moeilijk voor te stellen hoe real-time informatievoorziening daarin een cruciale voorsprong zou kunnen geven.

Verbeteren - maar hoe?

Maar ook als real-time informatieverschaffing geen noodzaak is, kan de actualiteit van de geleverde informatie nog steeds te wensen over laten. Als het rapport over consumentengedrag niet vandaag of morgen op het juiste bureau ligt, maar pas na drie maanden, loopt het bedrijf inderdaad kansen mis. De voor-de-hand-liggende vraag is dan: als de ict-verantwoordelijken zelf al aangeven hier ontevreden over te zijn, waarom doen ze er dan niets aan? Het is tenslotte hun verantwoordelijkheid – als zij het niet doen, wie dan wel?
Dat vraagt gewoon om nader onderzoek. Blijkbaar zijn veel ict-afdelingen onvoldoende in staat om hun gebruikers van actuele informatie te voorzien; waar ligt dat aan? Wat is er voor nodig om daar verbetering in te brengen? Helaas, het Progress-onderzoek stopt net als het interessant wordt.

Het is in ieder geval te hopen dat organisaties bij het verbeteren van hun informatievoorziening verder zullen kijken dan de invoering van wéér een nieuw softwarepakket (al dan niet van Progress). Het stadium van “met een nieuwe tool verdwijnen al uw problemen als sneeuw voor de zon” zijn we nu toch zo langzamerhand wel voorbij.

Toch?

©2010 42 Versions of the Truth. All Rights Reserved.

Wat in die publicaties echter onderbelicht blijft, is dat Data Vault veel meer is dan “alleen maar” datamodellering. Het geeft je niet alleen een uitstekend gereedschap in handen om je centrale datawarehouse te modelleren: het is ook een architectonische visie op de rol van het data warehouse in de overall BI-omgeving.

Eigenlijk is het eigenaardig dat die andere kant van Data Vault tot dusver in het openbaar wat op de achtergrond is gebleven. Want juist die andere kant biedt een radicaal andere visie op datawarehousing dan momenteel gangbaar is - één die naar mijn mening een hoop meerwaarde voor het vakgebied zou kunnen bieden.
(”In het openbaar”, want de visie van Linstedt komt uitvoerig aan de orde tijdens de Data Vault certificatiecursus. Wie de cursus niet gevolgd heeft, moet het doen met Linstedts blog, waarin hij zijn kijk op de veranderende rol van het datawarehouse beschrijft.)

System of fact

In de Data Vault visie verschuift de rol van het datawarehouse van gegevensintegrator naar “system of record”, of, in de terminologie waar Linstedt de voorkeur aan geeft, “system of fact”. Uitgangspunt is dat alle data altijd geladen wordt: “100% of the data 100% of the time”. Er vindt geen cleansing plaats, geen uitval vanwege gebrekkige kwaliteit, geen toepassing van business rules, geen data-integratie.
(Overigens vindt wel datamodelintegratie plaats: d.w.z. entiteiten uit onderliggende bronsysteemmodellen worden tot één Data Vault entiteit samengevoegd als ze qua grain overeenkomen, maar er vindt geen inhoudelijke merge plaats).

De toepassing van business rules, en alle activiteiten ten behoeve van cleansing, merging en integratie van data worden in de Data Vault aanpak gepositioneerd tussen het datawarehouse en de datamarts. Argumentatie daarbij is dat de gebruikers uiteindelijk eigenaar zijn van de gegevens, niet IT; en dat het dus de gebruiker is die bepaalt hoe je van data informatie maakt, niet de IT-afdeling.
Op zichzelf is dat geen sterk argument: immers, ook als de gebruikers de regels bepalen, is het nog steeds prima denkbaar dat die regels direct al bij binnenkomst van de data worden toegepast. In het licht van de veranderlijkheid van requirements en business rules, is het echter wel verstandig om je bij het inrichten van je datawarehouse niet te laten leiden door het laatste inzicht van de gebruikers t.a.v. de relevante bedrijfsbegrippen: het datawarehouse is idealiter proces- en requirementsonafhankelijk. Linstedt bereikt dit door simpelweg de gegevens (de facts) vast te leggen zoals ze binnengekomen zijn, zonder al bij vastlegging een poging te doen tot interpretatie ervan; want die interpretatie is per definitie gedreven door de inzichten van vandaag, en daar wil je het system of record niet op inrichten.

Compliance

Deze tolerante, proces-agnostische houding ten opzichte van de binnengekomen data is volgens Linstedt onontbeerlijk, wil het datawarehouse compliance met initiatieven als Sarbanes-Oxley, Basel-II etc. kunnen ondersteunen. Dit vereist o.a. dat gerapporteerde gegevens auditable zijn; met andere woorden, van een gerapporteerd gegeven moet nagegaan kunnen worden, hoe het tot stand is gekomen. Bronsystemen houden zelf meestal geen historie bij, dus het datawarehouse is de enige historische opslagplaats voor alle brongegevens. Worden de gegevens bij binnenkomst bewerkt op basis van business rules, dan wordt de audit trail naar het oorspronkelijke brongegeven doorbroken. Compliance vereist dus vastlegging zonder interpretatie.

Parallelle werkelijkheden

Doordat de integratie van gegevens en de toepassing van business rules niet meer in het datawarehouse verankerd zijn, maar pas onderweg naar de datamarts plaatsvinden (áls dat al gebeurt), representeert het datawarehouse niet langer “one version of the truth”, maar eerder “one version of the facts”. Dat geeft ruimte om meerdere parallelle “versions of the truth” af te leiden, ieder geheel toegesneden op de wensen van zijn gebruikers. De Data Vault aanpak sluit daarmee aan bij de (steeds luider wordende) tegengeluiden tegen de heilige graal van de “single version of the truth”: het is bepaald geen sinecure om een single version of the truth neer te zetten, en bovendien is het nog maar de vraag of onze gebruikers daar eigenlijk wel zo goed mee geholpen worden.

New kid on the block

Al met al wijkt de Data Vault aanpak dus aanzienlijk af van hoe we tot dusver onze datawarehouses ingericht hebben. Van Kimball hebben we geleerd om “one version of the truth” te creëren met behulp van conformed dimensions; en ook Inmon gaat uit van een geünificeerde kijk op geïntegreerde gegevens. (Het is in dat verband interessant om op te merken dat Inmon weliswaar zijn goedkeuring uitspreekt voor Data Vault als “the optimal choice for modeling” voor zijn DW 2.0, maar dat het DW 2.0-concept nog steeds voorziet in een integrated sector die data bevat die “[...] is used and understood universally across the corporation”.)

Na zelf jarenlang gewerkt te hebben in traditionele datawarehouse-omgevingen, geeft mijn huidige opdracht me een mooie gelegenheid om de Data Vault aanpak zelf te beproeven en te vergelijken met de gangbare praktijk.
De “system-of-record”-invalshoek om het datawarehouse zo proces- en requirementsonafhankelijk mogelijk te maken, is zeker nader onderzoek waard; maar het ontbreken van afgedwongen gegevensintegratie vormt een behoorlijke beheersuitdaging. “Multiple versions of the truth” kunnen gemakkelijk ontaarden in een onoverzichtelijke, onbeheersbare wirwar van losse data-silootjes - net als in het pré-datawarehousetijdperk. (Is een datawarehouse dat op afroep iedere gewenste realiteit kan produceren, eigenlijk wel compliant?)

Kortom, het belooft een interessant project te worden.

©2010 42 Versions of the Truth. All Rights Reserved.

Folksonomy

Tagging heeft waarde voor onszelf als individuen, omdat het ons in staat stelt om die gegevens (foto’s, filmpjes, blogposts, links) die voor ons van belang zijn, te ordenen volgens een indeling die het best bij onze eigen belevingswereld aansluit. Dat je niet gebonden bent aan 1 categorie, maar net zoveel tags aan een gegeven kunt hangen als je zelf zinnig vindt, is daarbij een groot voordeel.
Tagging is daarnaast succesvol als sociaal instrument, doordat het mensen met een gedeelde belevingswereld en interesse met elkaar verbindt in termen van hun specifieke, gedeelde vocabulaire. Daarin schuilt ook een belangrijke beperking: lang niet iedere gedeelde interesse vertaalt zich naar een gedeeld vocabulaire. Als je op Flickr zoekt naar foto’s van wat mensen in hun tas meeslepen (om maar een doorsnee zoekopdracht te noemen), dan kun je die vinden onder de tag “whatsinmybag“, “whatsinyourbag“, “whatisinmybag“, “whatisinyourbag“, en wie weet, misschien ook wel onder “lookwhatsinmybag” of “kijkeenswaterinmijntaszit” (of “kijkeenswaterinmetaszit” - in de folksonomy is alles geoorloofd). Het is dus te hopen dat je geen totaaloverzicht van alle tassen-met-inhoudsfoto’s nodig hebt, want dat zit er niet in - in ieder geval niet op basis van tagging.
Keerzijde hiervan is dat eenzelfde tag door verschillende individuen voor andere begrippen gebruikt kan worden. Zo vind je bij Flickr onder de tag “notebook” zowel foto’s van notitieboekjes als van laptops.

BI: eenduidigheid is alles

Het is niet voor niets dat sites die belang hebben bij compleetheid, correctheid en eenduidigheid van informatie, tagging niet of maar in beperkte mate aanbieden. Denk bijvoorbeeld aan Wikipedia: lemma’s worden gecategoriseerd in een opgelegde structuur, zonder ruimte om eigen tags te definiëren en aan artikelen te hangen. Denk ook aan Marktplaats, waar advertenties in strikte, voorgedefinieerde categorieën ondergebracht zijn. Uiteraard is die strakke indeling in het belang van zowel aanbieder als geïnteresseerde: hoe zou je een 5 jaar oude zilvergrijze Polo moeten taggen om zoveel mogelijk geïnteresseerden te trekken? En op welke tags zou je moeten zoeken om precies die 5 jaar oude zilvergrijze Polo te vinden?

Dit is exact de reden waarom we er in BI-land zo aan hechten om strakke definities af te spreken en business metadata vast te leggen. Het zijn nou juist de verschillen in begrippenkader tussen gebruikers onderling die voor problemen zorgen. Zo hebben binnen een onderneming de meeste afdelingen en gebruikersgroepen wel op één of andere manier interesse in de klant; bij doorvragen zou echter weleens kunnen blijken dat ze allemaal iets anders onder “klant” verstaan. Voor de salesmanager is een klant iedereen aan wie hij ooit een offerte heeft uitgebracht, voor de debiteurenadministratie is het iedereen die ooit een factuur toegezonden heeft gekregen, etc. Is er een taggingmechanisme beschikbaar, dan zullen al deze gebruikers het labeltje “klant” op hun klantconcept plakken. Zijn de tags zichtbaar voor alle gebruikers, dan is de spraakverwarring niet te overzien - jammer van al die moeite die we in het conformeren van de dimensies hebben gestoken.

Slagroom op de taart

Vanuit BI-oogpunt schuilt het gevaar hem dus met name in de communicatie tussen groepen met verschillende begrippenkaders. Voor deze communicatie zal altijd een eenduidige, geformaliseerde begrippenstructuur nodig zijn. Tagging leent zich hier niet voor. Als je het sociale aspect achterwege laat, zouden tags echter prima bruikbaar kunnen zijn als aanvulling op de formele structuur. Tags stellen individuele gebruikers(groepen) in staat om meer grip te krijgen op de voor hen bestemde informatie. Gebruikersgroepen die intern een benaming hanteren die het niet gehaald heeft als businessdefinitie in de formele structuur, kunnen d.m.v. tags alsnog hun eigen vertrouwde terminologie loslaten op hun rapportages.
In het hierboven aangehaalde voorbeeld, zouden alle afdeling de tag “klant” aan hun klantgerelateerde rapporten mogen hangen, ook al zou de klant van Sales in de BI-omgeving eigenlijk “prospect” heten.

Als bonus kan tagging ons, “de makers”, meer inzicht geven in de denkwereld van onze gebruikers. Analyseer hoe de gebruikers hun gegevens taggen, en ontdek dat de hele onderneming businessterm B gebruikt, hoewel businessterm A tijdens de informatie-analyse als beste uit de bus kwam. Ontdek ook dat afdeling 1, 2 en 3 hun rapporten allemaal taggen met begrip C, terwijl ze eigenlijk resp. D, E en F bedoelen. Hoe beter we de gebruiker kennen, hoe beter we hem kunnen ondersteunen.

(A)sociaal

Tagging kan dus wel degelijk nut hebben voor BI-omgevingen, maar dan wel zonder het sociale aspect wat in Web 2.0 zo belangrijk is. Het zou interessant zijn om te onderzoeken of dat ook opgaat voor andere Web 2.0-kenmerken die relevant zijn voor BI 2.0; maar dat is voer voor een toekomstige blogposting.

©2010 42 Versions of the Truth. All Rights Reserved.