Når arkitektur bekæmper tyngdekraften, betaler driften udgifterne

• • Storage-integrerede stakke forudsætter, at data kommer til navneområdet. De kræfter, der påvirker en virksomhedsejendom, siger, at de ikke gør.
  • Udtrykket “samlet navneområde” er et opgør med de tre former for data.
  • Den arkitektoniske udgift er strukturel: Ejerskab af pipelinen, afsoningsgæld, skemakobling, styring af dobbelt bogføring, omkostningsuklarhed.
  • Eksterne faktorer (lovgivning, programkobling, kontrakter, ejerskab) gør udgiften permanent, ikke midlertidig.
  • Et samlet kontrolplan fungerer ud fra data, hvor de findes – og flytter dem kun, når det at flytte dem, er det rigtige svar.

Hvis du evaluerer AI-dataplatforme, er linjeelementerne på tilbuddet ikke dine eneste omkostninger. Den reelle regning dukker op senere – i de pipelines, du skal opbygge, de personer, du tilknytter for at holde dem i live, og de muligheder, du opgiver, hver gang data skal flyttes blot for at kunne bruges.

Data har tyngde, den faste virksomhedsejendom er fuld af forvrængninger, der holder data på plads, og “data” i sig selv er ikke ét stof – de har tre former (data, metadata og vektorer), hver med forskellige egenskaber og krav. Dette indlæg handler om, hvad der sker, når en arkitektur foregiver, at disse love ikke gælder.

Den arkitektoniske antagelse under hver storage-integrerede stak

Storage-integrerede AI-stakke, hvor VAST AI-operativsystemer er det mest synlige eksempel, er bygget op omkring en enkelt arkitektonisk antagelse: AI-services kører på data, der allerede er landet i platformen. De skal være i platformen. Alt uden for navneområdet er, ud fra platformens synspunkt, usynligt.^1,4

Platformen leveres således med værktøjer til at bringe data ind. Den leveres med en historie om, hvordan centralisering af data forenkler driften. Den leveres med en samlet brugergrænseflade, der i demoen får hele ejendommen til at se ud som én ren ting.

Den historie er sammenhængende internt. Det er også et opgør med de strukturelle kræfter, der indvirker på fast virksomhedsejendomme.

De tre former betyder, at du ikke behøver at flytte de tunge data

Det, som virksomheder kalder “data”, er i virkeligheden tre forskellige ting:

• • Data – Tunge. Forbliver, hvor de er. Filer, optegnelser, billeder, video, telemetri, regulerede tabeller.
  • Metadata – Lette. Billige at udbrede. Lader enhver AI se alle aktiver, hvor som helst.
  • Vektorer –Lokalitetsfølsomme. Medbring mening overalt i ejendommen uden at medbringe selve dataene.

Arkitekturer, der behandler alle tre som det samme stof, medfører ét dårligt svar: Flyt alt. Arkitekturer, der behandler dem som særskilte, kan lade de tunge data blive, hvor de er, sprede metadata overalt i ejendommen og lade vektorer udføre de ræsonnementer i hele miljøet, som AI rent faktisk har brug for.

Et samlet navneområde er et sammenhængende svar, hvis den eneste form, du genkender, er data. Det er det forkerte svar i det øjeblik, du accepterer, at metadata og vektorer er førsteklasses borgere.

Den arkitektoniske udgift, der trækker ejendommen indad

Når en arkitektur er bygget op omkring den antagelse, at data skal ankomme, før AI kan røre ved dem, bliver alle eksterne kræfter i virksomheden en driftsmæssig forpligtelse:

• • Ejerskab af pipelinen. Alle kilder, herunder Snowflake, SharePoint, S3, Kafka, Tredjepartsstorage, SaaS kræver et synkroniseringsjob.¹ Der er et menneske bag hvert synkroniseringsjob.
  • Gældssanering. Hver kopi driver væk fra kilden. Skemaafdrift, regionale forsinkelser, lydløse afkortninger, når kildefelts længde ændres, og ingen informerede nogen. Nogen er nødt til at holde øje med og korrigere denne afdrift, for altid.
  • Skemakobling. Når kildesystemer ændres, ødelægges skriftlige eller digitale kopier – og AI-services, der afhænger af dem, ødelægges også.
  • Styring af dobbelt bogføring. Adgangskontroller, opbevaringspolitikker, lovgivningsmæssige tilbageholdelser og revisionsspor skal vedligeholdes dobbelt – i kilden og i kopien.
  • Omkostningsgennemsigtighed. Dit FinOps-team sporer nu dataflytning, storage-duplikering og udtrædelse fra en arkitektur, der blev solgt som konsolidering.

Intet af dette er skjult i ond tro. Det er strukturelt. Det er det, der sker, når en lukket, storage-integreret model møder en åben, distribueret dataejendom og forsøger at trække ejendommen indad.^1,4

Leverandørsproget betyder noget her. “Synkroniseringsmaskinen er gratis” og “Synkronisering er gratis” er ikke den samme sætning. Et synkroniseringsjob er ikke en engangsmigrering. Det er et permanent forhold mellem to systemer, der skal holdes sammenhængende for altid: I forhold til skemaændringer, netværkshændelser, tilladelsesændringer, opbevaringspolitikker, lovgivningsmæssige tilbageholdelser og lejlighedsvise afbrydelser på begge sider.⁴ Gang det med hvert kildesystem, dine AI-workloads kommer i kontakt med, og du har ikke forenklet din arkitektur. Du har tilføjet et nyt, leverandørspecifikt kopieringsplan, der kører nedenunder.¹

De eksterne kræfter gør udgiften permanent

Grunden til, at denne udgift ikke aftager med tiden, er, at de kræfter, der har skabt den, ikke er midlertidige. De er virksomhedens strukturelle funktioner:

