Advertorial

Door Tweakers Partners

De opkomst van cloud-data-lake bij Aegon

31-05-2021 • 08:00

14

Met een nieuwe data-cloudomgeving gebaseerd op AWS heeft Aegon zich losgemaakt van de beperkingen van legacy-systemen. Tijdens de Developers Summit (2-5 juni) vertellen enkele betrokken IT’ers hoe Aegon data uit verschillende bronnen in realtime naar de cloud kan synchroniseren vervolgens onder meer voor financiële risicoanalyses gebruikt.

De financiële dienstverlening is de afgelopen jaren onherkenbaar veranderd. En de ontwikkelingen gaan nog steeds in razendsnel tempo door. Denk aan de maatschappelijke gevolgen van vergrijzing, maar ook aan de verschuiving van face-to-face financieel advies naar online tooling waarmee consumenten zelf verder kunnen komen. Het doel van Aegon is om mensen te helpen verder vooruit te kijken en financiële zekerheid te krijgen. De strategie bij Aegons IT is dat dit zoveel mogelijk ‘data-driven’ wordt ingestoken.

devsummit

Met het cloud-data-lake kan Aegon data in realtime uit legacy-mainframesystemen halen, maar ook uit bedrijfsapplicaties en meer. “We zijn de afgelopen jaren steeds meer een data-driven company geworden”, vertelt sr. capability manager Jasper Buschgens. “Tegelijkertijd staan nog altijd veel enterprise-applicaties en onze klantendatabase in mainframe-omgevingen. Om bijvoorbeeld data-analyses en modelvalidaties te kunnen uitvoeren, wil je data uit deze systemen realtime, veilig en accuraat in een omgeving hebben waarin je ermee kunt werken.” Jasper ziet dat veel bedrijven query’s rechtstreeks op de onderliggende databases uitvoeren. “Dat zorgt voor extra belasting op die systemen. Het lost het probleem van datasynchronisatie tussen de verschillende systemen niet op en is ook niet de veiligste oplossing.”

Data ontsluiten en publiceren

Datawarehousing was het alternatief, maar architecten bij Aegon maakten een grotere stap door een data-lake te ontwerpen in AWS. “Het data-lake is een grote kopie van al onze kerndatabases. Om data te ontsluiten en te mogen gebruiken, moet elke gebruiker precies aangeven welke data hij nodig heeft, voor hoe lang en waarvoor. Dit in verband met de privacywetgeving in de AVG.”

Op basis van deze eisen ontsluit een team bij Aegon datasets. “Soms is dat permanent, bijvoorbeeld voor de Aegon-app waarmee klanten bankgegevens en hun pensioenwaarde kunnen inzien. Het kan ook tijdelijk zijn, bijvoorbeeld wanneer onze marketingafdeling een data-analyse wil uitvoeren. De datasets voor deze toepassingen worden als brokken gegeven, kunnen eindig zijn en zijn alleen benaderbaar voor het vooraf bepaalde doel.”

De cloud-data-lakeoplossing voorziet in een verantwoorde data-publication, maar ook in data-ingestion. Hoe krijg je de juiste data uit applicaties, transformeer en verrijk je hem waar nodig en zorg je dat hij altijd up-to-date is? “Stel, iemand geeft een adreswijziging door en deze is nog niet gerepliceerd in het data-lake, maar je start wel een marketingcampagne waarbij de oude data nog wordt gebruikt. Dat is niet ideaal natuurlijk. Nog pijnlijker is het als het bijvoorbeeld gaat om verouderde data van een klant die al is overleden.” Het op orde krijgen en houden van data is onder andere het werkterrein van de data-engineers. “Je moet velden combineren en controleren of data uniform is. Vervolgens kun je hem verrijken met informatie uit onder meer pensioensystemen. We werken ook veel met keywords, metadata en zoekcriteria om data te matchen. We kunnen daarmee zowel gestructureerde als ongestructureerde data hanteren.”

Kijkje onder de motorkap - Tweakers Developers Summit

Tijdens de Developers Summit verzorgt Jasper samen met twee medewerkers uit de devops-teams op 2 juni een talk in de devops-track van het event.

