Handlungsfähigkeit braucht konkrete Anforderungen
Ein Anbieter erhöht seine Preise, eine zentrale Software wird abgekündigt oder ein Betriebsdienstleister fällt aus. In solchen Situationen zeigt sich, wie viel Handlungsspielraum eine Organisation tatsächlich hat. Kann sie ihre Daten weiterverwenden? Kann ein anderer Partner den Betrieb übernehmen? Und lässt sich eine betroffene Komponente ersetzen, ohne die gesamte Plattform neu aufzubauen?
Digitale Souveränität wird damit zu einer Architekturaufgabe. Die Strategie des IT-Planungsrats von 2021 (PDF) benennt dafür drei Ziele: Wechselmöglichkeiten, Gestaltungsfähigkeit und Einfluss auf Anbieter. Für die Umsetzung leiten wir daraus eine Leitfrage ab: Welche Abhängigkeiten sind vertretbar, und welche Fähigkeiten müssen wir erhalten, um bei Veränderungen selbst entscheiden zu können?
Die Antwort sollte je nach Fachverfahren und Kritikalität unterschiedlich ausfallen. Für eine öffentliche Informationsseite gelten andere Anforderungen als für ein zentrales Antragsverfahren. Wer jede Anwendung maximal unabhängig auslegt, erhöht möglicherweise Kosten und Komplexität, ohne einen entsprechenden Nutzen zu gewinnen.
1. Abhängigkeiten sichtbar machen und bewerten
Am Anfang steht eine Bestandsaufnahme entlang der fachlichen Leistungen. Erfassen Sie Anwendungen, Datenbestände, Schnittstellen, Identitätsdienste, Betriebswerkzeuge und Dienstleister. Berücksichtigen Sie auch weniger sichtbare Bindungen: proprietäre Erweiterungen, nur beim Anbieter vorhandenes Wissen oder administrative Konten, auf die die eigene Organisation keinen Zugriff hat.
Bewerten Sie anschließend drei Fragen gemeinsam: Wie schwer wäre ein Ausfall oder eine unerwartete Änderung? Wie aufwendig wäre ein Wechsel? Und welche realistische Alternative steht zur Verfügung? So entsteht eine priorisierte Übersicht, aus der sich technische und organisatorische Maßnahmen ableiten lassen.
Eine bewusst akzeptierte Abhängigkeit kann wirtschaftlich sinnvoll sein. Halten Sie dafür den Nutzen, die Risiken, die verantwortliche Person und einen Überprüfungstermin fest. Ein Beschluss ohne Verantwortlichkeit und Wiedervorlage verliert im Tagesgeschäft schnell seine Wirkung.
2. Daten und Schnittstellen für einen Wechsel vorbereiten
Ein Exportknopf allein schafft noch keine Wechselmöglichkeit. Entscheidend ist, ob sich die exportierten Informationen vollständig und verständlich in einem anderen System nutzen lassen. Zu Geschäftsdaten gehören je nach Anwendung auch Anlagen, Metadaten, Beziehungen, Bearbeitungsstände und relevante Historien. Ein CSV-Export ohne Datenmodell kann diese Zusammenhänge verlieren.
Definieren Sie deshalb Exportumfang, Formate, Schemata und die Bedeutung der Felder. Prüfen Sie mit repräsentativen Testdaten, ob ein Import im Zielsystem funktioniert und fachliche Zusammenhänge erhalten bleiben. Dabei sind Berechtigungen sowie Aufbewahrungs- und Löschanforderungen gesondert zu berücksichtigen.
Auch Schnittstellen müssen nachvollziehbar sein. OpenAPI beschreibt HTTP-Schnittstellen in einem standardisierten Format. Das erleichtert Dokumentation und technische Integration. Eine solche Beschreibung garantiert allerdings keine fachliche Austauschbarkeit: Datenbegriffe, Fehlerbehandlung, Versionierung und herstellerspezifische Erweiterungen müssen ebenfalls abgestimmt werden.
Für die Anmeldung bietet OpenID Connect ein standardisiertes Authentifizierungsprotokoll auf Basis von OAuth 2.0. Damit lässt sich die Identitätsprüfung von der Anwendung trennen. Rollenmodelle, Benutzerzuordnungen und angebundene Verzeichnisse bleiben dennoch Teil der Migrationsplanung.
3. Austauschbarkeit an den richtigen Stellen schaffen
Trennen Sie fachliche Logik, Integration und infrastrukturspezifische Funktionen dort, wo ein späterer Wechsel plausibel ist. Ein Adapter kann beispielsweise verhindern, dass die Besonderheiten eines Zahlungsdienstes in zahlreiche Fachmodule einfließen. Muss der Dienst ersetzt werden, bleibt der Anpassungsbedarf dadurch besser eingrenzbar.
Dafür ist keine pauschale Umstellung auf Microservices erforderlich. Auch ein modular aufgebauter Monolith kann klare Verantwortlichkeiten und stabile Schnittstellen bieten. Viele verteilte Dienste erhöhen dagegen die Anforderungen an Überwachung, Fehleranalyse und Betrieb. Die passende Struktur richtet sich nach fachlichen Grenzen und den Fähigkeiten des Teams.
Ähnliches gilt für Cloud-Plattformen. Container können die Bereitstellung von Anwendungen erleichtern; angebundene Datenbanken, Identitätsdienste, Netzwerkfunktionen und Betriebsprozesse werden dadurch nicht automatisch portabel. Eine zweite Cloud schafft erst dann eine belastbare Alternative, wenn die Anwendung dort mit ihren Abhängigkeiten tatsächlich lauffähig ist.
Vergleichen Sie daher den Nutzen spezialisierter Plattformdienste mit den Kosten eines möglichen Ausstiegs. Für manche Anwendungen ist ein dokumentierter und erprobter Umzugsweg ausreichend. Ein dauerhafter Parallelbetrieb bei mehreren Anbietern sollte einen konkreten fachlichen Nutzen haben.
4. Betriebsfähigkeit als Teil der Architektur behandeln
Eine übertragbare Lösung braucht mehr als Quellcode. Zum Übergabepaket gehören reproduzierbare Installationsabläufe, Konfigurationen, Schnittstellendokumentation, Überwachung, Wiederanlaufanweisungen und klare Zuständigkeiten. Geheimnisse und Schlüssel müssen dabei über einen geregelten, geschützten Prozess bereitgestellt werden.
Open Source kann die Prüfung, Anpassung und Weiterentwicklung einer Lösung ermöglichen. Ob daraus praktische Unabhängigkeit entsteht, hängt unter anderem von Lizenzbedingungen, Projektpflege, Dokumentation und verfügbaren Fachkräften ab. Fehlt das nötige Wissen, verlagert sich die Abhängigkeit leicht vom Hersteller auf einen einzelnen Dienstleister.
Ein aussagekräftiger Nachweis ist eine Betriebsübergabe in einer isolierten Testumgebung: Ein anderes qualifiziertes Team setzt die Anwendung anhand der Unterlagen auf, stellt eine Sicherung wieder her und bearbeitet einen simulierten Störfall. Die dabei auftretenden Lücken werden vor dem Ernstfall sichtbar.
Vereinbaren Sie auch organisatorisch, welche Dokumentation, Nutzungsrechte, Zugänge und Unterstützungsleistungen für eine Übergabe verfügbar sein müssen. Architektur, Einkauf und Betriebsverantwortliche sollten diese Anforderungen gemeinsam formulieren und ihren Erfüllungsstand regelmäßig prüfen.
Beispiel: Eine kommunale Antragsplattform
Das folgende illustrative Szenario zeigt die Umsetzung: Eine Kommune möchte Onlineanträge mit Anmeldung, Anlagen und Übergabe an ein Fachverfahren bereitstellen. Formularlogik, Benutzerverwaltung und Datenhaltung liegen zunächst eng gekoppelt in einer Plattform. Ein Wechsel würde deshalb gleichzeitig mehrere zentrale Funktionen betreffen.
Ein mögliches Zielbild trennt die Verantwortlichkeiten: Ein Identitätsdienst übernimmt die Anmeldung, eine Formularkomponente erfasst Eingaben, eine Prozesskomponente verwaltet Bearbeitungsstände und eine Integrationsschicht übergibt Daten an das Fachverfahren. Dokumentierte Datenmodelle und Schnittstellen verbinden diese Bausteine. Ob dafür getrennte Produkte nötig sind, wird anhand von Aufwand und Wechselbedarf entschieden.
Die Abnahme umfasst einen konkreten Wechselversuch: Ausgewählte Anträge werden mit Anlagen und Bearbeitungsständen exportiert und in einer alternativen Testumgebung eingelesen. Anschließend wird geprüft, ob die Bearbeitung fortgesetzt werden kann und die Zuordnung zum Fachverfahren erhalten bleibt. Synthetische Testdaten vermeiden dabei die unnötige Verwendung personenbezogener Echtdaten.
Das macht verbleibende Bindungen sichtbar. Beispielsweise können spezielle Formularregeln weiterhin nur in der ursprünglichen Plattform ausführbar sein. Dann braucht es eine dokumentierte Überführung dieser Regeln und eine realistische Aufwandsschätzung. Der wirtschaftliche Vorteil liegt in einem besser kalkulierbaren Wechsel und einer belastbareren Verhandlungsposition.
Fünf Prüfkriterien für die nächste Architekturentscheidung
Formulieren Sie Ziele so, dass ihre Erfüllung nachgewiesen werden kann. Die folgenden Kriterien sind ein Ausgangspunkt; konkrete Zeit-, Kosten- und Qualitätsgrenzen legt die Organisation passend zur Kritikalität fest.
- Daten weiterverwenden: Ein definierter Testbestand lässt sich einschließlich relevanter Anlagen und Beziehungen exportieren, importieren und fachlich abgleichen.
- Komponenten ersetzen: Für eine kritische Komponente ist eine Alternative benannt; notwendige Anpassungen und Schnittstellentests sind dokumentiert.
- Betrieb übertragen: Ein zweites qualifiziertes Team kann die Lösung mit den verfügbaren Unterlagen bereitstellen und betreiben.
- Wiederanlauf beherrschen: Die Wiederherstellung wird getestet. Gemessene Wiederanlaufzeit und möglicher Datenverlust werden mit den fachlichen Zielen verglichen.
- Ausstieg kalkulieren: Datenübernahme, Anpassungen, Unterstützungsleistungen und Übergangsbetrieb sind im Wechselplan berücksichtigt und mit Verantwortlichkeiten versehen.
Beginnen Sie mit einem kritischen Verfahren und einem überschaubaren Nachweis. Aus den Ergebnissen lassen sich wiederverwendbare Architekturvorgaben und Abnahmekriterien entwickeln. Digitale Souveränität wird so zu einer fortlaufend überprüfbaren Fähigkeit: Die Organisation versteht ihre Abhängigkeiten, kann Alternativen bewerten und einen notwendigen Wechsel praktisch umsetzen.