Weg met datasilo’s: één fundament voor alle data

Al jaren wordt bedrijfsdata beheerd binnen twee gescheiden systemen: operationele systemen voor de dagelijkse werking van applicaties (online transactional processing, ofwel OLTP) en analytische systemen (online analytical processing, ofwel OLAP) voor het vergaren van inzichten. Deze scheiding is destijds ontstaan vanwege beperkingen van de infrastructuur.

Deze opzet resulteerde ook in geïsoleerde teams die harder moesten werken en vertraagde besluitvorming. En terwijl ontwikkelaars vooral bezig waren applicaties draaiende te houden, moesten analisten werken met vertraagde of onvolledige data. Zelfs nu veel van de oorspronkelijke technische beperkingen door cloudinfrastructuur zijn weggenomen, blijft de OLTP/OLAP-scheiding bestaan. Tegenwoordig wordt deze vooral in stand gehouden door verouderde software, vendor lock-in en organisatorische traagheid, niet door noodzaak. Het is daarom tijd dat we dit model en onze omgang met data opnieuw tegen het licht houden.

De status quo doorbreken

Zodra data in een transactioneel systeem terechtkomen, wordt het lastig en duur om ze te verplaatsen. Bedrijfseigen opslagformaten en ingewikkelde architecturen houden data gevangen in transactionele systemen en blokkeren integratie met moderne data- en AI-workflows. En als de infrastructuur niet aansluit op de behoeften van data- en AI-teams, zullen ze eromheen gaan werken.

Moderne AI-agents en applicaties hebben snelle en betrouwbare toegang tot actuele data nodig. Maar als operationele data vastzit in legacy-omgevingen, wordt realtime automatisering, personalisatie en besluitvorming veel moeilijker. Dat remt niet alleen de ontwikkeling af, het beperkt ook de wendbaarheid, schaalbaarheid en de mogelijkheid om op tijd inzichten te halen uit snelgroeiende datavolumes.

Organisaties gaan daarom nu steeds vaker op zoek naar alternatieven die deze beperkingen wegnemen en een uniforme, responsieve basis bieden voor moderne datagedreven systemen.

Van fragmentatie naar één datafundament

Oorspronkelijk was de scheiding tussen OLTP en OLAP logisch omdat rekenkracht zo schaars was. Data-analyses uitvoeren naast operationele workloads was simpelweg niet haalbaar. Maar met cloud-native opslag zoals open table formats is het niet langer nodig om aparte pipelines op te zetten die operationele data beschikbaar maken voor analytics. Toch werken veel ondernemingen nog steeds met architecturen waarbij operationele data eerst moet worden geëxtraheerd, getransformeerd en ingeladen voordat het geanalyseerd kan worden. En dat leidt al snel tot meer vertraging, doublures en overheadkosten.

De impact van die belemmeringen is groot. Analisten baseren hun inzichten op verouderde informatie, en ontwikkelaars zijn vooral bezig met pipeline-beheer in plaats van nieuwe functionaliteiten. Innovatie vertraagt en de gemiste kansen stapelen zich op.

Als reactie hierop stappen meer organisaties over op een verenigde data-architectuur, waarbij operationele en analytische workloads gebruikmaken van één datafundament met engines die zijn geoptimaliseerd voor specifieke taken. Dit verlaagt de complexiteit, verhoogt de efficiëntie en maakt snellere iteratie mogelijk – cruciale voordelen in het AI-tijdperk.

Ontwerpen voor AI-agentsystemen

AI-agents zorgen voor een grote omslag in de manier waarop we applicaties ontwikkelen. Deze intelligente systemen kunnen complexe taken met meerdere stappen uitvoeren door te redeneren op basis van bedrijfseigen gegevens en in real time te communiceren met andere componenten van de IT-omgeving. En omdat agents beslissingen en acties kunnen coördineren en uitvoeren binnen het volledige data-ecosysteem, bieden ze meer dan eenvoudige automatisering en worden ze een essentieel onderdeel van de dagelijkse operatie.

Voordat agents eenvoudige automatisering kunnen overstijgen, moet de onderliggende infrastructuur mee veranderen. AI-agents hebben lage latency naar actuele data nodig, soepele integratie tussen systemen en moderne ontwikkelingsworkflows. Dat kan met behulp van een zogenoemde lakebase, een nieuw type database dat deze problemen direct aanpakt. Een lakebase combineert de betrouwbaarheid van een operationele database met de openheid van een datalake in één omgeving, zodat teams zowel transactionele als analytische workloads kunnen uitvoeren zonder tussen systemen te hoeven schakelen.

Een lakebase geeft snelle toegang tot data, schaalt eenvoudig doordat opslag en compute van elkaar zijn gescheiden, en sluit aan bij moderne ontwikkelpraktijken zoals instant branching en versiebeheer. Omdat het is ontworpen voor AI-gedreven workloads, kunnen zowel ontwikkelaars als AI-agents sneller applicaties bouwen, testen en uitrollen – zonder de beperkingen van traditionele OLTP-setups.

De weg vooruit

Als we vooruitkijken, beweegt de branche duidelijk richting openheid en convergentie. Organisaties hebben infrastructuur nodig die silo’s afbreekt, zowel analytische als operationele behoeften ondersteunt en ontwikkelaars de vrijheid geeft om snel te bewegen zonder in te leveren op betrouwbaarheid of prestaties.

Traditionele OLTP-systemen met rigide architecturen en vendor lock-in houden die ontwikkeling alleen maar tegen. Daarom is een andere benadering nodig op basis van open, interoperabele platforms die workloads verenigen en de prestaties, schaal en wendbaarheid bieden die AI-native applicaties nodig hebben.

De overgang naar zo’n nieuwe infrastructuur kost tijd. De organisaties die nu al aan de slag gaan om fragmentatie terug te dringen, openheid omarmen en hun architectuur ontwerpen met intelligente systemen in gedachten, hebben daarom op langere termijn een duidelijke voorsprong in de AI-race.