Når arkitektur kjemper mot tyngdekraften, er det driften som betaler prisen

• • • • • Lagringsinnebygde stabler forutsetter at data kommer til navneområdet. Kreftene som påvirker virksomhetsområdet, sier at det ikke vil det.
        • «Enhetlig navneområdet»-banen er en sjanse å ta mot de tre dataformene.
        • Den arkitektoniske kostnaden er strukturell: Pipeline-eierskap, avstemmingsgjeld, skjemakobling, styring av dobbel bokføring, manglende kostnadstransparens.
        • Ekstern påvirkning (regulering, applikasjonssammenkobling, kontrakter, eierskap) gjør kostnaden permanent, ikke midlertidig.
        • En samlet kontrollplan opererer på data der den er – og flyttes bare når flytting er det riktige svaret.

Hvis du vurderer KI-dataplattformer, er ikke linjeelementene på tilbudet de eneste kostnadene dine. Den virkelige regningen kommer senere, i pipelinjene du må bygge, personene du må tilordne for å holde dem i live, og valgfriheten du gir opp hver gang dataene må flyttes for å være brukbare.

Data har tyngdekraft, det reelle eiendomsområdet er fullt av forvrengninger som holder data på plass, og selve «dataene» er ikke én substans, de finnes i tre former (data, metadata og vektorer), og hver av dem har ulike egenskaper og krav. Dette innlegget handler om hva som skjer når en arkitektur later som om disse lovene ikke gjelder.

Den arkitektoniske forutsetningen under hver lagringsinnebygd stabel

Lagringsinnebygde KI-stabler, med VAST KI-operativsystemer er det mest synlige eksempelet, og de er bygget på en enkelt arkitektonisk forutsetning: KI-tjenestene kjører på data som allerede har landet på plattformen. De må være på plattformen. Alt utenfor navneområdet er, sett fra plattformens synspunkt, usynlig.^1,4

Plattformen leveres med verktøy for å hente inn data. Den leveres med en historie om hvordan sentralisering av data forenkler driften. Den leveres med et enhetlig brukergrensesnitt som i demonstrasjonen får hele eiendommen til å se ut som en ren ting.

Den historien stemmer når det gjelder det interne. Det er også et sjansespill mot de strukturelle kreftene som virker på reelle virksomhetsområder.

De tre skjemaene sier at du ikke trenger å flytte tunge data

Det virksomheter kaller «data», er egentlig tre forskjellige ting:

• • Data — Tunge. Forblir der de er. Filer, poster, bilder, video, telemetri, regulerte tabeller.
  • Metadata –Lette. Billig å spre. Gjør det mulig for alle KI-er å se alle ressurser, uansett hvor de er.
  • Vektorer –Lokalitetsfølsomme. Har betydning for hele området uten å ha betydning for selve dataene.

Arkitekturer som behandler alle tre som samme substans, gir ett dårlig svar: Flytt alt. Arkitekturer som behandler dem som forskjellige, kan la de tunge dataene styres der de er, spre metadata på tvers av området og la vektorer gjøre det KI faktisk trenger.

Et enhetlig navneområde er et korrekt svar hvis den eneste formen du gjenkjenner, er data. Det er feil svar i det øyeblikket du aksepterer at metadata og vektorer eksisterer som viktige faktorer.

Den arkitektoniske kostnaden med å trekke området innover

Når en arkitektur er bygget på antakelsen om at data må være tilgjengelig før KI kan behandle den, blir alle eksterne faktorer i virksomheten en driftsforpliktelse:

