Self Service Analytics
Self Service Analytics en het grote BI-dilemma

Self service analytics is geen nieuw fenomeen. In de negentiger jaren werden er al zogenaamde managed query tools, waaronder BusinessObjects, Crystal reports en Cognos Impromptu, ingezet voor self service analytics. Deze voorlopers van de huidige producten zien er nu in onze ogen zeer simplistisch uit. Zoveel jaren ervaring met deze producten doet vermoeden dat we ondertussen wel weten hoe we ze op een efficiënte en effectieve manier kunnen inzetten en integreren met de klassieke data warehouse omgeving. Niets is echter minder waar. Veel organisaties worstelen hier nog steeds mee en veel goedbedoelde self service projecten zijn helaas geëindigd in chaos. Hiermee is het grote BI-dilemma ontstaan. Hoe implementeren en integreren we het klassieke gebruik van data met de behoefte aan self service analytics zonder dat we een van de twee te kort doen?

Zelf analyseren

Rapportage- en analysebehoeften zijn de laatste jaren fors veranderd. Ooit was IT verantwoordelijk voor alle rapporten en analyses die ontwikkeld werden. Nu niet meer. Veel ontwikkelwerk is verschoven naar de business. Bekende producten als PowerBI, QlikSense en Tableau, maken het mogelijk dat business gebruikers zelf hun analyses ontwikkelen en zelf krachtige rapporten in elkaar zetten. Deze mogelijkheden willen we niet kwijt, want het zou voor IT anders niet haalbaar zijn om aan de huidige BI-behoefte te voldoen. De rapportage en analyse backlog zou fenomenaal worden.

Om rapporten en analyses te laten werken, moeten er specificaties ingevoerd worden, zoals integratie-, transformatie-, aggregatie- en visualisatieregels. Wat er momenteel fout gaat, is dat de meeste van deze specificaties door de gebruikers zelf en onafhankelijk van elkaar ontwikkeld worden. Ieder voor zich. Als voor twee verschillende rapporten dezelfde tabellen geïntegreerd moeten worden, maken beide gebruikers onafhankelijk van elkaar vergelijkbare maar toch verschillende oplossingen. Dit is nadelig voor de productiviteit, onderhoudbaarheid, consistentie van rapportresultaten en de correctheid van informatie.

Waardevolle tijd

Die ieder-voor-zichzelf aanpak is op bepaalde gebieden wellicht aantrekkelijk maar slecht voor de productiviteit, omdat specificaties weinig tot niet gedeeld worden, zelfs al gebruikt iedereen hetzelfde self service product. Elke gebruiker vindt het wiel opnieuw uit. Daarbij komt dat sommige specificaties technisch van aard zijn en weinig met de business problematiek te maken hebben. Veel organisaties gebruiken trouwens niet slechts één product voor self service analytics maar meerdere. Zo kan bijvoorbeeld Tableau voor de dagelijkse databehoeftes gebruikt worden en DataRobot voor high-end data science, en dan uiteraard ook nog Excel. Deze tools delen per definitie geen specificaties. Als gebruikers verkoopcijfers willen bestuderen met verschillende producten, zal voor elk product een andere implementatie gerealiseerd moeten worden. Hiermee gaat veel waardevolle tijd verloren.

Het is zelfs mogelijk dat veel van de specificaties die ingevoerd moeten worden in de self service producten al in de data warehouse omgeving gedefinieerd zijn. Desondanks worden ze niet hergebruikt en wordt het wiel steeds opnieuw uitgevonden.

Onderhoudsnachtmerrie

Zoals aangegeven, veel specificaties worden meerdere malen in verschillende producten ingevoerd, of met andere woorden, ze worden gedupliceerd. Deze duplicatie van specificaties in allerlei rapporten en producten leidt tot een onderhoudsnachtmerrie. Als bepaalde specificaties aangepast moeten worden, omdat bijvoorbeeld business rules wijzigen, hoe wordt dan gegarandeerd dat op alle plekken waar die specificaties voorkomen een vergelijkbare aanpassing gemaakt wordt?

Een ander nadeel heeft te maken met de consistentie van rapportresultaten. Wordt bijvoorbeeld in alle rapporten dezelfde formule gehanteerd om de op-tijd-vertrokken vluchten te berekenen? Als iedereen op zichzelf ontwikkelt, dan is er geen garantie. Een ander soort consistentieprobleem ontstaat doordat veel van deze self service rapporten de specificaties opgebouwd in de klassieke data warehouse omgeving omzeilen. Bijvoorbeeld, als in het data warehouse een bepaald algoritme gebruikt wordt dat foutief gespelde adresgegevens corrigeert en als het self service product zelf data uit de productiedatabase haalt, dan zal waarschijnlijk die adres corrigerende functie niet aangeroepen worden. Daarmee zal het resultaat van de rapporten inconsistent zijn met de standaardrapporten uit het data warehouse.

Sowieso blijft de vraag of rapportresultaten wel correct zijn. Zijn inderdaad de correcte formules toegepast? Hoe goed zijn de ingevoerde specificaties? Wie voert controles uit op deze implementaties? Specificaties worden normaliter binnen een self service product opgebouwd in wat de meeste mensen een ‘semantische laag’ noemen. Elk product ondersteunt een eigen proprietary semantische laag met een eigen taal en eigen concepten. Hier ligt de basis van het grote BI-dilemma.

Datavirtualisatie

De gewenste situatie is natuurlijk dat specificaties éénmalig in een semantische laag gedefinieerd worden en vele malen gedeeld worden, ofwel één universele semantische laag. Self service producten bieden hier geen oplossing voor. Het ene product kan geen specificaties gebruiken die in een ander product gedefinieerd zijn, vandaar de replicatie. De oplossing moet buiten de self service producten gezocht worden en wel bij datavirtualisatie servers, zoals die van Cisco, DataVirtuality en Denodo. Datavirtualisatie servers worden geplaatst tussen de self service producten en gegevensbronnen. In feite lijkt het voor de self service producten alsof de datavirtualisatie server de gegevensbron is.

Het belang van deze architectuur is dat in datavirtualisatie servers alle specificaties slechts eenmalig ingevoerd hoeven te worden om vervolgens door allerlei self service producten gebruikt te kunnen worden. Eén keer definiëren en meerdere keren hergebruiken. Als een business rule verandert, dan hoeft de bijbehorende specificatie maar één keer aangepast te worden en wel in de datavirtualisatie server. Daarna maken alle producten er direct gebruik van en zijn alle rapporten aangepast.

Deze architectuur verbetert de productiviteit (omdat alles slechts eenmalig ingevoerd hoeft te worden), verbetert de onderhoudbaarheid (omdat een verandering maar op één plek doorgevoerd hoeft te worden) en verbetert de consistentie en correctheid van rapportresultaten (omdat elk rapport dezelfde specificaties gebruikt).

Het werken met datavirtualisatie servers vermindert niet het self service karakter van ontwikkeling. Met dezelfde snelheid kunnen specificaties gedefinieerd worden in een self service product als in een datavirtualisatie server. Business gebruikers zullen zich hierdoor veel meer kunnen richten op het ontwikkelen van de rapporten, analyses en visualisaties. Kortom, datavirtualisatie verkleint het grote BI-dilemma door orde te scheppen in self service omgevingen met één universele semantische laag. Self service wordt hiermee gepromoveerd tot managed self service!


Wanneer stop je met het alsmaar dupliceren van specificaties en kies je voor een oplossing waarbij alle specificaties eenmalig in één universele semantische laag gedefinieerd zijn?