Over mij

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.

door Richard Steijn

Archief voor 'Requirements'

When does the coding stop?

Pas sprak ik met een collega over de vraag waarom we nog steeds met zijn allen zitten te programmeren voor het realiseren van een informatiesysteem. Dit terwijl, als je er door je oogharen naar kijkt, er bij de meeste systemen steeds weer sprake van is dezelfde functionaliteit: het vast leggen van attributen van een entiteiten, het aan elkaar koppelen van entiteiten, of het opvragen van attributen van entiteiten in een of ander vorm. Toch zitten we steeds weer opnieuw en opnieuw te programmeren. Waarom genereren we het gros van de informatiesystemen niet gewoon in hun geheel? Een van de oorzaken is ongetwijfeld het feit dat informatiesystemen naast de grote gemene deler die ze hebben, ook hele specifieke eigenschappen hebben die precies op maat zijn voor een bepaald type gebruiker, situatie of platform. Deze specifieke functionaliteit is vaak lastig op generieke wijze te modeleren (bijvoorbeeld met een Model Driven Design tool) en vervolgens te genereren.  Eenmalig genereren en daarna handmatig uitbreiden lukt nog wel maar onderhoud plegen vanuit een functioneel model is al snel lastig. Kort gezegd: hoe meer je genereert, hoe meer flexibiliteit je inlevert.

De laatste jaren houd ik me voornamelijk bezig met data warehousing. Reuze interessante materie maar in het bouwproces zie ik wel veel herhaling van hetzelfde. Onwillekeurig dringt zich dan de weer vraag bij mij op: Waarom zit ik nog steeds te coderen? Gelukkig ben ik niet de enige met dit soort gedachten. Zo zijn de jongens (en meisjes?) van Qosqo al druk doende met de ontwikkeling van het product Quipu waarmee op basis van de structuur van bronbestanden Data Vaults gegenereerd kunnen worden met bijbehorende ETL. Ik denk echter dat codegeneratie binnen de data warehousing context nog veel breder kan worden toegepast. Ik zou een data warehouse architectuur willen kunnen ontwikkelen zonder perse toe te moeten werken naar een specifieke architectuur, en zonder me vast te pinnen op een bepaalde wijze van datamodellering. Ik zou graag op enkel op basis van een specifatie van de brondata en de requirements die gelden voor het data warehouse een volledig functionerende data warehouse architectuur willen kunnen genereren. Het maakt mij dan niet uit of het resultaat een Data Vault, Anchor Model, Historical Staging Area, Dimensional Model of een of andere mengvorm is. De te gebruiken modelleringstechniek is typisch iets dat ik buiten de requirements zou willen houden op basis waarvan de data warehouse architectuur gegenereerd gaat worden.

Ik zie het als volgt voor me: In een data warehouse architectuur zijn, functioneel gezien, een aantal lagen te onderscheiden:

  • De inputlaag, oftewel de databronnen. Deze zijn een gegeven en moeten dus enkel goed beschreven worden bijvoorbeeld in de vorm van een logisch datamodel per bron en bepaalde eigenschappen van de bron (verderop geef enkele voorbeelden).
  • De opslaglaag. Het hart van het data warehouse. Deze moet na analyse van de wensen van de gebruikers en de beschikbare databronnen worden vormgegeven. Modelleren kan in de vorm van logisch datamodel, uitgebreid met wat specifieke eigenschappen (zie verderop).
  • De outputlaag. Hiermee interacteert de gebruiker. De outputlaag is typisch het product van een transformatieproces met als input de opslaglaag en een verzameling business rules. Doorgaans wordt data in deze laag ontsloten door bijvoorbeeld BI tools zoals een cube, een dashboard met KPI’s, standaardrapporten of een voor gebruikers begrijpelijke informatielaag (zoals de Universe van BO en de Catalog van Cognos).  Maar alles is hier in principe mogelijk. Er kan gebruik worden gemaakt van logische datamodellen om de basisdata te beschrijven die beschikbaar moeten zijn om de gewenste output mogelijk te maken.

Tussen de input- en de opslaglaag en de opslag- en de outputlaag  kunnen mappings gedefinieerd worden. Deze vormen dan de basis voor het genereren van de benodigde ETL code.