• • Eierskap til pipeline. Hver enkelt kilde, inkludert Snowflake, SharePoint, S3, Kafka, tredjepartslagring, SaaS, trenger en synkroniseringsjobb.¹ Bak hver synkroniseringsjobb sitter et menneske.
  • Avstemmingsgjeld. Hver kopi drives fra sin egen kilde. Skjemadrift, lengre regionale ventetider, stille avkortning når en kildefeltlengde endres og ingen ble informert om det. Noen må oppdage og korrigere den driften hver gang.
  • Skjemakobling. Når kildesystemene endres, brytes nedstrømskopier – og KI-tjenestene som er avhengige av dem, brytes også.
  • Styring av dobbeltbokføring. Tilgangskontroller, retningslinjer for oppbevaring, lovbestemte sperrer og revisjonsspor må vedlikeholdes to ganger både i kilden og i kopien.
  • Manglende kostnadstransparens. FinOps-teamet overvåker nå dataflyt, lagringsduplisering og utgående trafikk på tvers av en arkitektur som opprinnelig ble markedsført som en konsolideringsløsning.

Ingenting av dette er skjult i ond tro. Det er strukturelt. Det er det som skjer når en lukket, lagringsinnebygd modell møter et åpent, distribuert dataområde og prøver å trekke området innover.^1,4

Her er leverandørspråket viktig. «Synkroniseringsmotoren er gratis» og «synkronisering er gratis» er ikke den samme setningen. En synkroniseringsjobb er ikke en engangsmigrering. Det er et permanent forhold mellom to systemer som må holdes konsekvent for alltid: Mot endringer i skjemaet, nettverkshendelser, endringer i tillatelser, retningslinjer for oppbevaring, lovbestemte sperringer og sporadiske avbrudd på begge sider.⁴ Hvis du multipliser det med hvert enkelt kildesystem KI-workloadene gjelder, så blir resultatet at du ikke forenklet arkitekturen. Du har lagt til et nytt, leverandørspesifikt kopiplan som kjører under det.¹

De eksterne kreftene gjør denne kostnaden permanent

Årsaken til at denne kostnaden ikke forsvinner over tid, er at kreftene som skaper den, ikke er overgangsrelaterte. De er strukturelle egenskaper i virksomheten:

• • Lovbestemte og suverene begrensninger. GDPR, HIPAA, datalagringslov, eksportkontroller. Noen data må behandles der de er. Synkroniseringsjobben som krysser en suveren grense, er synkroniseringsjobben som blir en samsvarshendelse.
  • Applikasjonskrav. Kildeapplikasjoner som ERP-er, CRM-er, EHR-er og transaksjonssystemer er koblet til eierne sine. Det var ikke ment at de skulle gi tilgang til et leverandørnavneområde. De ble designet for å drive en virksomhet.
  • Kontraktsmessig friksjon. Utgående hyperskaleringsavgifter og proprietære formater gjør det dyrere og hente ut data enn å la dem bli værende der de er. Å hente ut data for å plassere dem et annet sted, er en kostnadslinje som CFO-en til slutt må finne.
  • Organisasjonsdynamikk. To forretningsenheter som gjør hevd på de samme dataene, en overført virksomhets eiendom som forsvant over natten, en administrator som ikke vil frigjøre styringsdata — organisasjonskartet overstyrer rutinemessig det som er ideelt for arkitekturen.
  • Ukjente eller ikke-katalogiserte data. Data du vet finnes, men som ikke kan katalogiseres. Du kan ikke synkronisere det du ikke kan finne. Og det du ikke kan synkronisere, kan ikke KI se, i hvert fall ikke i en lagringsinnebygd modell.

Hver enkelt av disse elementene er en permanent egenskap i det miljøet en ekte virksomhet opererer i. Arkitekturer som er avhengig av at de fjernes, betaler kostnaden for dette på ubestemt tid.

Det forente alternativet

Dells KI-dataplattform er bygget på helt andre premisser. I stedet for å be kundene om å kopiere data til et leverandørkontrollert navneområde før de kan bruke dem, har Dell en forent tilnærming: Et kontrollplan som opererer på data der den befinner seg på tvers avPowerScale, ObjectScale, tredjepartslagring, lagre, SaaS og offentlig nettsky, og flytter bare data når det faktisk er det riktige.^4,5

