Stijn, je bentAnalytics Solution Advisor bij SAP. Als data enthousiast ben jij toch fan van data lakes en data warehouses, waar je alle gegevens tot je beschikking hebt, niet?

"Ja hoor, ik heb al heel wat interessante use cases gezien waarbij grote hoeveelheden data gestructureerd en ongestructureerd verzameld worden in bijvoorbeeld een data lake. En dat is handig voor een bepaalde groep geavanceerde gebruikers zoals bijvoorbeeld Data Scientists die op zoek zijn naar ruwe data. "

Stijn, leg uit

"Een data lake is data-agnostisch is: je kan er alle type data instoppen: gestructureerd, ongestructureerd, streaming... Maar agnostisch betekent ook dat wanneer je gegevens uit mooie gestructureerde bronnen soals SAP Core applicaties haalt, je gegevens ontdaan zijn van alle applicatie- en business context. Stel, je wil de facturatiehistoriek van een bepaalde klant analyseren. In de realiteit is een facturatiedocument in een SAP ERP samengesteld uit meerdere tabellen met complexe interne relaties, die samen een business object vormen: een rijke semantisch geheel dat door accountants perfect begrepen wordt. In een data lake zie je al die tabellen niet meer binnen hun business samenhang en moet de business context dus opnieuw opgebouwd worden.

Op het einde van de rit is de business terug afhankelijk van IT voor de set-up, maintenance en het beschikbaar stellen van de data. En moet IT beschikbaar zijn voor elke nieuwe vraag van de business om aanpassingen door te voeren. Ook op lange termijn schuilen er uitdagingen. Wanneer bijvoorbeeld SAP beslist om het bronsysteem te updaten, kan dit een grote impact hebben op de structuur van de data. Bij elke update van elke bedrijfsapplicatie moet IT nagaan of er wijzigingen zijn en hoe ze deze - indien nodig - ook kunnen doorvoeren.

Stijn Debever, Analytics Solution Advisor bij SAP

Een data lake lost dus niet alle problemen op, maar het beschikbaar hebben van alle data op één plaats in de cloud is voor de meeste organisaties toch een grote stap voorwaarts?

Een "one single source of truth" blijft belangrijk, maar ik zie bij een aantal bedrijven een move naar een "Data Mesh". Dus eerder het connecteren naar waar de data zich bevinden dan het dupliceren van al deze data. Een mesh biedt bovendien de mogelijkheid om verschillende departementen ownership over hun data te geven en te laten collaboreren op data in selfservice mode.

Hoe zie jij dan de ideale architectuur om je data in de cloud te brengen?

Ga uit van jouw use case en je bronsystemen. Is het de bedoeling om end-users toegang te geven tot de data om analyses uit te voeren en inzichten te laten krijgen in deze data? En bevinden je business critical data zich in een SAP Systeem? Dan is SAP unmatched om fast time to value op deze data en bronnen te brengen en deze data met non-sap data te verrijken. Wanneer je eerder kijkt naar Data Science usecases op non-sap data, data die ongestructureerd zijn en/of streaming, dan hebben ook zeker hyperscalers met hun data lakes hun rol in je data architectuur.

Wil je meer halen uit de data met SAP? Contacteer Stijn Debever of ontdek wat SAP data warehouse cloud voor uw organisatie kan betekenen. Aarzel niet om dit artikel te lezen, het geeft je een goede samenvatting van de uitdagingen waarmee bedrijven vandaag kampen.

Stijn, je bentAnalytics Solution Advisor bij SAP. Als data enthousiast ben jij toch fan van data lakes en data warehouses, waar je alle gegevens tot je beschikking hebt, niet?"Ja hoor, ik heb al heel wat interessante use cases gezien waarbij grote hoeveelheden data gestructureerd en ongestructureerd verzameld worden in bijvoorbeeld een data lake. En dat is handig voor een bepaalde groep geavanceerde gebruikers zoals bijvoorbeeld Data Scientists die op zoek zijn naar ruwe data. ""Een data lake is data-agnostisch is: je kan er alle type data instoppen: gestructureerd, ongestructureerd, streaming... Maar agnostisch betekent ook dat wanneer je gegevens uit mooie gestructureerde bronnen soals SAP Core applicaties haalt, je gegevens ontdaan zijn van alle applicatie- en business context. Stel, je wil de facturatiehistoriek van een bepaalde klant analyseren. In de realiteit is een facturatiedocument in een SAP ERP samengesteld uit meerdere tabellen met complexe interne relaties, die samen een business object vormen: een rijke semantisch geheel dat door accountants perfect begrepen wordt. In een data lake zie je al die tabellen niet meer binnen hun business samenhang en moet de business context dus opnieuw opgebouwd worden.Op het einde van de rit is de business terug afhankelijk van IT voor de set-up, maintenance en het beschikbaar stellen van de data. En moet IT beschikbaar zijn voor elke nieuwe vraag van de business om aanpassingen door te voeren. Ook op lange termijn schuilen er uitdagingen. Wanneer bijvoorbeeld SAP beslist om het bronsysteem te updaten, kan dit een grote impact hebben op de structuur van de data. Bij elke update van elke bedrijfsapplicatie moet IT nagaan of er wijzigingen zijn en hoe ze deze - indien nodig - ook kunnen doorvoeren.Een "one single source of truth" blijft belangrijk, maar ik zie bij een aantal bedrijven een move naar een "Data Mesh". Dus eerder het connecteren naar waar de data zich bevinden dan het dupliceren van al deze data. Een mesh biedt bovendien de mogelijkheid om verschillende departementen ownership over hun data te geven en te laten collaboreren op data in selfservice mode.Ga uit van jouw use case en je bronsystemen. Is het de bedoeling om end-users toegang te geven tot de data om analyses uit te voeren en inzichten te laten krijgen in deze data? En bevinden je business critical data zich in een SAP Systeem? Dan is SAP unmatched om fast time to value op deze data en bronnen te brengen en deze data met non-sap data te verrijken. Wanneer je eerder kijkt naar Data Science usecases op non-sap data, data die ongestructureerd zijn en/of streaming, dan hebben ook zeker hyperscalers met hun data lakes hun rol in je data architectuur.