Technische Souveränität & Interoperabilität

Technische Souveränität misst die Wechselfähigkeit eines Dienstes. Solange ein Dienst nicht innerhalb vertretbarer Frist und zu vertretbaren Kosten gegen einen anderen austauschbar ist, ist der Kunde strukturell von einem einzelnen Anbieter abhängig — unabhängig davon, wie sicher oder transparent dieser Anbieter im Einzelnen ist.

Diese Domäne adressiert daher die strukturelle Verhandlungsmacht. Sie ist die Domäne, die langfristige Preis-, Funktions- und Sicherheitsverhandlungen erst ermöglicht.

Eine hohe Bewertung in D3 verlangt sowohl offene Schnittstellen als auch die nachgewiesene Migrationsfähigkeit in realen Szenarien. Behauptete Portabilität ohne reproduzierbare Exit-Übung zählt nicht.

• Offene Standards und Open-Source-Komponenten

  Anteil offener Standards an Schnittstellen, Datenformaten und Kernkomponenten. Vermeidung proprietärer Sackgassen.

• Vollständig dokumentierte APIs

  Versionierte, vertraglich stabile, vollständig dokumentierte Schnittstellen für alle administrativen und datenbezogenen Funktionen.

• Datenportabilität in offenen Formaten

  Exportierbarkeit aller Kundendaten in offenen, dokumentierten Formaten — inklusive Metadaten und Beziehungen.

• SBOM-Bereitstellung

  Vollständige Software Bill of Materials für eingesetzte Komponenten, regelmäßig aktualisiert, maschinenlesbar.

• Exit-Kosten-Matrix

  Dokumentierte Aufwands- und Kostenabschätzung für vollständige Migration in vergleichbare Zielumgebungen.

• Kompatibilität zu Konkurrenzdiensten

  Nachgewiesene Migrationspfade in mindestens zwei konkurrierende Zielarchitekturen — idealerweise als reproduzierbare Referenzimplementierung.

• Proprietäre Lock-in-Elemente

  Transparente Auflistung aller proprietären Datenbanken, Funktionen, ML-Modelle oder Konfigurationsformate, die einen Wechsel erschweren.

1. Welche der vom Dienst genutzten Datenformate sind offen standardisiert?
2. Ist eine Referenzmigration in eine konkurrierende Zielumgebung dokumentiert und reproduzierbar?
3. Welche proprietären Komponenten besitzen kein funktionsäquivalentes offenes Pendant?
4. Existiert eine vollständige, aktuelle SBOM — maschinenlesbar im SPDX- oder CycloneDX-Format?
5. Welche dokumentierte Exit-Kostenabschätzung liegt für die typische Kundenkonfiguration vor?
6. Sind die APIs versioniert und mit verbindlicher Deprecation-Frist versehen?
7. Welche Datenkategorien sind nicht oder nur unvollständig exportierbar?

• API-Spezifikationen (OpenAPI, AsyncAPI) inklusive Versionspolitik
• SBOM im SPDX- oder CycloneDX-Format
• Exit-Drehbuch mit Schätzung von Dauer, Kosten und Datenverlust-Risiko
• Reproduzierbares Migrationsbeispiel in eine alternative Zielarchitektur
• Liste proprietärer Komponenten mit Risikobewertung

• API-Vollständigkeit nur für gängige Funktionen, kritische Administrationsoperationen nur über Web-UI
• Export in offenem Format, aber ohne Metadaten und Berechtigungsbeziehungen
• SBOM nur auf Anfrage und ohne maschinenlesbares Format
• Versteckter Lock-in über proprietäre Konfigurationsformate
• Exit-Kostenangaben ohne Referenz auf real durchgeführte Migration

• Übersicht aller vier Domänen
• Aggregationsprinzip
• Level-System L0–L3
• Verhältnis zu anderen Standards