Voor veel eindgebruikers in de organisatie is het kunnen beschikken over goede managementinformatie van levensbelang. Dat dan ook vaak behoefte is aan data-integratie wordt ook nog wel begrepen. Maar dat voor een structurele en toekomstvaste oplossing deze behoefte vertaald dient te worden in de implementatie van een integratieplatform of datawarehouse kan vaak op minder begrip rekenen. Behalve een gebrek aan begrip voor de noodzaak, wordt vaak de nadruk gelegd op de kostbaarheid en de lange implementatietijd van een dergelijke laag.
Met de komst van het modelleringsconcept data vault kan juist uitstekend invulling worden gegeven aan een aantal voor de business zéér relevante behoeften en kunnen bovendien de kosten en implementatietijd sterk worden verminderd. In het kort kan data vault worden omschreven als een brongeoriënteerde opslagstructuur van bedrijfsdata die dermate generiek is dat scriptgeneratoren en toolkits ontwikkeld kunnen worden om creatie en laden van een datawarehouse te automatiseren met behoud van historie.
Belangrijke voordelen van het generieke data vault-model zijn het parallel kunnen laden van enorme volumes aan data (petabytes) en de lineaire uitbreidbaarheid van het model wanneer nieuwe bronnen moeten worden ontsloten. Dit levert zowel beter planbare business intelligence-projecten, beperking voor de ontwikkeltijd als een sterke kostenreductie op.
Uit bovenstaande punten wordt duidelijk dat data vault in eerste plaats de business helpt doordat nu veel sneller kan worden beschikt over nieuwe rapportages, simpelweg omdat de implementatiedoorlooptijd van het datawarehouse enorm kan worden ingekort. Door het opzetten van een goede BI-architectuur en snellere oplevering van het eerste increment, kan de business eerder tevreden worden gesteld en kan het systeem vervolgens doorgroeien.
Als de integratielaag veel sneller kan worden geïmplementeerd blijft er veel meer tijd én geld over voor datgene waar de business behoefte aan heeft, namelijk het verrichten van informatie-analyse, de fit-gap-analyse in relatie tot de aanwezige informatie, het ontwikkelen van rapportages en het begeleiden van gebruikers in het begrijpen en gebruiken van de rapportages.
Door als het ware historie op te slaan van de bron, wordt het veel eenvoudiger om de herkomst van data te kunnen achterhalen en om wijzigingen te kunnen bestuderen die diezelfde data heeft ondergaan in de loop van de tijd. Bedrijven die ervaring hebben met data vault hoeven aantoonbaar minder energie te steken in het achterhalen van de origine van de in de rapportage gepresenteerde informatie. Sterker nog, data vault vergroot de analysemogelijkheden op de brondata en maakt daarmee eerder verborgen gebleven bronsysteemproblematiek transparant.
Traditioneel ontworpen datawarehouses zijn niet tot zeer slecht uitbreidbaar wanneer sprake is van fusies en overnames en dus nieuwe, vreemde bronnen moeten worden ontsloten. Juist in deze situaties heeft de business extra veel belang bij het daadwerkelijk integreren van de nieuwe partij. De eerder genoemde lineaire uitbreidbaarheid van het data vault-model is bij uitstek geschikt om in dergelijke situaties het datawarehouse eenvoudig en efficiënt uit te breiden.
Om in deze tijd blijvend toegevoegde waarde te kunnen bieden is het nodig om veel data snel, gecontroleerd en geïntegreerd te kunnen aanbieden. Met data vault kan hiervoor de basis worden gelegd.
De voordelen die Data vault met zich mee brengt op het gebied van compliance en schaalbaarheid lijken me helder.
Een kantekening is nog wel op zijn plaats: (een deel) van de integratie (en opschoning?) complexiteit verhuist ten opzichte van “traditionele datawarehouses” naar achter de hiergenoemde datawarehouse laag. Hierdoor kan de implementatietijd van de datawarehouse laag sterk verminderen. Dat betekent echter wel dat deze logica in een laag daarna (staging-out of datamart) moet worden ge?mplementeerd.
He Pieter, duidelijk artikel. Goed geschreven – mooi stukje werk. Nippur was en is een early adopter van Data Vault. Ben heel benieuwd naar jullie ontwikkelingen op dit gebied.
Voor diegenen die meer willen weten over DV verwijs ik naar de artikelen die ik samen met Lidwine van As heb geschreven in DB/M: http://www.prudenza.nl/nl/library
M.b.t. Sjoerd Janssen; terechte opmerking en helaas geeft DV niet heel veel aanwijzingen omtrent de datamart strategie en deployment. Het tweede artikel in bovenstaande link gaat daar expliciet op in.
Verder zou ik er nog op willen wijzen dat DV te vaak wordt neergezet als een vorm van modellering perse wat nogal wat problemen in het ontwerp en de uitvoering geeft. DV moet vooral een onderdeel zijn van een strak architectuur ontwerp waar techniek, organisatie en processen op elkaar zijn aangesloten. Een klein voorbeeld van iets dergelijks heb ik net beschreven op mijn blog:
http://www.b-eye-network.com/blogs/damhof/archives/2009/06/who_owns_the_da.php