Het is echt jammer dat zo weinig ontwerpers en -nog erger- architecten van data warehouses domweg één ontwerp voor alle klanten voorstellen. Dit is niet onder architectuur ontwerpen. Er is geen one-size-fits-all te bedenken voor een data warehouse. Ik snap wel dat er naar geneigd wordt om één ontwerp te kiezen, buiten dat het gemakkelijker is kan ook meteen een standaard aanpak voor de implementatie bedacht worden, waardoor ook de grootste domoor een implementatie lijkt te kunnen doen. Maar dit geeft zelden de gewenste oplossing.

Het onder architectuur leveren betekent dat het ontwerp en de aanpak volledig afgestemd moeten worden op de omgeving en langere termijn plannen en wensen van de klant. Er is niet één ontwerp altijd het beste voor elke klant. Een architect moet aan de kwaliteitseisen van de klant het juiste ontwerp kiezen of maken.

Er zijn vele methodieken en ontwerpen op de wereld voor het bouwen van een data warehouse. Er zijn twee methodieken die er in populariteit en bekendheid uitspringen; de Kimball en de Inmon methodiek, waarbij de Kimball methodiek snel aan populariteit wint. De aanhangers van deze methodieken hebben een haast religieuze overtuiging van de juistheid van de methodiek die zij aanhangen. Waar zelden rekening mee gehouden wordt is dat beide methodieken aan andere kwaliteitseisen voldoen. Geen van beide is in alle gevallen de beste keus, een combinatie van beide ontwerpen geeft vaak de beste benadering van wat de klant nodig heeft. In sommige gevallen is het ook nodig twee verschillende ontwerpen naast elkaar te kiezen, bijvoorbeeld als de beschikbaarheidseisen voor een deel van de informatiebehoeften sterk afwijkt.

Het OCI heeft een standaard lijst van kwaliteitseisen voor ICT systemen opgesteld die alle toepasbaar zijn, er is echter een kortere lijst van kwaliteits- en niet-functionele eisen op te stellen aan de hand waarvan de architect het ontwerp voor een data warehouse kan selecteren of maken. De normen voor deze eisen moeten achterhaald worden bij de klant. Vaak is het voor de klant nog niet geheel duidelijk wat de eisen precies zouden moeten zijn. De architect dient dan aan de hand van interviews en bestudering van missie en visie en de meerjaren plannen van de klant samen met het beoogde gebruik voor het data warehouse de optimale normering te bepalen. De normering is uiterst belangrijk en dient goed met de klant afgestemd te worden. Als de normen van teveel kwaliteitseisen te hoog gekozen worden zal de prijs van het extreem hoog worden, als er eisen te laag gekozen worden zal het geleverde product tegenvallen of slecht bruikbaar zijn voor de beoogde doelen.

Ik heb wel eens rondgelopen bij het BI Competence Center van een grote organsatie. Ze hadden hun zaakjes goed voor elkaar. Iedere medewerker had veel verstand van zaken. Ze hadden een groot deel van het reguliere BI traject afgedekt met bijpassende tools. Zaken werden uitgebreid gedocumenteerd, en er werd gebouwd vanuit de achtergrondgedachte van een Corporate Data Warehouse.
Op een gegeven moment werd bekend dat de firma zijn activiteiten zou bundelen met een andere grote firma binnen het vakgebied. Gedurende het fusieproces liep men aan tegen het feit dat het niet handig leek om op twee locaties twee afdelingen aan de slag te hebben op het gebied van BI. Vervolgens zag ik een strijd ontstaan over welke aanpak en architectuur zou overleven. De inhoud werd nadrukkelijk onderschikt aan de politiek. De uiteindelijke oplossing bleek een hybride gedrocht dat ver af stond van de intenties waarmee mijn klant ooit aan de slag was gegaan. Veel van deze ellende was te voorkomen geweest als men op directienivo wat meer doordrongen was geweest van het belang van BI, en van het belang van een bedrijfsbrede aanpak ervan.

Datawarehouse-trajecten halen hun toegevoegde waarde uit het combineren van informatie uit operationele systemen van verschillende bedrijfsonderdelen. Deze ‘informatie-integratie’ krijgt vorm in een corporate datawarehouse-model, of in ieder geval afdelingsoverstijgend model.Dat is niet alleen technisch een uitdagende klus, ook de afstemming met de diverse afdelingen en toekomstige klanten kan tot hoofdbrekens leiden. Voordat de bronanalyse en de informatie-analyse hebben geleid tot een concrete datawarehouse-omgeving onder architectuur praat je al gauw in termen van jaren.

