Wanneer architectuur de zwaartekracht bestrijdt, betalen operationele afdelingen de prijs

• • • • • • Voor in de storage geïntegreerde stacks wordt ervan uitgegaan dat data naar de namespace komen. De factoren die werken in een onderneming, weerspreken dit.
          • De pitch ‘Unified namespace’ vormt een weddenschap tegen de drie vormen van data.
          • De architecturale belasting is structureel: pijplijneigendom, afstemmingsschuld, schema-koppeling, governance dubbele boekhouding, ondoorzichtigheid van kosten.
          • Externe factoren (regelgeving, koppeling van applicaties, contracten, eigendom) zorgen ervoor dat de belasting permanent is, niet tijdelijk.
          • Een federatief controleniveau werkt op data waar deze zich bevinden en verplaatst deze alleen wanneer het verplaatsen het juiste antwoord is.

Als u AI-dataplatforms evalueert, zijn de posten op de offerte niet uw enige kosten. De daadwerkelijke kosten komen later aan het licht: In de pijpleidingen die u moet bouwen, de mensen die u toewijst om ze correct werkend te houden en de keuzemogelijkheden die u opgeeft elke keer dat data moeten worden verplaatst om bruikbaar te zijn.

Data has gravity, the real enterprise estate is full of distortions that hold data in place, and “data” itself isn’t one substance — it’s three forms (data, metadata and vectors), each with different characteristics and requirements. This post is about what happens when an architecture pretends those laws don’t apply.

De architecturale aanname onder elke storage-embedded stack

In storage geïntegreerde AI-stacks, met een VAST AI-OS als het meest zichtbare voorbeeld, zijn gebouwd op één architecturale aanname: de AI-services worden uitgevoerd op data die al naar platform zijn gebracht. Ze moeten zich in het platform bevinden. Vanuit het oogpunt van het platform is alles buiten de namespace onzichtbaar.^1,4

Het platform wordt geleverd met tools om data te importeren. Het wordt geleverd met een verhaal over hoe het centraliseren van data activiteiten vereenvoudigt. Het wordt geleverd met een uniforme UI die, in de demo, de gehele omgeving als één schoon geheel laat lijken.

Dat verhaal is intern consistent. Het is ook een weddenschap tegen de structurele krachten die op bedrijfsomgevingen werken.

De drie formulieren geven aan dat u de zware data niet hoeft te verplaatsen

Wat ondernemingen ‘data’ noemen, zijn eigenlijk drie verschillende dingen:

• • Data – zwaar. Blijft waar het is. Bestanden, records, beelden, video, telemetrie, gereguleerde tabellen.
  • Metadata – lichtgewicht. Goedkoop om te verspreiden. Laat elke AI toegang hebben tot alle assets, waar deze zich ook bevinden.
  • Vectoren – Localiteitsgevoelig. Draag betekenis over op de bedrijfsomgeving zonder de data zelf te dragen.

Architecturen die alle drie als dezelfde substantie behandelen, geven standaard één slecht antwoord: verplaats alles. Architecturen die ze als verschillend behandelen, kunnen de zware data beheren waar ze zich bevinden, metadata verspreiden over de omgeving en vectoren de omgevingsoverschrijdende interactie bieden die AI eigenlijk nodig heeft.

Een uniforme namespace is een coherent antwoord als de enige vorm die u herkent data is. Het is het verkeerde antwoord op het moment dat u accepteert dat naast data ook metadata en vectoren bestaan als eersteklas burgers.

De architecturale belasting van het naar binnen trekken van de omgeving

Wanneer een architectuur is gebouwd op basis van de aanname dat data moeten aanwezig moeten zijn voordat AI deze kan verwerken, wordt elke externe factor in uw onderneming een operationele verplichting:

