De gevolgen van de veranderingen binnen het applicatielandschap op de architectuur van jouw data

De architectuur van data open houden

'Data' is een breed concept en omvat een enorme hoeveelheid domeinen die allemaal specifieke kennis vereisen of een bepaald specialisatieniveau. Er zijn genoeg voorbeelden: data-architectuur, datavisualisatie, databeheer, databeveiliging, AVG enzovoort. Veel organisaties hebben in de loop der jaren geprobeerd om grip te krijgen op al die verschillende 'datadomeinen'. Geen eenvoudige opgave, want al deze domeinen ondergaan innovatieve veranderingen. Ze hangen bovendien vaak samen met andere en nieuwere concepten, zoals AI, datawetenschap, machine learning, en andere zaken.

Het verdient in elk geval de voorkeur om je blik en je data-architectuur zo open mogelijk te houden. Zo beperk je de gevolgen van toekomstige veranderingen op je huidige implementatie. Het negeren van dergelijke wijzigingen kan innovaties vertragen, irritatie wekken bij eindgebruikers en de kans op hogere kosten aanzienlijk vergroten als het aanpassen van je architectuur over enkele jaren onvermijdelijk is.

Het combineren van gegevens wordt gecompliceerd door moderne applicaties

De hoeveelheid gegevens neemt elk jaar exponentieel toe. Nieuwe gebruikers zijn er bovendien aan gewend om op hun wenken te worden bediend. Deze trend wordt overduidelijk ondersteund door het huidige landschap. Softwareleveranciers bieden bij veel applicaties in realtime data aan op efficiënte, aantrekkelijke en inzichtelijke wijze. Dit zijn uiteraard belangrijke punten voor deze leveranciers, maar ze leveren wel weer extra problemen op voor CIO's die gecombineerde gegevens moeten leveren aan eindgebruikers.

"Wat is de impact van een marketingcampagne op de verkoop van een bepaald product?". Het beantwoorden van deze vraag vormt een uitdaging voor veel organisaties. Er moeten hiervoor gegevens van twee (goed georganiseerde) applicaties worden gecombineerd. Atlassian biedt bijvoorbeeld rapportagefuncties in Jira en Saleforce doet hetzelfde met hun bekende CRM-platform. De rapportagefuncties in beide softwarepakketten zijn zelfs bijzonder uitgebreid, zodat je waardevolle rapporten kunt opstellen. Het is echter lastig om deze gegevens in één rapport te combineren.

Naast goed gestructureerde marketing- en verkoopdomeinen, vereist een dergelijke vraag bovendien een overkoepelende technische en organisatorische afstemming. Welk domein is verantwoordelijk voor of beschikt over het mandaat om een dergelijke vraag te beantwoorden? Is er een budget beschikbaar? Welke resources zijn er? En welk domein draagt de kosten?

Is selfservice BI een oplossing?

Om dergelijke vragen te kunnen beantwoorden zijn er oplossingen op de markt gekomen zoals selfservice BI. Deze tools kunnen gegevens gemakkelijk combineren en bieden gebruikers soms verrassende inzichten. De enige vereiste is dat deze tools toegang nodig hebben tot de betreffende gegevens. Klinkt vrij eenvoudig, toch?

Selfservice-tools zijn de afgelopen jaren zeer succesvol geworden, met Power-BI van Microsoft voorop. Door het belang van visualisaties en intuïtieve 'selfservice-gegevensladers' te vergroten, werden deze tools hun investering waard voor de 'sector'. Dit veroorzaakt echter wel een bepaalde spanning tussen de zakelijke gebruikers van deze tools en CIO's. Laatstgenoemden raken langzaam hun grip op het IT-landschap kwijt doordat er op de achtergrond bij een selfservice BI-aanpak ook veel ‘schaduw BI’-initiatieven ontstaan. Iemand kan bijvoorbeeld zelf besluiten om Google Data Studio te gebruiken zonder dat de CIO daarvan op de hoogte is, terwijl die CIO met behulp van Power BI een toolset probeert te standaardiseren. Conclusie: tonnen aan gedupliceerde gegevens, schending van de veiligheid en dan hebben we de AVG-naleving nog buiten beschouwing gelaten.

Welke andere oplossingen zijn er?

De standaard inzichten en analytische rapporten die applicaties bieden zijn al oud nieuws en de vraag naar realtime analyses, ook wel bekend als 'streaming analytics', neemt toe. Winkels laten tijdens online winkelen bijvoorbeeld op de productpagina zelf zien wat de daadwerkelijke voorraad van een product is. Vrij gangbaar, toch? Waarom is het dan zo moeilijk om mijn vraag over de gevolgen van mijn marketingcampagne op mijn verkoop te beantwoorden in een rapport?

De vereisten die aan gegevens worden gesteld en de behoeften eraan zijn aan verandering onderhevig. Wie is de eigenaar van welke gegevens en wie bepaalt het gebruik ervan? Verdwijnen historische gegevens als ze niet worden opgeslagen in een datawarehouse? Als de gegevens nog beschikbaar zijn in de applicatie waarin ze zijn gecreëerd, hoe lang blijven ze daar dan? De opslag van gegevens in een 'data lake' of een gegevensarchief is wellicht een goedkope(re) oplossing. Deze gegevens worden echter niet of nauwelijks geordend en zijn daardoor lastig te gebruiken voor zaken zoals management rapportages. Misschien dat het verplaatsen van deze gegevens naar een datawarehouse de beste oplossing is? Goed gestructureerde data, eenvoudig te combineren met data van andere domeinen en die zodoende een ideale basis biedt voor verdere analyse. Maar ... de informatie is niet beschikbaar in realtime en dit is een oplossing die vrij kostbaar kan uitpakken. Welke oplossing voldoet het beste aan je eisen?

Takeaway

Je zult ondertussen wel gemerkt hebben dat het heel eenvoudig is om talloze vragen en uitdagingen te bedenken over het ordenen van gegevens bij organisaties. Bepaalde datagerelateerde vragen moeten snel worden beantwoord, andere overwegend analytische of strategische vragen vereisen geen realtime gegevens. Een data-architectuur moet rekening houden met al deze behoeften en moet kunnen worden aangepast.

Wij geloven in een data-aanpak waarbij domeineigenaren ook eigenaar zijn van de data die zij ter beschikking stellen aan de rest van de organisatie. Het is de verantwoordelijkheid van de domeineigenaar om die data zodanig te ordenen dat zoveel mogelijk vragen van de organisatie