Dunne rapportages en vette databases
In elk BI-traject kom je ze tegen: rapportagetools. Met alle functionaliteit en geboden opties lijken het vaak zelfs méér dan rapportagetools. En dat is waar het misgaat. Te vaak worden rapportagetools ingezet voor zaken waarvoor ze niet bedoeld zijn. Het resultaat: een starre, slecht onderhoudbare en bovenal trage rapportagelaag. Terwijl juist performance altijd een issue is wanneer het gaat om het opbouwen van rapporten.
De paradox is daar: we willen snel onze informatie, maar doen weinig moeite om functionaliteiten onder te brengen in die componenten van ons datalandschap die er ook het beste in zijn. Toegegeven: de drempel is soms laag om zelf ontwerpbeslissingen te nemen en dus, helaas maar al te vaak, voor de makkelijkste manier te kiezen in plaats van de juiste.
De juiste tools voor de juiste taken
Onlangs kocht ik een ander huis. En zoals in elk nieuw huis moest er worden geklust: behangen, schilderen, gordijnen ophangen, vloeren leggen… In deze context kan de vergelijking niet treffender zijn: er moest een fotolijstje worden opgehangen en voordat ik het wist, ramde een behulpzame vriend met een bahco een spijker de muur in. En waarom niet, zou je denken. Nou, omdat een bahco geen hamer is… en bahco’s zijn er niet voor gemaakt om spijkers in een muur te slaan. De muur vond het ook wat minder: de spijker ging er eerst drie keer scheef in en dat bracht onvermijdelijke schade aan het stucwerk met zich mee. Oké, het fotolijstje hangt, maar als straks het interieur weer op zijn kop gaat en het fotolijstje natuurlijk ergens anders moet komen, hebben we meer werk dan verwacht.
De vergelijking met een datawarehouse- of rapportagetraject lijkt vergezocht maar is het allerminst. Tools worden ingezet voor taken waarvoor ze oorspronkelijk niet werden ontworpen. De oplossing ‘doet het’, maar je moet er vooral niet meer aankomen. En een omgeving waaraan niets meer hoeft te worden veranderd ben ik in de IT nog niet tegengekomen. Het opvallende in dit hele verhaal is dat de bahco noch de hamer hier iets aan kan doen: wij nemen zelf het besluit om verkeerde dingen met onze tooling te doen. Waarom toch?
Het dilemma
In organisaties waar veranderingen projectmatig worden aangepakt, is het risico op toolmisbruik het grootst. Maar al te vaak is het projectresultaat belangrijker dan al het andere, dus de manier waarop dat resultaat wordt behaald, is ondergeschikt aan datzelfde resultaat. Goed voor het project en de projectleider, maar niet voor de overall-architectuur, noch de beheer- en beheersbaarheid.
Data-architectuur: ETL in rapportagetools vermijden en dataplatform versterken
Met de enorme hoeveelheid data die voorhanden is (hetzij binnen je eigen organisatie, hetzij een veelvoud daarvan, beschikbaar als ‘open data’), is het ondoenlijk om data te extraheren en te verplaatsen. De behoefte om data te raadplegen op de oorspronkelijke locatie neemt dan ook toe. Een logische gedachte is dat de resources die nodig zijn om de data te bevragen, te filteren etc. dan op die locatie aanwezig moeten zijn. Die resources zijn niet per definitie en misschien zelfs per definitie niet aanwezig op de rapportageservers. En dat is ook niet nodig.
ETL-en in een rapportagetool? Niet doen! De compute-resources zitten vooral in het dataplatform en niet aan de rapportagekant. Maak het dataplatform dikker en de rapportagekant dunner. Niemand gaat naar de supermarkt om het volledige assortiment in huis te halen en vervolgens bij het koken pas te bepalen wat wel of niet nodig is. Het filteren gebeurt in een eerder stadium. Net zo goed dat je prima halffabrikaten kunt inkopen en thuis kunt afmaken in plaats van alles per se zelf te willen maken. Dat is niet alleen tijdrovend, en wellicht duurder (wel lekkerder 😉), maar is ook alleen voor talenten weggelegd die weten wat ze met al die basale ingrediënten moeten doen. Iedereen die zelf wel eens mayonaise heeft gemaakt, snapt wat ik bedoel. Nou, er is niks mis met het kopen van mayonaise.
Wat ik wil zeggen is: maak gebruik van de middelen die je hebt, met de juiste toepassing. Gebruik de middelen voor het doel waarvoor ze bedoeld zijn. Ik heb ooit iemand onder de noemer ‘kitchen-hack’ eieren zien koken in een koffiezetapparaat, maar ik mag hopen dat het niet tot de overtuiging heeft geleid dat dit dé manier is om eieren te koken. Tools worden op de markt gebracht voor een bepaalde toepassing: een bahco om bouten aan- of los te draaien, een hamer om ergens spijkers in te slaan. Daar worden ze voor ontworpen en op getest, en voor die specifieke taak zijn ze dus het meest geschikt.
Conclusie: optimalisatie door juiste inzet en focus
Functionaliteit hoort daar te liggen waar het hoort. Bij rapportagetools moet gefocust worden op rapporteren. Databases horen te worden ingezet voor data en aanverwante zaken, zoals toegang tot data.
De zwakke schakels in het geheel zijn niet de rapportagetools die voorhanden zijn, maar de mensen die ze gebruiken en inrichten. Zolang wij onszelf niet de druk willen opleggen om ons aan bepaalde ontwerpstandaarden te houden, zullen tools altijd minder dan optimaal worden ingezet met versnippering en beheersproblemen tot gevolg. Op project- en programmamanagementniveau zou vaker gekozen moeten worden voor de juiste aanpak en niet voor de snelste aanpak.