Logisch Data Warehouse
De logica van een logisch data warehouse Laatst bijgewerkt: 26 januari 2017

In eerdere blog artikelen ben ik uitgebreid ingegaan op het logisch data warehouse (op basis van datavirtualisatie) en de voordelen ervan. De sleutel tot het succes van deze architectuur is een perfecte “ontkoppeling” tussen gegevensbronnen en informatieproducten als rapportages en dashboards. Die ontkoppeling bereik je echter niet zomaar, daar moet je wel iets voor doen. Ook bij een logisch data warehouse moet je goed nadenken over de logica in je architectuurlagen. Maar wel anders dan bij een ‘klassiek’ data warehouse. Ik leg graag uit hoe…

Geen vaste aanpak

Hoewel bij een klassiek data warehouse ook sprake is van ontkoppeling, is het daar niet de essentie van de architectuur. Vaak zijn ETL-processen vervlochten met het informatiemodel en is veel van de business logica in de semantische laag van één of meerdere BI-tools vastgelegd. Dit gebrek aan ontkoppeling zorgt er voor dat het aansluiten van nieuwe databronnen of nieuwe rapportagetools complex en tijdrovend is. Om BI-tools te ontkoppelen gebruikt het logisch data warehouse een ‘centraal informatiemodel’. De ontkoppeling van databronnen gebeurt op basis van een ‘geïntegreerd dataoverzicht’, ongeacht techniek en locatie van de bron. Daarbij wordt niet één vaste aanpak afgedwongen. Het informatiemodel en dataoverzicht kunnen geheel virtueel opgezet zijn, maar ook gedeeltelijk fysiek en voor de rest virtueel.

Flexibiliteit in uitvoer

Nieuwe databronnen kunnen in een logisch data warehouse eenvoudig aangesloten en – gecombineerd met andere data – aangeboden worden. Of het nu gaat om big data, een webservice of een bestaand data warehouse. De architectuur kenmerkt zich ook door de flexibiliteit in uitvoer. Alle business logica ligt immers vast in het centrale informatiemodel. Vanuit dit model kan informatie in allerlei vormen worden aangeboden. Via een webservice of API, een datalevering aan een externe partij of een virtuele data mart. Alle vormen van informatiegebruik worden vanuit één uniform model ondersteund: standaardrapportages, vrije keuze in BI-tooling en het zelfstandig combineren en analyseren van data. De voordelen hiervan zijn goed beschreven in dit artikel van Mattijs Voet.

Datavirtualisatie

Om succesvol een logisch data warehouse te implementeren, is het essentieel om de ontkoppeling tussen databronnen en informatieproducten gestructureerd en – natuurlijk – logisch in te richten. Anders dan bij een klassiek data warehouse doen we dat niet in fysieke lagen waartussen data wordt gekopieerd en getransformeerd om uiteindelijk aansluiting te vinden op de rapportages en dashboards. Hier zijn geen vaste architectuurlagen zoals een operationeel data store, pre-staging area, staging area of data mart, maar juist de ruimte voor meerdere manieren van dataverwerking, fysiek of virtueel. Alle data komt uiteindelijk samen in het centrale informatiemodel van het logisch data warehouse. Daarbij wordt de kracht van datavirtualisatie optimaal benut en gecombineerd met historische data uit bronsystemen of een data warehouse.

Data warehouse

Logische lagen

Om de beste en meest beheersbare ontkoppeling te realiseren in je logisch data warehouse, is het verstandig om je architectuur wel uit een aantal logische lagen op te bouwen. Dit heeft als voordeel dat gelijke functies generiek kunnen worden uitgevoerd voor alle data uit alle bronnen. Alleen zijn hier de lagen grotendeels virtueel en alleen waar nodig fysiek. Zonder logische opbouw loop je het risico dat je niet optimaal profiteert van je nieuwe opzet, omdat je het overzicht kwijt raakt en er chaos ontstaat. En chaos leidt tot allerlei nadelen (kostbaar onderhoud, lange time to market, niet flexibel) die we kennen van veel klassieke data warehouses en die wilden we nu juist wegnemen.

