Deze week kwam ik het weer tegen bij een klant. Er moest een keuze gemaakt worden over hoe informatie uit een bepaald bronsysteem getrokken moest gaan worden. Een van de opties was om dit te doen middels een BI plugin die meegeleverd werd bij het bronsysteem. Na onderzoek bleek deze te weinig informatie op een te hoog detailnivo op te leveren. Het gevolg hiervan is waarschijnlijk dat er een grote hoeveelheid tijd gestoken moet worden in de ontsluiting van het bronsysteem.
Hoe moeilijk is het om als je een extractie of ontsluiting van een bronsysteem ontwerpt dat zodaning op te zetten dat je in principe een zo groot mogelijke variatie aan informatiebehoefte kan bedienen? In de praktijk betekend dat gewoon: prik op een zo laag mogelijk datailnivo in, neem ieder gegevensveld mee. Niet dat dit in de praktijk altijd mogelijk is, maar je dwingt jezelf tenminste om er goed over na te denken en bewust een keuze te maken. We weten inmiddels allemaal dat het niet mogelijk is om de informatiebehoefte rond een bepaalde bron over een jaar voorspellen. Laten we met zijn allen nu eens ons best doen om systemen te realiseren die niet al binnen een jaar aangepast moeten worden.

Recentelijk hebben we gekeken naar de geschiktheid van Open Source producten op het gebied van BI voor onze dienstverlening. We keken daarbij natuurlijk ook naar hoe makkelijk het daadwerkelijk was om een BI oplossing te realiseren. In onze pogingen om een bestaande klantcase aan de praat te krijgen liepen we tegen een vervelende bug van het pakket aan. In alle onschuld staken we wat tijd in de communicatie met een van de programeurs om uit te leggen hoe e.e.a. te reproduceren was. Groot was onze verbazing toen we twee dagen later de melding kregen dat er een nieuwe build beschikbaar was waarin de door ons genoemde bug verholpen was.
Ik weet nog uit de tijd dat ik voor een grote klant rapporten binnen Business Objects aan de praat probeerde te krijgen (inmiddels al meer dan tien jaar geleden, dus hoe het nu is weet ik niet). Ik moest ontzettend veel moeite doen om serieuze bugs op de ‘enhancement request’ lijst te krijgen.
Het is natuurlijk de vraag hoe lang het duurt voordat deze Open Source leverancier noodgedwongen de directe lijn met de bouwers moet doorknippen. Maar vooralsnog ben ik onder de indruk van de support. Iets wat men juist bij Open Source vaak bestempelt als niet voldoende voor serieuze toepassingen.

Het valt mij steeds op dat ETL tools precies de functionaliteiten bieden die ik niet van ze verwacht. Er zijn een aantal zaken aan een ETL proces generiek zoals foutafhandeling en foutstroom, logging voor audit trail en dergelijke. Je zou verwachten dat juist deze zaken in elke ETL daarom automatisch geregeld zijn. Dit blijkt nauwelijks het geval. Sommige tools bieden mogelijkheden om met templates of wizards generieke zaken aan te brengen, maar ontberen dan weer vaak de mogelijkheid om generieke zaken aan te passen.

Nog erger is dat de tools ook goed zijn in de dingen waar je ze eigenlijk niet voor nodig hebt. Ik bedoel hierbij het tekenen met de muis van een eenvoudige 1:1 flow. Dat gaat geweldig, klik klik sleep en het is klaar. Maar een dergelijk proces zou eigenlijk niet eens geklikt moeten worden, dat moet genereerbaar of met één definitie af te handelen zijn. Het gaat meestal om 80% van alle datastromen die wel zo eenvoudig zijn dat je er de ETL programmeur eigenlijk niet mee mag vervelen. Die programmeur zit zich nu een muisarm te klikken aan zaken die volledig geautomatiseerd hadden kunnen zijn.

De tool met fraaie grafische weergave wil ik wel graag gebruiken voor de zeer complexe transformaties met vele joins, opzoeken van laatste of huidige versie in de historie en transponeren van gegevens. Juist hier laten de tools het weer afweten, de join wordt niet of slecht naar de database doorgezet of zodanig doorgezet dat de performance onacceptabel wordt en er alsnog een view gemaakt moet worden die in ieder geval te tunen is.

Het is echt een gemiste kans van de ETL tool bouwers dat er steeds aandacht is voor de grafische presentatie maar geen aadacht voor waar ze het werk van de ETL programmeur weg kunnen automatiseren. Ik zie hier wel een mooie kans voor de open source ETL tools. Door het open en goed beschrijven van de ETL definities is het heel wel mogelijk om hier een generator overheen te schrijven die de eenvoudige processen in luttele secondes genereert, waarmee 80% van het (oervervelende) werk zomaar is gebeurd.