Wenn die Architektur gegen die Schwerkraft ankämpft, muss der Betrieb die Zeche zahlen

• • Bei in Storage integrierten Stacks wird davon ausgegangen, dass Daten in den Namespace übermittelt werden. Die Faktoren, die auf den Datenbestand eines Unternehmens einwirken, sorgen jedoch dafür, dass dies nicht der Fall ist.
  • Das Versprechen eines „einheitlichen Namespace“ ist eine Wette gegen die drei Formen von Daten.
  • Der Architekturaufwand ist struktureller Natur: Zuständigkeit für Pipelines, Abstimmungsrückstand, Schemakopplung, doppelte Governance-Verwaltung, undurchsichtige Kosten.
  • Externe Faktoren (Regulierung, Anwendungskopplung, Verträge, Verantwortlichkeiten) sorgen dafür, dass dieser Aufwand dauerhaft und nicht vorübergehend ist.
  • Eine vereinheitlichte Steuerungsebene arbeitet mit den Daten dort, wo sie sich befinden – und verschiebt sie nur, wenn das Verschieben die richtige Lösung ist.

Wenn Sie KI-Datenplattformen evaluieren, sind die einzelnen Posten im Angebot nicht Ihre einzigen Kosten. Die tatsächlichen Kosten zeigen sich erst später – in den Pipelines, die Sie aufbauen müssen, in den MitarbeiterInnen, die Sie damit beauftragen, diese am Laufen zu halten, und im Verzicht auf Flexibilität, den Sie jedes Mal eingehen, wenn Daten verschoben werden müssen, nur damit sie nutzbar sind.

Daten unterliegen der Schwerkraft, die tatsächliche Unternehmensumgebung ist voller Verzerrungen, die Daten an Ort und Stelle halten, und „Daten“ an sich sind keine einheitliche Substanz – sie nehmen drei Formen (Daten, Metadaten und Vektoren) an, die jeweils unterschiedliche Merkmale und Anforderungen aufweisen. In diesem Beitrag geht es darum, was geschieht, wenn eine Architektur vorgibt, dass diese Gesetze nicht gelten.

Die Architekturprämisse, die jedem in Storage integrierten Stack zugrunde liegt

In Storage integrierte KI-Stacks – von denen VAST AI OS das bekannteste Beispiel ist – basieren auf einer einzigen Architekturprämisse: Die KI-Services werden mit Daten ausgeführt, die bereits auf der Plattform vorhanden sind. Sie müssen sich also auf der Plattform befinden. Alles außerhalb des Namensraums ist, aus der Sicht der Plattform, unsichtbar.^1,4

Die Plattform wird mit Tools zum Aufnehmen von Daten ausgeliefert. Sie wird mit der Aussage bereitgestellt, dass die Zentralisierung von Daten Betriebsabläufe vereinfacht. Sie verfügt über eine einheitliche Benutzeroberfläche, die in der Demo die gesamte Umgebung wie eine einfache Sache aussehen ließ.

Diese Idee ist in sich schlüssig. Es ist auch eine Wette gegen die strukturellen Kräfte, die auf reale Unternehmensstandorte wirken.

Es müssen keine großen Datenmengen verschoben werden, schließlich gibt es drei Formate

Was Unternehmen als „Daten“ bezeichnen, sind drei verschiedene Dinge:

• • Daten – umfangreich. Bleiben dort, wo sie sind. Dateien, Datensätze, Bilder, Videos, Telemetrie, standardisierte Tabellen.
  • Metadaten – leichtgewichtig. Kostengünstig zu verbreiten. Jede KI kann jede Ressource überall sehen.
  • Vektoren – standortabhängig. Übertragen Bedeutung in der gesamten Umgebung, ohne die Daten selbst zu verschieben.

Architekturen, die alle drei Datenformen als ein und dieselbe Einheit behandeln, kommen zwangsläufig zu einer unzulänglichen Lösung: alles verschieben. Architekturen, die diese Formen als unterschiedliche Einheiten betrachten, können die umfangreichen Daten weiter dort kontrollieren, wo sie sich befinden, Metadaten in der gesamten Umgebung verbreiten und Vektoren das umgebungsübergreifende Schlussfolgern überlassen, das die KI tatsächlich benötigt.

Ein einheitlicher Namespace ist eine schlüssige Lösung, solange Sie nur die Form Daten wahrnehmen. Die Lösung passt nicht mehr, sobald Sie realisieren, dass Metadaten und Vektoren als gleichberechtigte Instanzen existieren.

Der Architekturaufwand für einen nach innen gerichteten Datenbestand

Wenn eine Architektur auf der Annahme basiert, dass Daten erst eingehen müssen, bevor die KI darauf zugreifen kann, wird jede externe Einflussgröße in Ihrem Unternehmen zu einer betrieblichen Verpflichtung:

• • Verantwortung für die Pipeline. Jede Quelle – einschließlich Snowflake, SharePoint, S3, Kafka, Storage von Drittanbietern und SaaS – erfordert einen Synchronisierungsjob.¹ Hinter jedem Synchronisierungsjob steht ein Mensch.
  • Abstimmungsrückstand. Jede Kopie weicht von ihrer Quelle ab. Schemaabweichungen, regionale Latenzspitzen, stillschweigende Kürzungen, wenn sich die Länge eines Quellfelds ändert – und niemand wird darüber informiert. Jemand muss diese Abweichungen erkennen und korrigieren – und das auf Dauer.
  • Schemakopplung. Wenn sich Quellsysteme ändern, funktionieren nachgelagerte Kopien nicht mehr – und die davon abhängigen KI-Services ebenfalls nicht.
  • Doppelte Governance-Verwaltung. Zugriffskontrollen, Aufbewahrungsrichtlinien, behördlich vorgeschriebene Aufbewahrungsfristen und Auditpfade müssen doppelt verwaltet werden – in der Quelle und in der Kopie.
  • Undurchsichtige Kosten. Ihr FinOps-Team muss jetzt die Datenverschiebung, die Storage-Duplizierung und ausgehende Daten in einer Architektur verfolgen, die als konsolidierte Lösung verkauft wurde.

Nichts davon wurde in böser Absicht verborgen. Es ist eine strukturelle Frage. Das geschieht, wenn ein geschlossenes, in Storage integriertes Modell auf einen offenen, verteilten Datenbestand trifft und versucht, diesen Bestand in sein System aufzunehmen.^{1, 4}

Die Anbietersprache ist hier wichtig. „Kostenlose Synchronisierungs-Engine“ und „kostenlose Synchronisierung“ sind nicht dasselbe. Ein Synchronisierungsjob ist keine einmalige Migration. Es handelt sich um eine dauerhafte Beziehung zwischen zwei Systemen, die stets konsistent gehalten werden müssen – ungeachtet von Schemaänderungen, Netzwerkereignissen, Berechtigungsänderungen, Aufbewahrungsrichtlinien, behördlichen Aufbewahrungsfristen und gelegentlichen Ausfällen auf einer der beiden Seiten.⁴ Wenn Sie dies mit jedem Quellsystem multiplizieren, mit dem Ihre KI-Workloads in Berührung kommen, haben Sie Ihre Architektur nicht vereinfacht. Sie haben eine neue, herstellerspezifische Kopieebene erzeugt, die darunter läuft.¹

Externe Kräfte verursachen permanente Kosten

Der Grund dafür, dass diese Kosten im Laufe der Zeit nicht auslaufen, ist, dass die Kräfte, die sie verursachen, nicht nur Übergangskräfte sind. Es handelt sich dabei um strukturelle Merkmale des Unternehmens:

• • • Behördliche und hoheitliche Einschränkungen. Die DSGVO, HIPAA, das Datenresidenzgesetz und Exportkontrollen. Einige Daten müssen dort verarbeitet werden, wo sie sich befinden. Ein Synchronisierungsjob, der eine Staatsgrenze überschreitet, wird zu einem Compliance-Incident.
    • Anwendungsanforderungen. „Source-of-Truth“-Anwendungen wie ERPs, CRMs, EHRs und Transaktionssysteme sind an ihre Verantwortlichen gekoppelt. Sie wurden nicht dafür entwickelt, den Namespace eines Anbieters mit Daten zu versorgen. Sie wurden entwickelt, um ein Unternehmen zu führen.
    • Vertragsschwierigkeiten. Die Ausgangsgebühren von Hyperscalern und proprietäre Formate führen dazu, dass das Extrahieren von Daten kostspieliger ist als deren Verbleib am ursprünglichen Speicherort. Das Extrahieren von Daten, um sie an einem anderen Ort zu speichern, ist ein Kostenposten, den Ihr CFO früher oder später entdecken wird.
    • Unternehmensdynamik. Zwei Geschäftsbereiche, die Anspruch auf dieselben Daten erheben, der Datenbestand eines übernommenen Unternehmens, der über Nacht hinzukommt, eine für die Daten verantwortliche Person, die die Governance nicht freigibt – die Organisationsstruktur des Unternehmens hat regelmäßig Vorrang vor der idealen Architektur.
    • Unbekannte oder nicht katalogisierte Daten. Daten, von denen Sie wissen, dass sie existieren, können nicht katalogisiert werden. Sie können nicht synchronisieren, was Sie nicht finden können. Und was Sie nicht synchronisieren können, kann Ihre KI nicht erkennen – zumindest nicht bei einem in Storage integrierten Modell.

Jede dieser Kräfte ist ein dauerhaftes Merkmal der Umgebung, in der ein reales Unternehmen tätig ist. Architekturen, die darauf gründen, dass sie verschwinden, tragen die Kosten auf unbestimmte Zeit.

Die Verbundalternative

Die KI-Datenplattform von Dell basiert auf einer ganz anderen Prämisse. Statt von Kunden zu verlangen, Daten in einen vom Anbieter kontrollierten Namespace zu kopieren, bevor sie diese verwenden können, verfolgt Dell einen Verbundansatz: eine Steuerungsebene, die Daten dort verarbeitet, wo sie sich befinden, sei es in PowerScale, ObjectScale, Storage von Drittanbietern, Warehouses, SaaS-Lösungen oder der Public Cloud, und sie nur dann verschiebt, wenn das Verschieben tatsächlich die richtige Lösung ist.^4,5