Functies

Hoe bedenk je de beste architectuur voor je logisch data warehouse? Door je, net als bij ieder ander data warehouse, tijdens het opbouwen, uitbreiden en onderhouden voortdurend af te vragen wat de impact van wijzigingen is op de functies die je data warehouse ondersteunt. Dat kan een eenvoudige functie zijn: “ik wil de maandrapportage kunnen opbouwen met data uit zowel bron A als B en ik wil daarbij inzicht hebben in iedere wijziging in de boekhouding.” Of een complexere functie als “ons bedrijf is gefuseerd, we gaan onze operationele systemen samenvoegen en oude systemen stapsgewijs uitfaseren, maar de continuïteit van onze rapportage en analyse omgeving moet gegarandeerd zijn.” Dit zijn twee heel verschillende voorbeelden en de eerste is concreter en eenvoudiger dan de tweede, maar beide hebben invloed op de keuzes die je gaat maken in de opbouw van je logisch data warehouse.

 

Logisch data warehouse Kadenza

Voorbeelden

Aan wat voor functies moet je dan denken bij het uitwerken van de functionele lagen van je architectuur? Een paar voorbeelden die je vaak tegenkomt:

  • Het opbouwen van historische informatie
  • Data-elementen uit verschillende databronnen samenvoegen en aanbieden in een informatiemodel
  • Het tonen van de herkomst en opbouw van informatie in rapportages (traceerbaarheid)
  • Inzicht geven wie toegang heeft tot gegevens en wat er mee gebeurt (auditeerbaarheid)
  • Het toepassen van business rules en rekenregels op data
  • Informatie volgens een bepaalde frequentie kunnen leveren (real-time, batch)

Functionele architectuur

Het vaststellen van de functies van je logisch data warehouse is een continu proces. Door bij iedere nieuwe wens of wijziging (bijvoorbeeld in een bronsysteem) de functies onder de loep te nemen weet je wat nodig is om de wens of wijziging te realiseren. Zo ontstaat een functionele doelarchitectuur die per onderdeel technisch uitgewerkt kan worden. Ik beschrijf hieronder een aantal functionele lagen die je kunt toepassen in je functionele architectuur. In een volgende blog post zal ik verder ingaan op de technische vertaling van deze lagen.

1. Connectielaag (virtueel)
Deze laag legt verbinding met de bronsystemen en selecteert de benodigde bronobjecten (views/tabellen). Hier vindt ook een eventuele vertaling plaats van betekenisloze naamgeving in een bronsysteem naar voor de ontwikkelaar begrijpelijke namen. Het uitgangspunt is dat deze laag virtueel is.

2. Datalaag (virtueel tenzij)
In deze laag wordt data binnen één bron en daarna van bronnen onderling geïntegreerd naar een relationeel bedrijfsmodel waarvan de entiteiten gebaseerd zijn op de bedrijfsprocessen. Omdat dit bedrijfsmodel minder vaak wijzigt dan de bronsystemen, realiseren we hiermee al een eerste ontkoppeling van de bronsystemen. Ook bij deze laag is het uitgangspunt virtueel, behalve als het van belang is om historie op te bouwen die door het bronsysteem niet te leveren is. In dat geval kunnen we kiezen voor een ETL-aanpak met fysieke opslag zoals we die kennen uit het klassieke data warehouse.

3. Data mart laag (virtueel/hybride)
Hier worden voor de verschillende informatiedomeinen data marts gemaakt. Hierbij wordt data getransformeerd vanuit het bedrijfsmodel naar het specifieke informatiedomein op basis van business rules en rekenregels. Een data mart is altijd virtueel. Wordt een data mart opgebouwd uit een selectie van zowel virtuele als fysieke tabellen uit de datalaag, dan spreken van een ‘hybride’ opbouw. Eventueel kan vanuit een datamart ook nog een deellevering worden vastgelegd voor verfijning naar bijvoorbeeld een afdeling of toepassing die de data gaat gebruiken.

