Ik ben Richard Steijn en datawarehousing/BI specialist. Bij vele organisaties in diverse branches heb ik een kijkje in de keuken mogen nemen. Verscheidene technologieën hebben mijn pad gekruist. Data en alle vraagstukken daaromheen vormen een rode draad in mijn werkzame leven. In deze blog schrijf ik over de dingen die mij zoal bezighouden.
Managementinformatie wordt gemaakt op basis van data afkomstig uit een of meer bronsystemen. Tussen het moment van het onttrekken aan het bronsysteem en het moment van afleveren van managementinformatie bij de eindgebruiker kan de ruwe brondata aan verschillende transformaties worden onderworpen. Niet zelden wordt er in dit proces gebruik gemaakt van een of andere vorm van historische data opslag. Een belangrijke reden om datahistorie te bewaren is dat dit ons in staat stelt om op ieder gewenst moment eerder geproduceerde managementinformatie exact te kunnen reproduceren. Zo kan de gebruiker, op een later tijdstip verdere analyse uitvoeren op dezelfde cijfers als destijds. Dit wordt ook wel het non-volatility principe genoemd.
Binnen verschillende BI architecturen wordt op verschillende manieren omgegaan met brondata, het bewaren van historie en de transformaties die nodig zijn om van ruwe brondata managementinformatie te maken. De ene architectuur is er primair op gericht informatievragen die hier en nu spelen te kunnen beantwoorden en bevatten geen voorzieningen voor non-volatility. Andere architecturen zijn ambitieuzer van opzet en garanderen wel non-volatility en houden tegelijkertijd rekening met het gegeven dat bronsystemen kunnen wijzigen evenals de informatiebehoefte van de gebruikers van managementinformatie. Alles daar tussenin is uiteraard ook mogelijk.
Verlies van historie
Bij de meeste BI architecturen kan informatie verloren gaan over de historie en herkomst van de brondata. Dit is altijd het gevolg van het transformeren van data waarbij de uitkomst van de transformatie wordt bewaard maar de data die als input voor de transformatie diende niet. Voor de meeste BI specialisten is dit gesneden koek (mag ik hopen), echter voor de business, de eindgebruiker van de BI architectuur, is dit lang niet altijd het geval (We hebben een datawarehouse dus we bewaren de historie van al onze data…). Daarom is het goed om eens te benoemen wat er allemaal gebeurt met de data uit de operationele systemen voordat het uiteindelijk is getransformeerd naar bruikbare management informatie.
Manieren om data historie te verliezen
Hieronder beschrijf ik aan welke transformaties data binnen een BI architectuur onderworpen kan worden en hoe dit tot verlies van data historie kan leiden.
Data cleansing
Dit is het opschonen van data door het toepassen van kwaliteitsregels alvorens deze data in het datawarehouse worden geladen. Er zijn verschillende situaties die er toe kunnen leiden dat een data item niet in het datawarehouse terecht komt:
Data integratie
Dit is het samensmeden van gefragmenteerde data tot een geheel. Ik onderscheid twee vormen van data integratie:
Calculatie
Dit is het berekenen van numerieke waarden op basis van verschillende getallen in een of meer records uit het bronsysteem. Denk hierbij bijvoorbeeld aan het berekenen van een omzet voor een orderregel door het verkochte aantal te nemen en dit te vermenigvuldigen met de stuksprijs van het bestelde product en hiervan een eventueel verleende korting af te trekken. De berekende omzet wordt opgeslagen in het datawarehouse, maar de onderliggende getallen (aantal verkocht, stuksprijs en kortingsbedrag) niet.
Aggregatie
Dit is het berekenen van numerieke waarden door het samenvatten van data uit meerdere records uit het bronsysteem voor een of meer dimensies en dit opslaan in het datawarehouse. Tegelijkertijd worden de onderliggende detailgegevens niet bewaard in het datawarehouse. Een voorbeeld van aggregatie is het berekenen van het verkochte aantal van een product per week door de som van het verkochte aantal van alle orderregels voor het betreffende product die binnen dezelfde week vallen, op te tellen.
Wat is nou eigenlijk het probleem?
In de bovengenoemde voorbeelden onder het kopje data integratie is het probleem evident. Door voortschrijdend inzicht in de wijze waarop de data geïntegreerd moet worden of door er te laat achter te komen dat er iets mis is gegaan met de data integratie is het onmogelijk de oorspronkelijke brondata te reconstrueren en opnieuw te integreren volgens de nieuwe inzichten.
Ook rondom data cleansing strategieën kunnen we voorschrijdende inzichten krijgen. Bijvoorbeeld we komen tot het inzicht dat, geheel tegen de afspraken in, de order desk orderregels ‘misbruikt’ door een negatief te factureren bedrag in te voeren om zo geld terug te storten op rekening van klanten die te veel betaald hebben. Nu we dit weten, blijkt dat we, achteraf gezien, de orderregels met een negatief factuurbedrag wel degelijk hadden moeten meenemen in de berekening van de weekomzet. Echter deze orderregels zijn buiten het datawarehouse gehouden en zijn in de tussentijd mogelijk gewijzigd in het bronsysteem. Met terugwerkende kracht zijn we nu niet meer in staat de weekomzet te herberekenen volgens de nieuwe methode.
Organisaties zijn continue onderhevig aan veranderingen. Hetzelfde geldt voor de markt waarin zij opereren. Het kan dan ook niet anders dan dat de informatiebehoefte van de gebruikers van de BI oplossing verandert in de tijd. Om tegemoet te kunnen komen aan deze veranderende informatiebehoefte, moeten soms wijzigingen worden aangebracht in het datawarehouse. Stel dat de eindgebruiker aanvankelijk geïnteresseerd was in de omzet per product, per verkoper, per week. Om aan deze informatiebehoefte te voldoen, zijn de orderregels afkomstig uit het ordersteem geaggregeerd per product, verkoper en week. Het resultaat van deze aggregatie is opgeslagen. De onderliggende orderregels niet. Op een later moment geeft de eindgebruiker aan dat hij de omzet ook nog per verkoopregio wil kunnen bekijken. We hebben nu geen andere keus dan de omzet opnieuw te berekenen door de orderregels zoals ze nu in het ordersysteeem staan, opnieuw te aggregeren, ditmaal met de extra dimensie verkoopregio. Er is een gerede kans er inmiddels iets is veranderd in het orderregels in het ordersysteem. Als we het non-volatility principe belangrijk vinden, moeten we in dat geval de oorspronkelijke omzetcijfers (per product, per verkoper, per week) bewaren in het datawarehouse en daarnaast de omzetcijfers volgens de nieuwe berekening (per product, per verkoper, per week, per verkoopregio) gaan opslaan. De oorspronkelijke omzetcijfers uitsplitsen volgens een extra dimensie kan in dit geval dus niet.
Business beslist mee
Nu we weten waar we historie kunnen verliezen, kunnen we, indien gewenst, hierop anticiperen. Dit kan door de juiste BI architectuur te kiezen, in combinatie met de juiste wijze van het modelleren van data. Voordat een organisatie een keuze maakt, is het belangrijk om helder te hebben welke consequenties deze keuze heeft in termen van mogelijk verlies van data-historie en hoe dit de flexibiliteit en onderhoudbaarheid van de oplossing beïnvloedt. Architectuurkeuze is dus niet enkel een technische aangelegenheid. De business moet hier ook bij betrokken worden.