Data-engineer Sushma Chakravadhanula zal hierbij een rol spelen, net als Bram de Mooij die de data gebruikt op de Finance-afdeling van Aegon. “We laten echt de details van het systeem zien, dus wat er onder de motorkap zit. Daarbij zullen Sushma en Bram code demonstreren en ingaan op de gebruikte technologieën en methodologieën.” Jasper hoopt dat developers enthousiast worden door het verhaal, maar ook een boodschap meekrijgen. “Verzekeraars en banken zijn van nature misschien wat conservatief. We hebben een imago van mainframes, legacy en achterstallige technologie. Maar dat is enkel het beeld aan de buitenkant en in ieder geval bij Aegon niet terecht. Wij omarmen zoveel mogelijk moderne technologieën en oplossingen zodat we onze klanten optimaal bedienen. Met ons data-lake hebben we verschillende prijzen gewonnen en dit is maar één van de projecten waar we aan werken.”

Hoewel het platform enkele jaren geleden is opgeleverd, gaat de ontwikkeling nog altijd door. Vijf devops-teams werken continu aan de cloud-data-lake. “We kijken onder meer hoe we efficiënter met data om kunnen gaan en hoe we veiliger en sneller kunnen publiceren. Tegelijkertijd zijn er verschillende applicaties die worden uitgefaseerd of gemigreerd. We moeten wel zorgen dat data daaruit beschikbaar blijft.” Elk kwartaal definiëren gebruikers uit de business een wensenlijst via zogeheten PI-events. “Deze punten krijgen prioriteit, maar daarna is het aan de teams hoe ze het oplossen. Dat kan bijvoorbeeld door het maken van nieuwe datasets, maar het komt ook voor dat een vraag zo uniek is dat ze met een andere taal gaan werken. Bij data-lake wordt veel gebruikgemaakt van Python, maar het kan in sommige gevallen ook interessant zijn om in R te programmeren. We geven developers deze ruimte.” De laatste sprint (van twee weken) in elk kwartaal (PI-event) is overigens helemaal een ‘feestje’ voor developers. “Dat is een innovatiesprint waar developers bij het data-lakedomein in principe zelf invulling aan mogen geven. Ze mogen dan bouwen of doorontwikkelen aan wat ze willen of nuttig vinden, op hun eigen manier.”

Data-lake 2.0 op komst

Inmiddels worden de contouren van het traject ‘Data-lake 2023’ duidelijk, meldt Jasper. “De teams onder leiding van productmanager Gerrie Minnaard kijken nu hoe dit vorm krijgt en zullen dit platform mogelijk grotendeels herbouwen. Feitelijk gaat het om een soort Data-lake 2.0. We zitten nu in de designfase.” De lessen die zijn opgedaan bij het bouwen van het eerste data-lake worden meegenomen naar het nieuwe traject. “Van Gerrie, die medeverantwoordelijk was voor de bouw van het data-lake, heb ik begrepen dat het heel belangrijk is geweest dat we dit met zijn allen zouden doen of helemaal niet. Er was en is geen ruimte voor eigenaren van applicaties om data op een andere manier te ontsluiten. Dit was een designprincipe dat met hand en tand is verdedigd en waar het managementteam van Aegon volledig achter staat. Daardoor hebben we nu de kracht van een compleet data-lake.”

Benieuwd geworden naar het data-lake en wil je een kijkje nemen in de code? Of wil je meer weten over de analyses die Aegon draait met realtime data, ontsloten uit mainframesystemen? Ontdek het tijdens de Developers Summit, een digitaal event van 2 tot en met 5 juni. Kijk hier voor meer informatie over het programma en om je ticket te registreren.

Dit artikel is geen redactioneel artikel, maar een advertorial en tot stand gekomen dankzij Aegon en Tweakers Partners. Dit is de afdeling binnen Tweakers die verantwoordelijk is voor commerciële samenwerkingen, winacties en Tweakers-events zoals Meet-ups, Developers Summit, Testfest en meer. Kijk hier voor een overzicht van alle acties en events. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen].

Reacties (14)

14
14
3
1
0
11
Wijzig sortering
Als ik het goed begrijp is een datalake een kopie van je productiedata om zo de eigenlijke productieservers te ontlasten. Beetje slim synchroniseren en vervolgens mag iemand daar een uurtje mee querieen als hij of zij dat aanvraagt.

