Warum die meisten Sovereign Stacks von vornherein im Test durchfallen Vier Kriterien für echte Souveränität

Anbieter zum Thema

SUSE Software Solutions Germany GmbH

Hyland Software Germany GmbH

STACKIT - Schwarz Digits Cloud GmbH & Co. KG

Yorizon GmbH & Co. KG

Suchen Sie sich ein Szenario aus: Sanktionen, neue Eigentümer eines Lieferanten, eine Executive Order in den USA, ein Vertragsstreit. Was bedeutet das für Ihre IT-Umgebung?

Wenn ein Teil Ihrer Antwort ist, dass Sie mit der Rechtsabteilung eines Anbieters in Verhandlungen treten, dass Sie das Problem an eine staatliche Behörde eskalieren oder auf eine regulatorische Ausnahmeregelung warten, dann haben Sie keine Souveränität. Sie haben nur eine verwaltete Abhängigkeit in guter Verpackung. Sie sind schon vom Tag der Inbetriebnahme an verwundbar.

Die Souveränitätslücke

Das ist der Stresstest, den die meisten vorgeblich souveränen Stacks auf dem heutigen Markt nicht bestehen, aber niemand bemerkt es. Es ist der Test, den Käufer weltweit laut einfordern sollten. Und es ist nicht nur ein Randthema: Laut der von Suse in Auftrag gegebenen Studie „Navigating Digital Resilience 2026“ legen erstaunliche 98 Prozent der Unternehmen Wert auf digitale Souveränität. Zugleich ergreifen jedoch nur 52 Prozent aktiv Maßnahmen, um diese zu erreichen.

Genau in dieser massiven Umsetzungslücke gedeihen herstellerorientierte Pakete, die das Etikett der Souveränität tragen, ohne dass sie dieses Versprechen in der betrieblichen Realität einhalten könnten.

Wann ist „sovereign“ gleich „souverän“?

Dies ist nicht nur eine Erkenntnis aus China oder dem Nahen Osten, sie gilt auch für Europa. Es betrifft jedes Unternehmen, in dem IT geschäftskritisch geworden ist. Beginnen wir mit ein paar Grundlagen:

• Souveränität ist eine Haltung, kein Produkt.

• Sogenannte „Sovereign Stacks“ von Anbietern können operative Abhängigkeiten mit sich bringen.

• Open Source, offene Standards, Portabilität und rechtliche Unabhängigkeit sind für echte Souveränität unerlässlich.

• Käufer sollten Souveränität anhand der architektonischen Unabhängigkeit bewerten, nicht anhand des Marketing-Namens.

Ein Beispiel: IBM hat kürzlich IBM Sovereign Core angekündigt. Ein Software-Bundle, das auf Red Hat OpenShift basiert, mit HashiCorp Vault, IBM Verify und IBM Concert als zusätzliche Komponenten. Kein Zweifel: Dieses Bundle enthält großartige Software. Aber warum wird hier das Wort „Sovereign“ verwendet? Diese Produkte, ob einzeln oder kombiniert, weisen keinerlei souveräne Eigenschaften auf. Was ist hier los? Sind wir in eine Phase des „Sovereign“-Washings eingetreten?

Eine ganze Welle solcher anbietergesteuerten Souveränitätsangebote überschwemmt gerade den Markt. Die Marketingseiten strahlen Zuversicht aus. Jedes Angebot verspricht operative Kontrolle, kontinuierliche Compliance-Überwachung, hybriden Einsatz und KI-fähige Infrastruktur. Überall sind die richtigen Schlagworte deutlich zu lesen. Die Warnhinweise sind dagegen zurückhaltender. Die genaue Herkunft dieser Angebote ist nicht immer ersichtlich. Und tatsächlich liegt die Basis dieser Angebote oft bei einem einzigen Anbieter - und zwar unter einer Rechtsordnung, die die Ihre nicht gleichermaßen respektiert. Das bedeutet, dass der Käufer dem Anbieter weiterhin vertrauen und die Validierung selbst vornehmen muss.

Das Problem mit vorgefertigten Stacks

Und das ist der Punkt. Die meisten „souveränen“ Stacks haben einen Single Point of Failure: den Anbieter. Wenn ein angeblich souveränes Angebot erfordert, dass man seinem Anbieter und seinem Managed-Service-Provider voll und ganz vertraut, ist die Abhängigkeit nicht beseitigt, sondern nur verlagert. Operative Transparenz in einem Stack, den man nicht vollständig kontrolliert, mag ein erster Schritt in die richtige Richtung sein. Aber dies ist keine Souveränität. Die Black Box wird nur einen Spaltbreit geöffnet.