• • Eigendom van pipeline. Voor alle bronnen, waaronder Snowflake, SharePoint, S3 en Kafka, storage van derden, SaaS, is een synchronisatietaak nodig.¹ Elke synchronisatietaak wordt uitgevoerd door een mens.
  • Reconciliatieschuld. Elke kopie wijkt af van de bron. Schema-drift, regionale latentiepieken, stille afbrekingen wanneer de lengte van een bronveld verandert en waarvan niemand op de hoogte is gebracht. Die drift moet altijd worden gedetecteerd en gecorrigeerd door een mens.
  • Schemakoppeling. Wanneer bronsystemen veranderen, kunnen downstreamkopieën en de AI-services die hiervan afhankelijk zijn, defect raken.
  • Bestuurlijke dubbele boekhouding. Toegangscontroles, retentiebeleid, bewaarplicht en audittrails moeten twee keer worden bijgehouden, zowel in de bron als in de kopie.
  • Ondoorzichtigheid van kosten. Uw FinOps-team volgt nu dataverplaatsing, storageduplicatie en uitvoer in een architectuur die is verkocht als consolidatie.

Niets hiervan is te kwader trouw verborgen. Het is structureel. Het is wat er gebeurt als een gesloten, in storage ingebed model een open, gedistribueerde dataomgeving ontmoet en probeert deze omgeving naar binnen te trekken.^1,4

De taal van de leverancier is hier belangrijk. ‘Synchronisatie-engine is gratis’ en ‘synchronisatie is gratis’ zijn niet dezelfde zin. Een synchronisatietaak is geen eenmalige migratie. Het is een permanente relatie tussen twee systemen die voor altijd consistent moeten worden gehouden: tegen schemawijzigingen, netwerkgebeurtenissen, machtigingswijzigingen, retentiebeleid, bewaarplicht en incidentele storingen aan beide zijden.⁴ Vermenigvuldig dat met elk bronsysteem met uw AI-workloads en u hebt uw architectuur niet vereenvoudigd. U hebt slechts onderhuids een nieuwe, leveranciersspecifieke kopieerlaag toegevoegd.¹

De externe krachten maken de belasting permanent

De reden dat deze belasting niet na verloop van tijd verdwijnt, is dat de krachten die haar veroorzaken niet van voorbijgaande aard zijn. Het zijn structurele kenmerken van de onderneming:

• • Wettelijke en soevereine beperkingen. AVG, HIPAA, wetgeving inzake datalocatie, exportcontroles. Sommige data moeten worden verwerkt waar ze zich bevinden. De synchronisatietaak die een soevereine grens overschrijdt, is de synchronisatietaak die een nalevingsincident wordt.
  • Applicatievereisten. Applicaties die een bron van waarheid vormen, zoals ERP’s, CRM’s, EHR’s en transactiesystemen, zijn gekoppeld aan hun eigenaren. Ze zijn niet ontworpen om te fungeren als voeding voor de namespace van een leverancier. Ze zijn ontworpen om een onderneming te runnen.
  • Contractuele wrijving. Door de kosten van uitvoer uit hyperscaler en bedrijfseigen indelingen wordt het duurder om duurder te extraheren dan ze op hun plaats te laten. Data ophalen om deze te laten fungeren als invoer elders is een kostenpost waarover uw CFO uiteindelijk zal vallen.
  • Organisatorische dynamiek. Twee bedrijfseenheden die dezelfde data opeisen, de omgeving van een overgenomen bedrijf dat van de ene op de andere dag moet worden opgenomen, een rentmeester die de governance niet wil vrijgeven – het organigram overschrijft routinematig het architecturale ideaal.
  • Onbekende of niet-gecatalogiseerde data. De data die u kent, bestaan maar kunnen niet worden gecatalogiseerd. U kunt niet synchroniseren wat u niet kunt vinden. En wat u niet kunt synchroniseren, kan uw AI ook niet zien, althans niet in een in storage ingebeld model.

Elk van deze factoren is een permanent kenmerk van de omgeving waarin een echte onderneming actief is. Architecturen die ervan afhankelijk zijn dat ze verdwijnen, blijven betalen voor de belasting hiervan.

Het federatieve alternatief

Het Dell AI Data Platform is gebouwd op een heel andere premise. In plaats van klanten te vragen om data naar een door de verkoper gecontroleerde namespace te kopiëren voordat ze deze kunnen gebruiken, is de aanpak van Dell gefedereerd: een besturingsvlak dat data gebruikt waar ze zich bevinden in PowerScale, ObjectScale, storage van derden, warehouses, SaaS en de publieke cloud, en data alleen verplaatst als dit daadwerkelijk de juiste oplossing is.^4,5