De input- en opslaglagen zijn mijns inziens volledig functioneel te modelleren op een min of meer declaratieve wijze. De outputlaag is de lastigste en kan mogelijk niet volledig gemodelleerd worden zonder te vervallen in een verkapt soort programmeren (waar we juist vanaf willen). Dit is vooral het geval als er zeer exotische (en die komen vaker voor dan ons lief is) business rules het spel zijn.

Delen van de data warehouse architectuur die declaratief te modeleren zijn

Toch is er ook iets te zeggen voor een eenvoudige basistaal waarin procedurele beschrijvingen van business rules kunnen worden vastgelegd. Een dergelijke taal biedt namelijk een platformonafhankelijke wijze waarop allerhande transformaties kunnen worden vastgelegd. Als we het vervolgens voor elkaar krijgen alle business rules met deze beperkte taal volledig te modelleren, kunnen we ook het onderhoud op de resulterende data warehouse architectuur via dit model blijven doen.  Anders blijft altijd de noodzaak bestaan om na het genereren van een nieuwe versie van de data warehouse architectuur handmatige correcties op de niet gegenereerde code uit te voeren.

Wat winnen we met een dergelijke benadering:

  1. We kunnen alle benodige datastructuren genereren op basis van het model.
  2. We kunnen alle benodigde ETL genereren op basis van het model.
  3. Na wijzigingen in het model kunnen we ook de migratie van de oplossing gebaseerd op het oude model naar de oplossing gebaseerd op het  nieuwe model automatiseren.
  4. We zijn niet afhankelijk van de onderliggende techniek omdat we het systeem volledig functioneel hebben beschreven. Komt er nieuwe technologie in beeld, dan kan m.b.v. de bijbehorende code generator het nieuwe systeem gegenereerd worden.

Voor ieder platform een codegenerator

Hieronder noem ik enkele zaken die zoal moeten worden vastgelegd in het functionele model van de BI oplossing. Het is uiteraard slechts een schot voor de boeg.

Informatie rondom de inputlaag

  • Welk type databron betreft het?(csv, Excel sheets, xml, tabellen in een Oracle database, Webservice, …)
  • Moet de brondata continue of per interval worden bijgeladen?
  • Hebben we per laadbatch de beschikking over een volledige of onvolledige foto van het bronsysteem of  alleen de delta’s
  • Mag de databron live worden benaderd voor BI doeleinden of niet?
  • Per bronbestand: Welke entiteiten,relaties en attributen zijn er?
  • Per entiteit: Hoe kan deze uniek te geïdentificeerd worden  (of is er misschien een foutkans, zie ook een vorige blogpost)?

Informatie rondom de data in de opslaglaag

  • Welke entiteiten,relaties en attributen hebben we?
  • Wat willen we wel en wat willen we niet historisch bewaren?
  • Welk attribuut in de inputlaag, correspondeert met welk attribuut in de opslaglaag?

Informatie rondom de data in de outputlaag

  • Per outputvorm (cube, dashboard etc): Welke KPI’s, meetwaarden en dimensies onderscheiden we?
  • Welke entiteiten in de opslagstructuur hebben we nodig om een KPI, meetwaarde of dimensie te creeeren?
  • Per outputvorm: Hoe vaak moet data ververst worden?

Ik realiseer me dat dit een wel zeer globale schets is, en dat er nog het nodige denkwerk verzet moet worden om tot een werkende oplossing te komen. Het is echter de moeite waard om dit verder uit te werken. Alleen zo kunnen we uiteindelijk zeggen: “The coding finally stops!” Ik wil iedere lezer dan ook aanmoedigen om hierop te schieten en zijn/haar ideeën met mij te delen. Wellicht zijn er al vergaande ontwikkelingen in deze richting waarvan ik geen weet heb. Ik verneem ze graag!

Datawarehousing: Bezint eer ge begint

Over het algemeen ontstaat de behoefte aan een Enterprise Data Warehouse (EDW) geleidelijk. Iemand in de organisatie heeft behoefte aan bepaalde statistieken die hem kunnen helpen bij het nemen van beslissingen. In het begin wordt deze vraag op een ad hoc wijze opgepakt, eventueel wordt er een business intelligence tool voor gebruikt. Na verloop van tijd komt men erachter dat er regelmatig her en der in de organisatie soortgelijke acties lopen en dat dit allemaal wel erg veel tijd kost. Trouwens: hoe komt het dat Pietje andere statistieken heeft als Jantje over het zelfde onderwerp? Het is tijd voor een meer centrale aanpak: een EDW project.

