Het belang van vraaggedreven data-architecturen

Leer in 8 minuten

Wat de risico’s van een aanbodgedreven aanpak zijn
Wat de rol van metadata is in een architectuur
Hoe je naar een vraaggedreven architectuur toewerkt

Veel data-architecturen worden vanuit de bronsystemen ontworpen. Dit is vaak duidelijk te zien wanneer de eerste high level diagrammen of zogenaamde praatplaten van een data-architectuur getekend worden. Al snel verschijnen er dataopslagpunten in het plaatje, zoals data warehouses, data lakes, data hubs en staging areas. Vervolgens wordt bekeken welke bronsystemen data gaan aanleveren en hoe en waarmee de data gekopieerd wordt. Daarna wordt bepaald met welke producten de gebruikers de data kunnen bevragen. Deze aanpak leidt tot een aanbodgedreven data-architectuur.

Risico’s van een aanbodgedreven aanpak

Die kan succesvol zijn, maar het gevaar is dat niet goed in kaart gebracht is welke data de gebruikers werkelijk nodig hebben en hoe ze die willen gebruiken. Dit zou weleens de reden kunnen zijn dat gebruikers de ontwikkelde dashboards en rapporten niet als een eindproduct maar als input beschouwen. Data wordt dan naar een spreadsheet gekopieerd, waar vervolgens formules en what-if analyses uitgevoerd worden. De resultaten hiervan worden vervolgens naar andere spreadsheets gekopieerd en naar collega’s gestuurd. Dit is een duidelijk teken dat wat door IT ontwikkeld is, niet voldoet aan de gebruikerswensen.

Maar andere wensen zouden door de aanbodgedreven aanpak gewoonweg niet boven tafel kunnen komen. Veronderstel dat gebruikers de mogelijkheid nodig hebben om zelf data te wijzigen of toe te voegen. Bijvoorbeeld in het geval dat een gebruiker ziet dat bepaalde kosten op een verkeerd project geboekt zijn. Uiteraard kan hij of zij de correcte cijfers doorbellen naar de eigenaren van die data en die zullen het dan ongetwijfeld aanpassen, maar dan kan het uren of zelfs dagen duren voordat de cijfers in de gehele data-architectuur verwerkt zijn. Wat moet zo’n gebruiker in de tussentijd doen? Misschien wil hij of zij die gegevens ter plekke kunnen aanpassen, om daarna de analyse voort te zetten. Als dat inderdaad het geval is, dan moet binnen de architectuur bijgehouden worden en moeten die cijfers op een of andere manier in de oorspronkelijke bron aangepast worden.

In sommige data-architecturen wordt data vier keer gekopieerd voordat deze in een database belandt waartoe gebruikers toegang hebben. Dit proces kan zo lang duren en zoveel resources vereisen dat de data slechts één keer per 24 uur ververst kan worden. Als gebruikers willen dat de data niet ouder mag zijn dan 1 uur, dan kan dat niet. Dit is niet mogelijk met vier keer kopiëren. De data-architectuur voldoet dan simpelweg niet aan de wensen van de gebruikers.

Een ander voorbeeld betreft data science. In veel data science-projecten kan externe data een toegevoegde waarde hebben en soms zelfs cruciaal zijn. Als er te veel aandacht besteed wordt aan alleen de bronsystemen, dan past de ondersteuning voor het verwerken van die externe data mogelijk niet bij de rest van architectuur.

Wat ook wel eens fout gaat op het gebied van data science zijn de trainingsets. Data scientists maken vaak trainingsets met data aan. Deze moeten opgeslagen worden en vaak ook bewaard blijven voor auditing doeleinden. In sommige data-architecturen wordt deze mogelijkheid niet eens gecreëerd.

Metadata en aanbodgedreven data-architectuur

Bij een aanbodgedreven aanpak krijgt ook metadata soms te weinig aandacht. Er wordt bepaald welke metadata beschikbaar is en hoe en met welk product die opgeslagen gaat worden. Hierbij wordt wel nagedacht over welke metadata IT-specialisten, zoals ontwerpers, programmeurs en data warehouse specialisten, nodig hebben, maar ook hier wordt niet altijd voldoende nagedacht over hoe gebruikers metadata willen inzetten.