Diese Designentscheidung ist eine direkte Anwendung des 3-Formen-Modells:

• • • Die Daten bleiben dort, wo sie gespeichert sind, und werden von den Teams kontrolliert, die sie bereits verwalten.
    • Die Metadaten werden überall verbreitet, sodass jede KI, die Sie auswählen, jede Ressource unabhängig vom Standort sieht.
    • Die Vektoren übertragen die Bedeutung in der gesamten Umgebung, sodass die KI Daten analysieren kann, ohne diese zuvor verschieben zu müssen.

Es ist nicht so, dass Verbundarchitekturen niemals Daten verschieben. Sie verschieben, wenn es sinnvoll ist. Aber sie machen Datenverschiebung nicht zur Voraussetzung, um Nutzen aus der Plattform zu ziehen. Und allein diese eine Architekturentscheidung beseitigt den Großteil des oben genannten betrieblichen Aufwands – denn dieser Aufwand entsteht nur, wenn Sie Ihre Architektur auf der Annahme aufgebaut haben, dass Daten erst verschoben werden müssen, bevor die KI darauf zugreifen kann.⁴

Außerdem wird das beibehalten, was dem CFO am meisten wichtig ist: Optionalität. Eine Steuerungsebene mit Verbundansatz bindet den Datenbestand nicht an den Namespace eines Anbieters. Sie belässt den Datenbestand dort, wo er sich bereits befindet, unter der Kontrolle der Teams, die ihn bereits verwalten, und macht ihn für die KI vor Ort nutzbar.^{2, 4}

Unabhängige Analysten warnen zunehmend vor dieser Dynamik. In einem kürzlich erschienenen Beitrag wurde angemerkt, dass trotz der Unterstützung offener Standards durch VAST dessen „einheitliche Architektur Abhängigkeiten schaffen könnte, die zukünftige Migrationen erschweren“ – eine höfliche Umschreibung dafür, dass es umso schwieriger wird, das System jemals wieder aufzugeben, je mehr Daten synchronisiert werden.² In einem anderen Beitrag wurde festgestellt, dass der Ansatz von VAST „eher dem Modell einer hyperkonvergenten Infrastruktur ähnelt und einen eng integrierten, fest definierten Stack bereitstellt, bei dem VAST die gesamte Erfahrung kontrolliert.“³ HCI hat der Branche vor Augen geführt, was geschieht, wenn dieses Modell auf Heterogenität in großem Maßstab trifft. Hier gelten dieselben Lektionen.

Drei Fragen, die Sie stellen müssen, bevor Sie unterschreiben

Diese Fragen sollten direkt in Ihre Angebotsanfrage aufgenommen werden.

1. 1. Wie viele Pipelines werden im stabilen Zustand in Ihren Namespace geleitet? Bitten Sie um eine realistische Schätzung auf der Grundlage eines Datenbestands, der Ihrem eigenen ähnelt, und nicht auf der Grundlage einer Referenzarchitektur, die auf einer „Greenfield“-Umgebung basiert. Ordnen Sie dies Ihren regulatorischen und anwendungsbezogenen Datenbeständen zu.
   2. Wer ist für den Abgleich verantwortlich, wenn sich ein Quellsystem ändert? Wenn die Antwort „Ihr Team, mit unseren Tools“ lautet, dann tragen Sie die Betriebskosten. Berechnen Sie diese.
   3. Was geschieht, wenn ich die Synchronisierung einer Quelle im dritten Jahr einstellen möchte? Die Antwort ist ein direktes Maß dafür, auf wie viel Flexibilität Sie verzichten, und ein klarer Hinweis darauf, wie viel Konfliktpotenzial die Architektur bei einem Ausstieg aufweist.

Die Kurzfassung: Bezahlen Sie nicht für etwas, von dem Ihnen niemand gesagt hat, dass Sie es kaufen.

Die nächsten Schritte

Im nächsten Beitrag komme ich zurück zum Thema Rechenzentrum, da die Auswirkung dieses Architekturaufwands nicht nur ein VZÄ-Problem ist.Es ist ein wirtschaftliches GPU-Problem.Wenn Daten erst bereitgestellt werden müssen, bevor sie verarbeitet werden können, ist der teuerste Posten in Ihrer KI-Infrastruktur derjenige, der die Rechnung zahlt.

 ¹VAST Data, „DataSpace and SyncEngine“, Produktdokumentation.

 ²DataPro.news, „VAST Data: Revolutionary AI OS or Silicon Valley Hyperbole?“. Juni 2025.

 ³NAND Research, „How to Think about VAST Data“, Februar 2026.

 ⁴PROWESS Consulting, „Architecture and Operational Comparison: Dell AI Data Platform vs. VAST AI OS“, im Auftrag von Dell, April 2026.

 ⁵Dell Technologies, „Dell AI Data Platform mit NVIDIA beschleunigt Enterprise AI durch bahnbrechende Innovationen bei Datenorchestrierung und Storage“, PR Newswire, März 2026.