När arkitekturen kämpar mot gravitationen är det driften som får betala

• • • • • Lagringsinbäddade stackar förutsätter att data kommer till namnrymden. De krafter som agerar på företagets egendom säger något annat.
        • Argumentet för en ”enhetligt namnrymd” är en satsning mot de tre formerna av data.
        • Arkitekturskatten är strukturell: ägande av pipelinen, eftersläpande avstämning, schemakoppling, dubbelarbete i styrningen och bristande insyn i kostnader.
        • Externa krafter (regelverk, appkopplingar, avtal, ägande) gör skatten permanent snarare än tillfällig.
        • Ett förenat kontrollplan arbetar med data där de finns – och flyttar dem bara när det är nödvändigt.

Om du utvärderar AI-dataplattformar är radartiklarna i offerten inte dina enda kostnader. Den verkliga kostnaden visar sig senare – i de pipelines du måste skapa, de personer du tilldelar för att hålla dem vid liv och den valfrihet du ger upp varje gång data måste flyttas bara för att vara användbara.

Data har tyngd, den verkliga företagsegendomen är full av störningar som håller data kvar på plats och ”data” i sig är inte en enda substans – utan består av tre former (data, metadata och vektorer), som var och en har olika egenskaper och krav. Det här inlägget handlar om vad som händer när en arkitektur påstår att de här lagarna inte gäller.

Det arkitektoniska antagandet som ligger till grund för varje lagringsinbäddad stack

Lagringsinbäddade AI-stackar, där VAST AI OS är det tydligaste exemplet, bygger på ett enskilt arkitektoniskt antagande: att AI-tjänsterna körs på data som redan har landat på plattformen. De måste finnas på plattformen. Allt utanför namnrymden är osynligt ur plattformens perspektiv.^1,4

Därför levereras plattformen med verktyg för att samla in data. Den levereras med en berättelse om hur driften blir enklare när du centraliserar dina data. Den levereras med ett enhetligt användargränssnitt som i demon får hela egendomen att se enhetlig och prydlig ut.

Den här berättelsen är sammanhängande. Den går även emot de strukturella krafter som verkar mot företagets faktiska egendom.

De tre formerna innebär att du inte behöver flytta tunga data.

Det företag kallar ”data” är egentligen tre olika saker:

• • Data – tunga. Stannar kvar på plats. Filer, poster, bilder, video, telemetri, reglerade tabeller.
  • Metadata – lätta. Billiga att sprida. Varje AI kan se alla tillgångar, var som helst.
  • Vektorer – platskänsliga. Överför mening i hela egendomen utan att föra med de data det gäller.

Arkitekturer som behandlar alla tre formerna som samma substans landar ofta i ett dåligt svar: flytta allt. Arkitekturer som behandlar dem som distinkta kan låta tunga data styras där de finns, sprida metadata i hela egendomen och låta vektorerna sköta det miljöoberoende resonemang som AI:n faktiskt behöver.

En enhetlig namnrymd är en rimlig slutsats om den enda formen du beaktar är just data. Slutsatsen blir dock sämre så fort du accepterar metadata och vektorer som likvärdiga medborgare.

Den arkitektoniska skatten när du centrerar hela egendomen

När en arkitektur bygger på antagandet att data måste anlända innan de kan hanteras av AI:n blir varje extern kraft i företaget ett operativt åtagande:

• • Ägandet av pipelinen. Alla källor, som Snowflake, SharePoint, S3 och Kafka, extern lagring eller SaaS, behöver ett synkroniseringsjobb.¹ Bakom varje synkroniseringsjobb finns en människa.
  • Eftersläpande avstämning. Varje kopia avviker med tiden från sin källa. Schemaavdrift, regionala latenstoppar, tysta trunkeringar när längden på ett källfält ändras utan att någon har sagt något. Någon måste hela tiden upptäcka och korrigera den här avdriften.
  • Schemakoppling. När källsystemen ändras slutar kopior nedströms att fungera – och det sker även med AI-tjänsterna som är beroende av dem.
  • Dubbelarbete i styrningen. Åtkomstkontroller, kvarhållningspolicyer, lagstadgad kvarhållning och revisionsspår måste bibehållas dubbelt – både för källan och kopian.
  • Bristande insyn i kostnader. FinOps-teamet spårar nu dataförflyttningar, lagringsdubbletter och utmatningar i en arkitektur som såldes in som konsolidering.

Inget av det här döljs med onda avsikter. Problemet är strukturellt. Det är helt enkelt resultatet när en sluten, lagringsinbäddad modell möter en öppen, distribuerad dataegendom och försöker centralisera egendomen.^1,4

Här är det viktigt hur leverantören kommunicerar. ”Synkroniseringsmotorn är gratis” och ”synkroniseringen är gratis” betyder inte samma sak. Ett synkroniseringsjobb är inte en engångsmigrering. Det är en permanent relation mellan två system som hela tiden måste hållas konsekvent: mot schemaändringar, nätverkshändelser, behörighetsändringar, kvarhållningspolicyer, kvarhållning enligt regelverk och tillfälliga avbrott på endera sidan.⁴ Multiplicera det här med varje källsystem dina AI-arbetsbelastningar hanterar så har du knappast förenklat din arkitektur. Du har lagt till ett nytt, leverantörsspecifikt kopieringsplan som körs under den.¹