Het is belangrijk dat grondig geanalyseerd wordt welke metadata de gebruikers nodig hebben en hoe ze daarmee willen omgaan. Gebruikers willen bijvoorbeeld definities en toelichtingen zien terwijl ze een rapport bestuderen. Maar misschien willen ze niet dat ze die metadata in een apart systeem moeten opzoeken, maar dat deze automatisch verschijnt als ze met hun muis twee of drie seconden boven een bepaald datapunt blijven hangen. Of misschien willen ze ter plekke metadata, zoals een extra toelichting, in de vorm van annotaties kunnen toevoegen. Als andere gebruikers de metadata over hetzelfde datapunt opvragen, moet die annotatie ook verschijnen met een indicatie van wie deze ingevoerd heeft en wanneer. Als dit gewenst is, moet de data-architectuur dit mogelijk maken.

De vraaggedreven data-architectuur

Dit zijn allemaal typische voorbeelden van eisen die niet zomaar boven tafel komen als we de aanbodgedreven aanpak volgen. Het is dan ook beter om te kiezen voor een aanpak waarbij de behoeften van de gebruikers goed in kaart gebracht worden. De nadruk moet daarbij niet alleen liggen op welke data ze nodig hebben, maar ook op hoe ze de data én de metadata willen gebruiken. Dit is de vraaggedreven aanpak die leidt tot vraaggedreven data-architecturen.

Maar wat wordt in deze context bedoeld met het analyseren van de gebruikersbehoeften? Het betekent dat er niet alleen gekeken wordt naar welke data nodig is, maar ook naar andere aspecten. Welke aspecten dat zijn, hangt af van de gebruikers en hoe zij met data willen omgaan.

In het artikel van Gwyneth Ouwehand “In 5 stappen naar het perfecte dashboard” worden vijf heel duidelijke stappen beschreven die helder aangeven wat er precies geanalyseerd moet worden bij gebruikers van BI-dashboards.

In de eerste stap worden de functies van de gebruikers en het globale doel van de dashboards in kaart gebracht. Het resultaat van deze eerste stap wordt in persona’s (ofwel gebruikersprofielen) vastgelegd. Een persona beschrijft een gebruikerstype. In de tweede stap wordt in user stories beschreven wat gebruikers willen bereiken. De nadruk ligt hier op de taak en de werkwijze van de gebruikers en niet alleen op welke data ze nodig hebben.

Gebruikers kunnen ook klanten, patiënten of burgers zijn die de data slechts enkele keren per jaar nodig hebben. Het kan zijn dat niet precies duidelijk is hoe ze werken en wat ze er precies mee doen. In dit geval zal de nadruk liggen op de user interface. Een interface voor gebruikers die een applicatie tientallen keren per dag gebruiken, moet er anders uitzien dan een die slechts enkele keren per jaar gebruikt wordt. Voor dit soort gebruikers zal metadata in de vorm van toelichtingen belangrijk zijn. In de architectuur moet daar dus uitgebreid over nagedacht worden.

Een ander aspect om te bestuderen is de maximale latency van de getoonde data. Hebben de gebruikers een data latency van een paar seconden nodig om hun taak goed uit te voeren of is één dag oude data nog goed genoeg. Hoe lager de data latency, hoe minder kopieerslagen van de data gewenst zijn, omdat ze allemaal tijd kosten. Het kan ook geen kwaad om de schade te bepalen als niet aan de eis voor data latency voldaan wordt.

Zoals Gwyneth Ouwehand ook in haar artikel voorstelt, is het raadzaam om prototypes te ontwikkelen waarmee getest wordt of wat er gebouwd gaat worden inderdaad geschikt is voor de gebruikers.

Er zijn veel aspecten die belangrijk zijn om te bestuderen. Moeten geproduceerde rapporten auditable en reproduceerbaar zijn en zo ja, voor hoe lang? Bij dit soort eisen moet er in de architectuur van alles geregeld worden om het mogelijk te maken.

Conclusie

Sommigen zullen dit betoog een open deur intrappen vinden. Maar in de praktijk ligt de nadruk bij het ontwerpen van een nieuwe data-architectuur toch nog te vaak op de bronsystemen en de data-opslagpunten. Het is sterk aan te raden een meer vraaggedreven aanpak toe te passen. En om ervoor te zorgen dat de data-architectuur al die gebruikersbehoeften denkt. Dus ook bij het ontwerpen van een data-architectuur is de klant koning.