De start van het EDW project zou altijd moeten worden ingeluid met fase van bezinning en analyse. Hier dient men ondermeer de volgende vragen te beantwoorden:

Vraag: Wie heeft er belang bij een EDW?

Het gaat er hierbij om te bepalen welke mensen mogelijk eindgebruiker zullen worden van het EDW. Mogelijk hebben zij stokpaardjes of tegenstrijdige belangen.  Dit moet in een vroeg stadium helder zijn zodat hierop geanticipeerd kan worden.

Vraag: Wat verwachten deze mensen van een EDW?

Van belang is hier te bepalen of de verwachtingen van de potentiële eindgebruikers wel realistisch zijn. Men dient te beseffen dat de informatie die men aan het EDW wil onttrekken ergens vandaan moet komen en een zeker kwaliteitsniveau moet hebben. Hier geldt het principe Garbage in is garbage out. Ook moet men beseffen dat al het gewenste mogelijk niet in één keer, maar stapsgewijs gerealiseerd kan worden. Verwachtingsmanagement is hier het toverwoord. Dit voorkomt teleurstellingen achteraf.

 

Vraag: Staat de directie achter het project?

Een EDW raakt de gehele organisatie. De data die in het EDW wordt ingelezen wordt in de bronsysteen ingevoerd door vele mensen op allerlei afdelingen en niveaus. Verschillende mensen zijn eigenaar of beheerder van de data. Iedereen heeft binnen de organisatie zo zijn eigen doelstellingen. Deze komen niet noodzakelijkerwijs overeen met de doelstellingen van het EDW project. Weerstand kan dan het gevolg zijn. Soms is het dan nodig dat er “van bovenaf” mensen in een bepaalde richting te sturen.

 

Vraag: Is er voldoende draagvlak in de organisatie?

Zoals hierboven genoemd, raakt een EDW project een heleboel mensen binnen de organisatie. Deze mensen dragen allemaal in meer of mindere mate bij aan het succesvol zijn van het EDW. Het is essentieel dat er door de organisatie heen voldoende draagvlak gecreëerd wordt. Dit komt normaal gesproken niet vanzelf. Als een EDW alleen maar meer werk betekent voor een medewerker (bijvoorbeeld door dat er strengere eisen gesteld worden aan de wijze waarop deze persoon zijn gegevens invoert in een bronsysteem), dan zal deze er niet snel voor warm lopen. Het is dus zaak om mensen vroegtijdig te betrekken bij het project (al is het maar door regelmatige informatieverstrekking)  en ze, waar mogelijk, in ruil ook iets terug te geven. Denk hierbij bijvoorbeeld aan het beschikbaar stellen van nuttige rapportages die gebaseerd zijn op de geïntegreerde data in het EDW.

 

Vraag: Is er voldoende geld en mankracht beschikbaar voor het EDW project?

Deze praktische vraag ligt in het verlengde van het voorgaande. Iets willen is een ding maar er daadwerkelijk resources voor vrijmaken is iets anders. De kosten zijn in het begin van het project het hoogst maar zullen in principe niet stoppen zolang het EDW in gebruik is. Een EDW project blijft gedurende de levenscyclus van het data warehouse de nodige menskracht, geld en aandacht vergen. Idealiter is er minstens een persoon die binnen de organisatie de verantwoordelijkheid draagt voor het “in leven houden” van het EDW. Dit is geen taakje dat je “er even naast” doet. Om het EDW levend te houden moet er naast de nodige technische en functionele beheerhandelingen ook het draagvlak voor het data warehouse op zijn minst gehandhaafd blijven.

Hopelijk valt u op dat in deze vragen techniek geen enkele rol speelt. Datawarehousing is in de eerste plaats mensenwerk en raakt de gehele organisatie.  Het is daarmee grotendeels een politiek spel. Als dit spel niet goed gespeeld wordt, is het datawarehouse gedoemd te mislukken. Technologie is slechts het middel waarmee het datawarehouse gerealiseerd wordt en komt  pas een veel later aan bod.

Maar daarover meer in een volgende post…..