Maar als het om allerlei databases gaat, hoe kan dan ineens wel de security gewaarborgd worden? Hoe voorkom je dan ineens wel dat iemand zaken kan zoeken waar die geen rechten op heeft? Vooropgesteld dat het uurtje querieen toegewezen is. En waarom kunnen diezelfde rechten bijvoorbeeld niet op een productie omgeving worden ingesteld? En voordat iemand zegt: Dan moet je het seminar bijwonen, sorry, maar ik moet gewoon werken, ik kan niet een paar dagen een seminar bijwonen
Die productie databases zijn de backend van operationele transactional systemen. Die zijn ontworpen om de dagelijkse business te ondersteunen. Dan gaat het vaak om het opvragen en bewerken van een enkele case. Ergo: database geoptimaliseerd voor opvragen 1 of enkele regels.

Dat is heel wat anders dan analytische query’s. Die combineren (veel) data. Over bronnen heen. Daarvoor optimaliseer je je platform voor het ophalen van veel regels, combineren en aggregeren.

Qua security is het niet zo dat de toegang binair is (alles of niets). Toegang kan je op een modern platform regelen op rij-niveau. Zeker omdat je dat centraal doet, in een daarvoor ontworpen platform, gaat de waarborging van security en privacy omhoog.
Qua security is het niet zo dat de toegang binair is (alles of niets). Toegang kan je op een modern platform regelen op rij-niveau. Zeker omdat je dat centraal doet, in een daarvoor ontworpen platform, gaat de waarborging van security en privacy omhoog.
Was het maar zo simpel.

Je kan aan de IT kant inderdaad een robuuste security infrastructuur neerleggen, maar die moet zich wel ergens op baseren. Als je veel geluk hebt kom je met functie/afdeling een eind, maar vaak blijkt dat onvoldoende, bijvoorbeeld omdat je eigenlijk naar rollen zou moeten kijken ipv functies, en die worden niet in het HR systeem bijgehouden. Dan worden er bijvoorbeeld LDAP groepen aangemaakt om toegang tot bepaalde data te regelen. Toegang verlenen tot z'n groep is goed te regelen, maar wanneer wordt die weer weggehaald? Dat soort onderhoudsproblemen maken het echt lastig.
Ben ik helemaal met je eens. De basis, die ik in drie zinnen schreef, is simpel. De praktijk veel weerbarstiger. Het levert mij al jaren werk op ;)

Je maakt een heel belangrijk punt door rollen te benoemen. Dit is de enige degelijke basis voor privacy bewuste informatievoorziening en digitalisering. Op zowel systeem als proces en organisatie moet dit vaak nog goed ingericht worden.

Bij het opzetten van een nieuw data platform zoals Aegon, heb je de kans een aantal dingen meteen goed te doen. Al zit je ook dan nog wel eens vast aan ongewenste legacy zoals een chaos in de AD groepen...
Leuk verhaal. Herkenbaar. Wel verbazingwekkend dat er geen centraal data warehouse was? Ik mag hopen dat er decentrale data warehouses waren...

Ook een grote stap om direct naar data lake te gaan zonder data warehouse. Ik neem aan dat er naast data lake ook diverse governance oplossingen zijn (MDM, lineage), anders gaat het snel naar een data swamp toe.

Ik ben benieuwd wat voor structuren er zijn, hoe de storage is (Delta, csv, parquet enz) en hoe de compute geregeld is (Lamba, Spark, Databricks?), wat de verversingssnelheid is en wat uiteindelijk dit gehele traject opgeleverd heeft.
Drain the Data-Swamp, iets waar we de komende jaren zeker nog mee te maken gaan hebben lijkt me.
Maar idd, ik ben ook nieuwsgierig wat nu in deze case concreet de voordelen zijn ten opzichte van de DataWarehousing aanpak. Uit het artikel kan ik enkel af leiden dat er een hogere graad van afscherming/authorisatie is..
Eentje om in het oog te houden op de summit!
En zijn je vragen beantwoord tijdens de presentatie?
Zo verbazingwekkend is het niet dat er geen centrale datawarehouse is. Voor een groot bedrijf als Aegon met veel afdelingen en business lines met een groot aantal applicaties (honderden verschillende applicaties misschien?) is het ondoenlijk om alles in één datawarehouse te stoppen. Het is dan logisch dat er decentrale datawarehouses bestaan (in welke vorm dan ook).