Die enkele ontwerpbeslissing is een directe toepassing van het frame met drie vormen:

• • De data blijven waar ze zich bevinden, beheerd door de teams die ze al beheren.
  • De metadata worden overal verspreid, dus elke AI die u kiest, ziet elke asset, ongeacht de locatie.
  • De vectoren dragen betekenis over de hele omgeving, waardoor AI data kan gebruiken zonder deze eerst te verplaatsen.

Het is niet zo dat federatieve architecturen nooit data verplaatsen. Dat doen ze, wanneer het zinvol is. Maar dataverplaatsing is geen voorwaarde om waarde uit het platform te halen. En die ene architecturale keuze elimineert het grootste deel van de operationele belasting hierboven – omdat de belasting alleen bestaat als u uw architectuur hebt gebouwd rond de aanname dat data moeten worden verplaatst voordat AI ermee aan de slag kan.⁴

Het behoudt ook datgene waar de CFO het meest om geeft: keuzemogelijkheden. Een federatief besturingsvlak sluit het datadomein niet op in de namespace van een leverancier. Het laat het domein daar waar het al is, bestuurd door de teams die het al besturen en maakt het bruikbaar voor AI.^2,4

Onafhankelijke analisten wijzen steeds vaker op deze dynamiek. In een recent artikel werd opgemerkt dat ondanks de steun van VAST voor open standaarden, zijn ‘uniforme architectuur afhankelijkheden kan creëren die toekomstige migraties lastig maken’; een beleefde manier om te zeggen dat hoe meer data u synchroniseert, hoe moeilijker het is om deze ooit te verlaten.² In een ander artikel werd opgemerkt dat de aanpak van VAST ‘meer analoog is aan het hypergeconvergeerde infrastructuurmodel, waarbij een strak geïntegreerde, eigen stack wordt geleverd waarbij VAST de volledige ervaring controleert.’³ HCI heeft de industrie geleerd wat er gebeurt als dat model in contact komt met heterogeniteit op schaal. Dezelfde lessen zijn hier van toepassing.

U moet zichzelf drie vragen stellen voordat u tekent

Deze gaan rechtstreeks naar uw RFP.

1. 1. Hoeveel pipelines zal ik uitvoeren bij de stabiele status in uw namespace? Vraag om een realistische schatting op basis van een datadomein dat er uitziet als dat van u, niet een referentiearchitectuur die is gebouwd rond een greenfield. Breng dat in kaart met uw regelgevings- en applicatiegekoppelde omgeving.
   2. Wie is de eigenaar van de afstemming wanneer een bronsysteem verandert? Als het antwoord ‘uw team, met onze tools’ is, zijn dat uw operationele kosten. Ken er een waarde aan toe.
   3. Als ik in jaar drie wil stoppen met het synchroniseren van een bron, hoe gaat dat dan in zijn werk? Het antwoord is een directe maatstaf voor de mate van keuzemogelijkheden die u opgeeft, en een directe maatstaf voor de frictie die de architectuur creëert bij het verlaten van het systeem.

De kortere versie: betaal niet voor sanitair waarvan u niet wist dat u het kocht.

De nabije toekomst

In het volgende bericht ga ik terug naar de datacentervloer, omdat het gevolg van deze architectuurbelasting niet alleen een FTE-probleem is. Het is een probleem van GPU-economie. Wanneer data aanwezig moeten zijn voordat de rekencapaciteit kan worden uitgevoerd, is de duurste post in uw AI-infrastructuur de post waar de rekening wordt betaald.

¹ Productdocumentatie voor VAST Data, “DataSpace and SyncEngine”.

² DataPro.news, “VAST Data: Revolutionair AI OS or Silicon Valley hyperbole?” Juni 2025.

³ NAND Research, “How to Think about VAST Data”, februari 2026.

⁴ Prowess Consulting, “Architectural and Operational Comparison: Dell AI Data Platform vs. VAST AI OS”, in opdracht van Dell, april 2026.

⁵ Dell Technologies, “Dell AI Data Platform with NVIDIA Supercharges Enterprise AI with Breakthrough Data Orchestration and Storage Innovations”, PR Newswire, maart 2026.