Logisch Data Warehouse
Een logisch data warehouse is meer dan technologie!

Er is nogal wat te doen over het logisch data warehouse en de toepassing van datavirtualisatie de laatste tijd. En niet voor niks, want een logisch data warehouse architectuur biedt grote voordelen en allerlei nieuwe kansen om data slimmer te gebruiken. Diverse artikelen daarover vind je hier, hier en hier. Mattijs Voet legt in zijn laatste blog artikel goed uit hoe je de business case voor een implementatie van een logisch data warehouse uitrekent. In de praktijk zie ik echter dat veel bedrijven nog moeite hebben om de voordelen en kansen van deze nieuwe architectuur te verzilveren. Meestal om dezelfde reden: een puur technische benadering, waarbij geswitcht wordt naar een andere technologie voor data-integratie (bijv. van ETL naar datavirtualisatie), maar alle processen en werkwijzen precies hetzelfde blijven. Maar om de belofte van het logisch data warehouse volledig waar te maken, is heel wat meer nodig!

Vier invalshoeken

Een puur technische migratie naar een logisch data warehouse zal best voordelen opleveren voor wat betreft ontwikkeltijd en –snelheid. Door data niet langer (meerdere malen) te dupliceren, worden het doorvoeren van aanpassingen, het uitvoeren van testen en de in productiename nu eenmaal eenvoudiger.

Maar pas als je je manier van werken kritisch onder de loep neemt, zullen de voordelen maximaal zijn. Data is niet meer een bijproduct voor verslaglegging over het verleden, het is de brandstof van je bedrijf geworden. En dat heeft grote gevolgen voor strategie, cultuur en competenties van medewerkers. Zorg dat je data durft te ontdekken, in plaats van alles van tevoren af te bakenen.

Maximaal profiteren van een architectuur die data veel eenvoudiger en sneller beschikbaar maakt, heeft meer voeten in de aarde dan alleen een nieuwe technologie implementeren. Het vraagt, naast een keuze in tools & architectuur, om veranderingen vanuit drie andere invalshoeken die ik in dit artikel nader onder de loep zal nemen:

 

Blog Kadenza Logisch data warehouse

Strategie & Informatie

Zeggen dat je datagedreven wil werken is één, het ook echt doen is een tweede. Dat ‘doen’ zou niet moeten bestaan uit allerlei losse initiatieven, maar verankerd moeten zijn in een bedrijfsbrede strategie. Waarin je niet alleen zegt dat data belangrijk is, maar ook hoe de informatie die verborgen ligt in die data de motor wordt achter nieuwe producten en diensten en je het bedrijf daar ook echt op aanpast. En dat is best lastig voor bedrijven die gewend zijn om hun processen centraal te stellen en niet hun data. Terwijl juist de flexibiliteit om processen aan te passen op basis van wat de data vertelt steeds crucialer wordt voor bedrijven om te overleven.

Een mooi voorbeeld hiervan is het verschil in strategie waarmee Netflix en Blockbusters reageerden op een afnemende vraag naar videoverhuur. Netflix draaide het traditionele model volledig om door video ‘naar de gebruiker’ te brengen, waarmee het bedrijf tegelijk allerlei waardevolle gebruiksdata kon verzamelen. Terwijl Blockbusters (in eerste instantie) vasthield aan het bestaande proces en probeerde met mooiere winkels en gratis koffie consumenten toch naar de winkel te krijgen.

Een andere veelgemaakte fout is het idee dat bij het implementeren van zo’n strategie iedere ontwikkeling meteen perfect moet zijn en breed toegepast moet worden. Datagedreven worden is een proces van experimenteren en groeien, waarbij er ruimte moet zijn om – in een beschermde omgeving – fouten te maken. Niet elk experiment hoeft meteen tot een oplossing te leiden en niet alle data vanaf het begin volledig betrouwbaar te zijn. Dat vraagt dus ook om verschillende niveaus van data governance. De regels voor data die je nog aan het ‘ontdekken’ bent, zijn anders dan voor informatie die gepubliceerd wordt in een jaarrekening.

Organisatie & Proces

Een succesvolle logisch data warehouse implementatie zorgt ervoor dat je bedrijf veel wendbaarder wordt. Maar alleen als je je ontwikkelprocessen ook flink aanpakt. Gaan werken in Scrum-teams en tweewekelijkse sprints alleen is niet de oplossing. Want zolang we met die teams nog steeds alles ‘defensief’ ontwikkelen (de functioneel ontwerper haalt de requirements op bij de gebruiker, vertaalt dit in een ontwerp dat de ontwikkelaar bouwt en vervolgens wordt er uitgebreid getest, alles in een verregaand geformaliseerde OTAP-omgeving) zal de opleversnelheid niet significant korter worden. Omdat het daadwerkelijk bouwen vaak maar 15% uitmaakt van het totale proces is de besparing in inspanning en doorlooptijd niet meer dan 10%. Terwijl we zoeken naar een verbetering van 80% of meer!