Je moet ook niet vergeten dat Aegon een financieel dienstverlener is. Deze branche is onderhevig aan veel regelgeving waardoor praktische IT oplossingen die gangbaar zijn in andere (minder gereguleerde) bedrijfstakken niet altijd mogelijk zijn.
Er waren twee centrale data warehouse oplossingen. 1 voor marketing en 1 voor finance. Elke wijziging in een data warehouse werd een hele opgave en de performance degradeerde. Een andere belangrijk punt was dat wanneer je iets wil toevoegen aan een data warehouse je eigenlijk dat wil doen met terug werkende kracht. Daarvoor zou je de ruwe input data moeten bewaren wat natuurlijk niet was gedaan. Dus op zoek naar een betere oplossing...data vault! Met een data vault modeleer je alles naar een specifiek data model om alle data te bewaren. Mooi idee maar had ook weer zijn uitdagingen.
Data lake is alles in object storage gooien en misschien later wel gaan gebruiken want storage kost niks meer...
Bij Aegon is ervoor gekozen om data uit het data lake to publiceren. Dus mensen krijgen niet toegang tot het data lake maar krijgen een fit-for-purpose data set specifiek voor hun doel. Er zijn data stewards in dienst die beoordelen of een data verzoek valide is. Voorlopig blijft het dus mensenwerk.
Wil je weten hoe dit allemaal samenwerkt dan moet je naar de summit "komen" ;)
Ah het befaamde data vault. Wat een drama was dat. Een data lake is in principe schemaloos en data vault was het compleet tegenovergestelde. Alles zover uitgemodelleerd dat je van ellende niet meer wist waar je tegen aan zat te kijken. In Nederland is Data vault heel populair, maar ik heb nooit echt begrepen waarom.

We hebben hier een Historical Data Archive (HDA) onder onze data marts zitten, zodat we ruwe en historische data hebben. Daar zitten we nog wel op te puzzelen, want zuiver gezien hoeft dat niet in een data warehouse te zitten. Liever in een lake met goedkope opslag ;-)
Data vault klinkt op papier heel mooi en efficient. We hebben een mooie engine gebouwd zodat een nieuwe bron aansluiten "weinig" werk zou zijn. Helaas kregen wij het niet voor elkaar om de analisten hun bron data model te laten vertalen naar een DV model. Daar zit echt serieus veel werk in en hebben we echt onderschat. Vooral het argument "Waarom zou ik het hele model vertalen terwijl het niet eens gebruikt wordt?!". Dus na twee jaar trekken aan een dood paard alle pijlen op cloud (AWS) gericht. DV voed nu nog een data warehouse welke we aan het ontmantelen zijn ten gunste van het data lake (data platform).
Het uitzetten van dit soort monolieten is ook een drama. Gemaakt om 24/7 te werken dus daar betaal je ook voor.
Komt bekend voor. Iets waar ik mee bezig ben geweest bij een oudwerkgever van me.
Ook een verzekeraar.

De hoeveel data die er ligt is zo groot dat traditionele datawarehouses niet meer voldoen voor rapportage doeleinden.. De doorlooptijden van de standaard ETL processen worden gewoon te groot en de inflexibiliteit van de traditionele datastructuren zorgen ervoor dat wijzigingen in die datastructuren erg lang duren voordat deze opgenomen kunnen worden in een DWH.
.
Door de data realtime te streamen naar een datalake heb je de mogelijkheid om rapporten over operationele data te draaien zonder dat je de bron belast. En doordat de data in ruwe vorm in de datalake staat, kun je de transformaties aan de voorkant/frontend houden. Dit maakt je data veel flexibeler en kun je analyses maken over je data die met traditionele datawarehouses erg lastig te realiseren zijn.
En het lijkt mij ook dat een dataset niet alle kolommen hoeft te bevatten, maar alleen de kolommen die voor die applicatie nodig zijn.

Ik hoop alleen voor de ontwikkelaars dat die security niet alle plezier uit het werk haalt doordat overal aanvragen voor gedaan moeten worden (en alle problemen die sommige organisaties dat in dat proces weten te stoppen).
Klopt. Dit noemen we fit-for-purpose. De security check wordt gedaan door data stewards (elke business unit heeft er 1). De goedkeuring wordt vastgelegd in Collibra (meta data tool) en tijden publiceren controleert onze PubEngine of deze matchen.
Over niet al te lange tijd zal het data verzoek ook in Collibra gedaan kunnen worden waardoor het een webshop ervaring zal worden. Data in je winkelwagen > afrekenen > order wordt gecontroleerd > data wordt geleverd. Blije klant!

Op dit item kan niet meer gereageerd worden.