4. Analysemodel (virtueel of fysiek)
In deze laag worden aggregaties en afleidingen van data uit een data mart vastgelegd. Als voorbereidend werk voor de opbouw van specifieke rapportages of om analisten werk uit handen te nemen. Een analysemodel kan een gefilterd en/of geaggregeerd informatiemodel van een data mart zijn voor een specifieke taak of doelgroep. Een kubus is een goed voorbeeld van een analysemodel.

5. Metrics en dashboards (fysiek)
In deze laag worden voorgedefinieerde rapportages en dashboards opgebouwd en beheerd. Denk bijvoorbeeld aan rapporten in PowerPivot-Excel of Tableau, of een dashboard in PowerBI.

6. Consume-laag
In deze laatste laag gaat het om het consumeren van informatie door gebruikers in de vorm van rapporten of andere informatieproducten, zoals een analyse-kubus. Hier wordt de levering en presentatie van rapportages en analyses in verschillende toepassingen georganiseerd. Bijvoorbeeld de beschikbaarheid van een rapport in een mobiele app of een analyse tool. Maar ook de verstrekking van een data mart voor self service analytics en data discovery. In de consume-laag vindt ook de toegangscontrole plaats waardoor iedereen alleen datgene ziet wat hij wil of mag zien. Wie mag waar bij en welke informatie moet gefilterd of gemaskeerd worden voor bepaalde gebruikers?

Dataclassificaties

Er is zeker niet één ideale architectuur voor een logisch data warehouse. Het mooie is juist dat je de architectuur kunt optimaliseren voor jouw specifieke situatie. Een aanpak die je daarbij kan gebruiken is die van dataclassificatie. Daarbij inventariseer je als eerste de bestaande situatie. Hoe is data georganiseerd? Hoe wordt data gebruikt? Welke informatiewensen zijn er? Vervolgens beschrijf je de kenmerken van bestaande gegevensverzamelingen en bepaal je welke rol ze in je nieuwe architectuur spelen. Als laatste leg je de relatie tussen de herkomst van data en de beoogde informatiewensen. Welke vraag gebruikt welke data? Is die data daar voor geschikt en wat moet ermee gebeuren? Op deze manier werk je gestructureerd toe naar onderbouwde keuzes voor je architectuur.

Consequent toepassen

Datavirtualisatie speelt een grote rol in een logisch data warehouse. Ook voor de virtuele database is er niet één beste manier van inrichten. Inrichtingskeuzes zullen per project, toepassing of domein anders zijn. Bovendien wordt het aanbrengen van structuur niet afgedwongen, daar moet je zelf voor zorgen. En dat kun je vooraf maar beter goed doen, want anders is het binnen de kortste keren chaos! Je functionele architectuur is uiteraard het uitgangspunt bij het organiseren van virtuele databases en tabellen. Een datavirtualisatieplatform biedt gelukkig wel allerlei mogelijkheden om structuur aan te brengen. Daarmee is het dus een kwestie van alle conventies en standaarden consequent en gedisciplineerd toepassen…

De techniek

Als de functionele architectuur van je logisch data warehouse is uitgedacht, is het tijd voor de technische invulling. Ga je inderdaad een platform voor datavirtualisatie inzetten? En hoe pas je daarbinnen de beste naamgeving, mapstructuren en autorisatie toe?  Hoe en waar ga je historie opbouwen? Hoe ondersteun je verschillende update ritmes? En wat regel je centraal en wat kunnen gebruikers zelf doen met de data?
Je hebt heel wat technische keuzes te maken. Maar daarover in mijn volgende blog post meer…

Kijk je al naar technische oplossing voor virtualisatie? Heb je dan ook al bedacht hoeveel je wil besparen op ontwikkelkosten en levertijd van data?


Whitepaper
DOWNLOAD