Of de hooggespannen verwachtingen worden ingelost wordt dan pas duidelijk. Het risico bestaat dat de opdrachtgever gaandeweg zijn aandacht richt op andere, nieuwe projecten die sneller Return on Investment beloven. Een CEO blijft gemiddeld slechts 31 maanden in functie, dus veel tijd is je niet gegund.

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.

Ik leerde ooit van een goede collega om na het afdrukken van een document ook even te kijken naar wat er nog meer bij de printer ligt als je je printje op gaat halen in het printerhok. Net zoals dat de informele communicatie belangrijk kan zijn bij een project, kan ook dit je het nodige leren over wat er in de periferie van je project gebeurt. Het gaat dan vaak om informatie die je via de reguliere kanalen niet bereikt. Ik ben welliswaar nooit achter sappige roddels gekomen, maar het nut is mij zeker gebleken. Kijk wel uit dat je je dagen niet slijt in het printhok.

Ik ben altijd weer verbaasd als ik organisaties zie worstelen met de vraag hoe ze de eenduidige objectdefinities, die met veel pijn en moeite aan de organisatie en bronsystemen ontfutseld zijn, toegankelijk maken voor de eindgebruikers. Men verzand vaak in het zoeken naar een geschikt tool waarbij ook nog eventje gepoogd wordt om de hele keten van het tot stand komen van het object vast te leggen en op een inzichtelijke wijze naar iedereen (techniek en business) te communiceren. Naar mijn menig leg je de lat heel hoog als je zoekt naar een enkele geintegreerde oplossing die zowel voor de business als voor de techniek werkt. Ik heb diverse keren meegemaakt dat de oplossing die uiteindelijk het beste bleek bestond uit twee verschillende onderdelen; een systeem waarmee gegevens uit de tool-metadata (ETL en rapportage) werd gebruikt om de techniek te helpen. Daarnaast werd er vanuit de rapportage-portal een koppeling gemaakt met een document/webpagina met daarop een lijst met begrippen en hun definities. Niks geen moeilijk systeem, maar een pragmatische oplossing die in een enkele dag te realiseren is. Het leven kan soms zo simpel zijn.

Tegenwoordig kun je als grote organisatie niet meer meekomen als je je interne informatievoorziening niet op orde hebt. Toch heb ik maar weinig organisaties van binnen gezien die dat kunnen zeggen. Het is frappant hoe vaak ik nog organisaties zie worstelen met elementaire zaken (op IT-gebied) die ‘verkeerd’ opgezet zijn.

Zo herinner ik mij een klant waarbij er op verschillende plaatsen nieuwe versies van bronsystemen werden ontwikkeld. Beide systemen gingen iets doen met een deel van het productenaanbod. Beide teams hadden geen inhoudelijk contact met elkaar en zagen daar ook de noodzaak niet van in. Het gevolg laat zich raden. Bij het realiseren van een integraal productbeeld binnen het corporate Data Warehouse bleken beide systemen een incompatible perceptie te hebben van een product. Slecht ten koste van een aanzienlijke hoeveelheid manuren kon er ETL gebouwd worden die er nog iets van bakte.

In dit geval bleek dat, ofschoon het realiseren van een corporate BI omgeving als noodzakelijk werd beschouwd voor het realiseren van de bedrijfsdoelstellingen, het bijbehorende bewustwordingsproces binnen de organisatie niet voldoende was. Het als organisatie succesvol zijn met BI vergt duidelijk meer dan alleen de implementatie van wat tools.

We zijn dit blog begonnen vanuit een noodzaak die we met een aantal medewerkers van Euclides voelden om ervaringen van alledag binnen het BI werkveld te delen met collega’s en en de rest van de wereld. Het is in die zin ook een test om te kijken of we wel zoveel te melden hebben dat het interessant is voor anderen om te lezen. Het mooie van het medium Internet is dat er alle ruimte is voor dit soort initiatieven, en in plaats van lang discussieren over het nut en de noodzaak hiervan zijn we maar gewoon begonnen. Dit blog wordt geschreven door medewerkers en is in die zin niet objectief, en geschreven vanuit de persoonlijke beleving van de consultants.