Defensief ontwikkelen werkt niet voor experimenten en innovatie. Wat je nodig hebt is een manier om nieuwe data-producten experimenteel en stapsgewijs te ontwikkelen in de productie-omgeving en die vervolgens – na gebleken succes – operationeel te maken en breder beschikbaar te stellen. Een omgekeerde OTAP-omgeving dus…

Daarvoor kunnen we gek genoeg terugvallen op een idee dat al meer dan 15 jaar oud is: het pace layer model van Gartner:

In de Systems of Innovation laag wordt experimenteel ontwikkeld in productie. Als de resultaten de moeite waard zijn voor bredere toepassing in de organisatie, wordt de oplossing in gebruik genomen in de Systems of Differentiation laag. Wordt de toepassing bedrijfskritisch, bijvoorbeeld omdat de informatie gebruikt wordt voor externe rapportage of in communicatie met klanten, dan wordt hij verplaatst naar de Systems of Record laag. Belangrijk hierbij is dat het mogelijk is om ontwikkelde software te ‘promoten’ tussen de lagen. De verschillende lagen in het pace layer model hebben andere eisen en regels voor testen en governance.

Een logische data warehouse architectuur is geknipt voor het pace layer model. Door de volledige ontkoppeling van bronsystemen en informatieproducten kunnen we de data integratie verankeren en robuuster maken, terwijl de informatie blijft werken. De Systems of Innovation laag is een pure productie omgeving (P). De Systems of Differentiation laag kent wel een acceptatie omgeving (AP) om impact en gebruik van de nieuwe data-ontsluiting of informatieservice te testen. De Systems of Record laag werkt met een volledige OTAP-omgeving zoals we die traditioneel kennen om robuustheid en betrouwbaarheid van informatie te kunnen garanderen. Het virtuele karakter van het logisch data warehouse maakt – zeker bij gebruik van een datavirtualisatieplatform – het verplaatsen van informatiestromen tussen de verschillende lagen eenvoudig te implementeren.

Cultuur & Gebruikers

Zulke drastische veranderingen in je strategie en werkwijzen zijn natuurlijk alleen mogelijk als je aandacht besteedt aan de competenties en ‘mindset’ van alle mensen in je organisatie. Het is makkelijk om te zeggen dat experimenteren met data prima is, maar als de IT-afdeling zegt dat je data alleen mag benaderen vanuit je standaardrapport op het door en door geteste data warehouse, komt dat niet verder dan een mooi idee. En als medewerkers dan maar zelf gaan experimenteren met data, komt het vaak ook niet verder dan een leuke proefballon.

Een bedrijfscultuur waarin het voor iedereen normaal is om te experimenteren met data, is dan ook van groot belang. Een cultuur waarin het normaal is om ‘fouten’ te maken. Omdat die fouten toch wel gemaakt worden en je ze beter kunt maken op de juiste plek, voordat ze grote consequenties hebben. In een datagedreven organisatie kan een marketingmedewerker in één dag een experiment opzetten voor een nieuwe marktbenadering met een slimme A/B-test gebaseerd op historische data over klantgedrag. Als dat experiment succesvol is, kun je het in korte tijd herhaalbaar maken voor andere gebruikers door een promotie naar de Systems of Differentiation laag. En wil je deze aanpak volledig automatiseren? Dan implementeer je die vervolgens – met andere tooling en volledige data governance – in je operationele systemen.

Bij veel bedrijven overheerst nog de angst om data uit de Systems of Differentiation laag – of zelfs de Systems of Record laag – vrij te geven aan gebruikers. Vaak omdat de IT-afdeling zich gedraagt als eigenaar van de data (wat ze natuurlijk niet is!). Het is belangrijk om te werken aan een gevoel van partnerschap tussen de IT-afdeling en de business, waarin wordt samengewerkt aan innovatieve oplossingen die het bedrijf verder helpen. Waarin de business enerzijds de ruimte heeft om te experimenteren met data om nieuwe producten, diensten en processen te bedenken (met oplossingen die door IT in beheer worden genomen). Maar anderzijds ook het vertrouwen heeft in dataproducten die ze van IT tot haar beschikking krijgt.

Tot slot

Ik hoop dat ik duidelijk heb gemaakt dat er meer nodig is dan een verandering van tools en architectuur om de voordelen van een logisch data warehouse en/of datavirtualisatieplatform ten volle te benutten. Voor het snel terugverdienen van je investeringen in een nieuwe data-architectuur moet je ook je strategie, werkwijzen en bedrijfscultuur onder de loep nemen. Gelukkig is het goede nieuws dat je daarbij niet bang hoeft te zijn voor slechte resultaten. Want door optimale ondersteuning van experimenten, ontstaan nieuwe informatieproducten niet op basis van vage wensen of aannames, maar door daadwerkelijk gebruik van de data. En dat is uiteindelijk de beste test voor ieder product, het gebruik zelf!

Staat het woord ‘data’ in jouw strategisch plan?