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.
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:
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.
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:
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
Informatie rondom de data in de opslaglaag
Informatie rondom de data in de outputlaag
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!