De yttre krafterna gör den här skatten permanent

Anledningen till att den här skatten inte klingar av över tid är att de krafter som skapar den inte är tillfälliga. De är strukturella egenskaper i verksamheten:

• • Lagstadgade och nationella begränsningar. GDPR, HIPAA, datalagstiftning, exportkontroller. Vissa data måste bearbetas där de finns. Ett synkroniseringsjobb som korsar landsgränser blir direkt till en efterlevnadsincident.
  • Krav på apparna. Appar som agerar sanningskälla, till exempel ERP-, CRM-, EHR- och transaktionssystem, är kopplade till sina ägare. De är inte avsedda att mata en leverantörs namnrymd. Syftet är att driva verksamheten.
  • Problematiska avtal. Avgifter för utmatning från hyperskalare och proprietära format gör det dyrare att extrahera data än att lämna dem på plats. Att mata ut data för att lagra dem någon annanstans är en kostnadspost som din ekonomichef så småningom upptäcker.
  • Organisationens dynamik. Två affärsenheter gör anspråk på samma data, ett förvärvat företags egendom måste plötsligt introduceras, en förvaltare släpper inte taget om styrningen – organisationsschemat har ofta företräde framför det arkitektoniska idealet.
  • Okända eller ej katalogiserade data. De data du vet finns men inte kan katalogisera. Du kan inte synkronisera det du inte hittar. Och det du inte kan synkronisera kan din AI inte se, åtminstone inte i en modell där lagringen är inbäddad.

Var och en av de här krafterna är permanenta i den miljö där riktiga företag verkar. Arkitekturer som är beroende av att de försvinner måste betala den här skatten på obestämd tid.

Det federerade alternativet

Dells AI-dataplattform bygger på helt andra premisser. Istället för att be kunderna kopiera data till en leverantörsstyrd namnrymd innan de kan användas är Dells metod federerad: ett kontrollplan som verkar på data där de finns i PowerScale, ObjectScale, extern lagring, datalager, SaaS och det offentliga molnet, och som bara flyttar data när det faktiskt är nödvändigt.^4,5

Det enda designbeslutet är en direkt tillämpning av konceptet med de tre formerna:

• • Data stannar där de finns och styrs av samma team som innan.
  • Metadata sprids överallt, så att varje AI du väljer kan se alla tillgångar oavsett plats.
  • Vektorerna överför mening inom hela egendomen, så att AI:n kan resonera kring data utan att först flytta dem.

Det stämmer inte att data aldrig flyttas i en federerad arkitektur. Det gör de när det behövs. Dataflyttar är dock inte en förutsättning för att du ska få ut värde av plattformen. Och det enda arkitekturvalet gör att du slipper det mesta av driftsskatten ovan – eftersom den endast uppstår om du har byggt arkitekturen kring antagandet att data måste flyttas innan AI:n kan hantera dem.⁴

Dessutom bevarar du det CFO:n bryr sig mest om: valfrihet. Ett federerat kontrollplan låser inte fast dataegendomen i en enda leverantörs namnrymd. Egendomen lämnas på plats, den styrs av samma team som förut och AI:n kan använda den direkt.^2,4

Oberoende analytiker tar upp den här dynamiken allt oftare. I en nyligen publicerad artikel stod att ”trots VAST:s stöd för öppna standarder kan den enhetliga arkitekturen skapa beroenden som gör framtida migreringar till en utmaning” – ett snällt sätt att säga att ju mer data du synkroniserar in desto svårare blir det att lämna miljön.² En annan analytiker observerade att VAST-metoden ”passar bättre för den hyperkonvergerade infrastrukturmodellen och ger en tätt integrerad, stängd stack där VAST styr hela upplevelsen”.³ HCI lärde branschen vad som händer när den här modellen möter en storskalig heterogenitet. Samma lärdomar gäller även här.

Tre frågor att ställa innan du skriver på

De bör absolut ingå i din RFP.

1. 1. 1. 1. 1. Hur många pipelines kör jag i normala fall in till er namnrymd? Be om en realistisk uppskattning baserad på en dataegendom som din, inte en referensarkitektur byggd kring en ideal miljö. Jämför med regelverken och appkopplingarna i din egendom.
            2.  
            3. Vem äger avstämningen när ett källsystem ändras? Om svaret är ”ditt team med våra verktyg” är det du som står för driftskostnaden. Sätt ett pris.
            4. Hur gör jag om jag vill sluta synkronisera en källa om tre år? Svaret är ett direkt mått på hur mycket valfrihet du ger upp, och på hur mycket friktion arkitekturen skapar om du vill avsluta.

      Den korta versionen: betala inte för det maskineri ingen berättar att du håller på att köpa.

Nästa steg

I nästa inlägg går jag tillbaka till datacentergolvet, eftersom konsekvensen av den här arkitekturskatten inte bara är ett problem som gäller FTE.Den ställer till det för GPU-ekonomin.När data måste anlända innan du kan köra beräkningar är den dyraste radposten i din AI-infrastruktur den som betalar fakturan.

¹ VAST Data, produktdokumentation för ”DataSpace and SyncEngine”.

² DataPro.news, ”VAST Data: Revolutionary 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”, beställd av Dell i april 2026.

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