• • • Lovgivningsmæssige og suveræne begrænsninger. GDPR, HIPAA, lovgivning om dataopbevaring, eksportkontrol. Nogle data skal behandles der hvor de er. Det synkroniseringsjob, der krydser en suveræn grænse, er det synkroniseringsjob, der bliver en compliance-hændelse.
    • Programkrav. Centraliserede programmer, såsom ERP’er, CRM’er, EHR’er og transaktionssystemer, er koblet til deres ejere. De er ikke designet til at forsyne et leverandørnavneområde. De er designet til at drive en forretning.
    • Kontraktmæssige gnidninger. Hyperscaler-udtrædelsesgebyrer og egenudviklede formater gør data dyrere at trække ud end at efterlade dem, hvor de er. At trække data ud og efterlade dem et andet sted er en omkostningslinje, som din økonomidirektør i sidste ende finder.
    • Organisationsdynamik. To forretningsenheder, der gør krav på de samme data, en opkøbt virksomheds ejendom er kommet til i løbet af natten, en forvalter, der ikke vil give slip på styringen – organisationsdiagrammet tilsidesætter rutinemæssigt det arkitektoniske ideal.
    • Ukendte eller ikke-katalogiserede data. De data, du ved findes, men ikke kan katalogiseres. Du kan ikke synkronisere det, du ikke kan finde. Og hvad du ikke kan synkronisere, kan din AI ikke se, i det mindste ikke i en storage-integreret model.

Hver eneste af disse kræfter er en permanent egenskab i det miljø, en reel virksomhed opererer i. Arkitekturer, der er afhængige af, at de forsvinder, betaler udgiften på ubestemt tid.

Det samlede alternativ

Dells AI Data Platform er bygget op omkring en helt anden præmis. I stedet for at bede kunderne om at kopiere data til et leverandørstyret navneområde, før de kan bruge dem, er Dells tilgang samlet: Et kontrolplan, der fungerer ud fra data, hvor de findes på tværs af PowerScale, ObjectScale, tredjepartsstorage, lagre, SaaS og offentlig cloud, og som kun flytter data, når det at flytte dem, rent faktisk er det rigtige svar.^4,5

Den enkelte designbeslutning er en direkte anvendelse af de tre former for rammer:

• • Dataene forbliver der, hvor de er, styret af de teams, der allerede styrer dem.
  • Metadataene udbredes overalt, så hver AI, du vælger, ser hvert aktiv uanset placeringen.
  • Vektorerne medbringer betydning på tværs af ejendommen, så AI kan ræsonnere omkring data uden først at flytte dem.

Det er ikke sådan, at samlede arkitekturer aldrig flytter data. Det gør de, når det giver mening. Men de gør ikke dataflytning til forudsætningen for at opnå værdi fra platformen. Og det ene arkitektoniske valg eliminerer det meste af driftsudgiften ovenfor – fordi udgiften kun findes, hvis du har bygget din arkitektur ud fra den antagelse, at data skal flyttes, før AI kan komme i kontakt med dem.⁴

Det bevarer også det, som CFO’en bekymrer sig mest om: Valgmuligheder. Et samlet kontrolplan opbevarer ikke dataejendommen i en leverandørs navneområde. Det efterlader ejendommen, hvor den allerede er, styret af de teams, der allerede styrer den, og gør den nyttig for AI på stedet.^2,4

Uafhængige analytikere peger i stigende grad på denne dynamik. En nylig artikel nævnte, at trods VAST’s understøttelse af åbne standarder, kan dens “samlede arkitektur skabe afhængigheder, der gør fremtidige migreringer udfordrende” – en høflig måde at sige, at jo flere data du synkroniserer, jo sværere er de nogensinde at efterlade.² En anden observerede, at VAST’s tilgang er “mere analog med den hyperkonvergerede infrastrukturmodel, der leverer en tæt integreret, meningsfuld stak, hvor VAST styrer den fulde oplevelse.”³ HCI lærte branchen, hvad der sker, når denne model møder heterogenitet i stor skala. De samme lektioner gælder her.

Tre spørgsmål, du bør stille, før du underskriver

De går direkte ind i din RFP.

1. 1. Hvor mange pipelines vil jeg køre ind i dit navneområde ved stabil tilstand? Bed om et realistisk skøn baseret på en dataejendom, der ligner din, ikke en referencearkitektur, der er bygget op omkring en projektudviklingstilgang. Sammenlign det i forhold til din lovgivnings- og programkoblede ejendom.
   2. Hvem ejer sanering, når et kildesystem ændres? Hvis svaret er “dit team, ved hjælp af vores værktøjer”, er det dine driftsomkostninger. Prissæt det.
   3. 1. Hvis jeg vil stoppe med at synkronisere en kilde i år tre, hvordan ser det så ud? Svaret er et direkte mål for, hvor meget valgfrihed du giver slip på, og en direkte udlæsning af, hvor mange gnidninger arkitekturen skaber omkring afslutningen.

Den kortere version: Betal ikke for VVS, som ingen fortalte dig, at du købte.

Hvad er næste skridt?

I det næste indlæg vender jeg tilbage til datacentergulvet, fordi konsekvensen af denne arkitektoniske udgift ikke blot er et FTE-problem. Det er et problem med GPU-økonomien. Når data skal lande, før beregningen kan køre, er det dyreste linjeelement i din AI-infrastruktur det, der betaler regningen.

 ¹ VAST-data, “DataSpace and SyncEngine”-produktdokumentation.

 ² DataPro.news: “VAST-data: Revolutionerende AI-operativsystem eller Silicon Valley Hyperbole?” Juni 2025.

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

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

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