In den meisten dieser vorgefertigten Bundles lauert eine zweite, subtilere Falle. Die Plattform wird als flexibel angepriesen. Aber der Stack schreibt einen bestimmten Identitätsanbieter, einen bestimmten Secrets-Manager, eine bestimmte Compliance-Engine, eine bestimmte Observability-Schicht und eine bestimmte Kubernetes-Distribution vor. Jedes Teil ist „Open Source-basiert“. Aber keines davon kann gegen andere Optionen ausgetauscht werden. Wenn Sie dies tun, verlieren Sie den Support, für den Sie bezahlen.

Europäische Käufer können ihre eigenen Komponenten nicht in ein solches Paket einbringen. Sie erhalten den Katalog eines Anbieters mit einem Hinweis auf Souveränität auf der Titelseite. Die Wahlmöglichkeit wurde jedoch durch eine kuratierte Liste ersetzt. Und der Kurator ist derselbe Anbieter, von dessen Abhängigkeit der Käufer sich gerade befreien möchte.

Der Sinn des Aufbaus von Resilienz besteht ja gerade darin, dass kein einzelner Anbieter eine Kontrolle über Ihren IT-Stack ausübt, die sich nicht umgehen lässt. Ein Stack, der vorschreibt, welches Verschlüsselungstool, welchen Identitätsanbieter und welche KI-Laufzeitumgebung Sie verwenden müssen, bietet keine Wahl. Die Gesamtlösung bleibt eine Black Box. Die bessere Option ist ein Stack auf Basis offener Standards, bei dem Komponenten ausgetauscht werden können und der gesamte Stack komponierbar wird.

Wie US-Konzerne Europas digitale Unabhängigkeit untergraben

Souveränitäts-Washing in der Cloud

Open Source vs. „Open Source-basiert“: Der entscheidende Unterschied

Der Grund, warum jeder Anbieter darauf aus ist, den Begriff „open“ zu verwenden, liegt auf der Hand: 94 Prozent der IT-Führungskräfte betrachten Open Source-Technologie mittlerweile als sehr oder extrem wichtig für ihre Resilienzstrategie. Doch mit zunehmender Reife des Marktes wird die Unterscheidung zwischen „Open Source-basiert“ und „vollständig offen“ zu einer Tür, die nur in eine Richtung offensteht.

Aber „open“ sollte kein Marketing-Begriff sein, sondern einen vierstufigen Test bestehen. Jeder Käufer, der ernsthaft an seiner Souveränität arbeitet, sollte seine Anbieter an denselben Maßstäben messen:

• Open Source, mit Verfügbarkeit des vollständigen Quellcodes. Nicht „Open Source-basiert“. Nicht „aufgebaut auf“ etwas Offenem. Der Quellcode, den der Käufer prüft, muss genau der Quellcode sein, der in der Produktion läuft.

• Offene Standards. Komponenten müssen austauschbar sein. Wenn es auch nur einen einzigen Teil gibt, den man nicht ersetzen kann, ohne den Rest der Bedingungen außer Kraft zu setzen, haben Sie Vendor-Lock-in.

• Die Option, die Software überall zu betreiben. Keine geschlossene Cloud, keine Erfordernis für eine Genehmigung, Nutzungsmöglichkeit selbst in Air-Gapped-Umgebungen.

• Freiheit bei der Wahl des Rechtsraums. Die Software sollte in der gewünschten Region unterstützt werden.

Diese vier Punkte sind nicht verhandelbar. Sobald einer davon nicht gegeben ist, hat die Souveränitätsgeschichte eine Achillesferse. Wenn alle vier erfüllt sind, gelangt ein Käufer von der Aussage „Wir vertrauen diesem Anbieter“ zu „Wir müssen das nicht“.

Stellen Sie die richtigen Fragen!

In Kundengesprächen weltweit zeigt sich gerade ein echter Bedarf an Unabhängigkeit. Anbieter sollten die unangenehmen Fragen beantworten, statt sie zu umschiffen:

• Wo befindet sich die Quelle des Angebots?

• Wer kontrolliert sie?

• Was passiert, wenn der Käufer abwandert?

• Wessen Rechtsprechung gilt, wenn es einmal schwierig wird?

Die Anbieter, die sich diesen Fragen direkt stellen, sind diejenigen, die europäische Käufer in die engere Wahl ziehen sollten. Denn Souveränität ist kein Produkt. Es ist eine Reihe von architektonischen Entscheidungen, die transparent getroffen werden und die ein Käufer überprüfen und reproduzieren kann.

„Souveränitäts-Washing“ bei Cloud-Diensten

ZenDiS: Digitale Souveränität ist mehr als ein Standortversprechen

(ID:50846047)