Denne enkeltdesignbeslutningen er en direkte anvendelse av rammeverket med tre former:

• • Dataene forblir der de er, og styres av teamene som allerede styrer dem.
  • Metadataene sprer seg overalt, slik at all KI du velger, kan se alle ressurser uavhengig av hvor de befinner seg.
  • Vektorene har betydning på tvers av området, slik at KI kan resonnere på disse dataene uten å flytte dem først.

Men det er ikke slik at forent arkitektur aldri flytter data. De flytter data når det gir mening. Men de gjør ikke databevegelser til en forutsetning for å få verdi fra plattformen. Og det enkle arkitektoniske valget eliminerer det meste av driftskostnadene ovenfor – fordi kostnadene bare er der hvis du har bygget arkitekturen rundt antagelsen om at data må flyttes før KI kan behandle dem.⁴

Det opprettholder også det CFO er mest opptatt av: Valgfrihet. Et samlet kontrollplan fanger ikke dataområdet i leverandørens navneområde. Den lar området være der det allerede er, styrt av teamene som allerede styrer den, og gjør det nyttig for den KI-en som er på plass.^2,4

Uavhengige analytikere fremhever stadig denne dynamikken. En nylig artikkel påpekte at til tross for at VAST støtter åpne standarder, kan den «enhetlige arkitekturen skape avhengigheter som gjør fremtidige migreringer utfordrende», en fin måte å si at jo mer data du synkroniserer inn, desto vanskeligere er det flytte den.² En annen artikkel observerte at tilnærmingen til VAST er «mer analog med den hyperkonvergerende infrastrukturmodellen, og leverer en tett integrert og lite tilpassbar stabel der VAST kontrollerer hele opplevelsen.»³ HCI lærte bransjen hva som skjer når den modellen møter heterogene miljøer i stor skala. De samme lærdommene gjelder her.

Tre spørsmål du må stille før du signerer

Disse går rett inn i RFP.

1. 1. 1. Hvor mange pipelines kommer jeg til å kjøre inn i navneområdet i stabil tilstand? Be om et realistisk estimat basert på et dataområde som ser ut som ditt, ikke en referansearkitektur bygget rundt et greenfield. Kartlegg det mot det forskriftsmessige og applikasjonstilkoblede området ditt.
      2. Hvem eier avstemming når et kildesystem endres? Hvis svaret er «teamet ditt, ved hjelp av verktøyene våre», er det driftskostnadene dine. Prissett det.
      3. Hvis jeg ønsker å stoppe synkroniseringen av en kilde i år tre, hvordan vil det se ut? Svaret er en direkte måling av hvor mye valgfrihet du gir fra deg, og en direkte måling av hvor mye friksjon arkitekturen skaper rundt utgangen.

Den kortere versjonen: Ikke betal for arbeid ingen har fortalt deg at du har kjøpt.

Dette skjer videre

I neste innlegg går jeg tilbake til datasentergulvet, fordi konsekvensene av denne arkitektoniske kostnaden ikke bare er et FTE-problem. Det er et problem relatert til GPU-økonomi. Når data må lande før databehandlingen kan kjøres, er det dyreste linjeelementet i KI-infrastrukturen det som betaler regningen.

¹ VAST Data, produktdokumentasjon for DataSpace og SyncEngine.

² DataPro.News, «VAST data: Revolusjonerende OS for AI eller Silicon Valley Hyperbole?» Juni 2025.

³ NAND Research, “Hva du skal tenke om VAST-data”, februar 2026.

⁴ Prowess Consulting, «Architectural and Operational Comparison: Dell KI sammenlignet med VAST AI OS», bestilt av Dell, april 2026.

⁵ Dell Technologies, «Dell AI Data Platform with NVIDIA Supercharges Enterprise AI with Breakthrough Data Orchestration and Storage Innovations,» PR Newswire, mars 2026.