Vendor Lock-in: Wo Behörden ihre Wahlfreiheit verlieren
Atix: Wie Abhängigkeiten entstehen – und sich vermeiden lassen
Herstellerabhängigkeit entsteht in der Behörden-IT selten durch eine einzelne Entscheidung. Wie viel Wahlfreiheit später bleibt, wird bereits bei Beschaffung und grundlegenden Architekturentscheidungen mitbestimmt. Entscheidend ist deshalb, wie gut sich eine IT-Infrastruktur über ihren gesamten Lebenszyklus verändern, ergänzen oder ersetzen lässt.
Mit OZG, EfA und der zunehmenden Vernetzung der Verwaltungs-IT steigt die Tragweite solcher Entscheidungen. Fachverfahren, Plattformen und Infrastrukturen greifen immer stärker ineinander. Damit wird Wechselfähigkeit umso wichtiger: Systeme und Plattformen müssen auch in vernetzten IT-Landschaften veränderbar und austauschbar sein.
Abhängigkeit entsteht im Alltag
Wie sich eine Lösung über Jahre im Betrieb entwickelt, lässt sich bei der Beschaffung nur begrenzt absehen.
Werden für zentrale administrative Aufgaben ausschließlich herstellerspezifische Werkzeuge eingesetzt, entstehen neue technische Bindungen. Gleiches gilt, wenn Konfigurationen nur mit proprietären Verfahren gepflegt werden können oder wesentliches Betriebswissen auf wenige Personen oder Dienstleister konzentriert ist.
Solange alles funktioniert, ist diese Abhängigkeit oft unsichtbar. Kritisch wird sie, wenn sich Rahmenbedingungen ändern: Ein Dienstleister soll gewechselt werden, neue Sicherheitsanforderungen entstehen, Infrastrukturkomponenten müssen ersetzt werden oder Lizenzbedingungen und Preise verändern sich deutlich. Auch Unternehmensübernahmen können dazu führen, dass sich Portfolios, Preismodelle oder verfügbare Leistungen ändern. Bestehende Abhängigkeiten können dann ungeplante Mehrkosten verursachen oder die bisherigen Handlungsoptionen einschränken.
Auch der Produktlebenszyklus kann die Wahlfreiheit begrenzen. Wird etwa eine Managementlösung eingestellt, ist eine Nachfolgelösung des bisherigen Herstellers – sofern vorhanden – nicht zwangsläufig eine echte Alternative. Stellt der Hersteller etwa von einer On-Premises-Lösung auf ein reines SaaS-Modell um, kann das mit bestehenden Sicherheits- oder Betriebsanforderungen kollidieren.
Wenn die Infrastruktur die Wahlfreiheit einschränkt
Behörden-IT ist häufig heterogen – nicht immer aus eigener Entscheidung. Neben unterschiedlichen Betriebssystemen, virtuellen Maschinen, Rechenzentren und Cloud-Umgebungen müssen auch zentral bereitgestellte oder nachgenutzte Fachanwendungen integriert werden. Diese können technische oder plattformspezifische Vorgaben mitbringen.
Eine zunächst sinnvolle Standardisierung kann dabei später zur Einschränkung werden. Ist die Umgebung vollständig auf eine Linux-Distribution ausgerichtet und erfordert eine neue Fachanwendung eine andere, müssen Vorgaben angepasst oder zusätzliche Betriebsstrukturen aufgebaut werden.
Containerisierung kann solche Konflikte teilweise abfedern, schafft aber eine weitere Plattformebene mit eigenen Anforderungen. Ein späterer Plattformwechsel oder Betrieb in einer anderen Behördenumgebung kann dennoch zusätzlichen Anpassungsaufwand verursachen.
Problematisch ist deshalb weniger die Heterogenität selbst als der Betriebsaufwand, den sie erzeugen kann. Benötigt jede Plattform eigene Verwaltungswerkzeuge, Prozesse und Spezialwissen, steigen Aufwand und personelle Abhängigkeiten. Die technische Wahlfreiheit bleibt zwar erhalten, ist in der Praxis aber mit Aufwand verbunden.
Entscheidend ist deshalb, ob sich neue Plattformen in bestehende Management- und Betriebsprozesse integrieren lassen.
Automatisierung schafft mehr Unabhängigkeit im Betrieb
Standardisierte und automatisierte Abläufe können helfen, komplexe Betriebsstrukturen beherrschbar zu halten.
Werden Systeme über Jahre manuell eingerichtet und gepflegt, entsteht fast zwangsläufig individuelles Spezialwissen. Bestimmte Konfigurationen funktionieren dann mitunter nur deshalb, weil einzelne Administratoren oder externe Dienstleister die notwendigen Schritte kennen.
Dokumentierte und reproduzierbare Prozesse schaffen hier Abhilfe: Systeme lassen sich nach definierten Standards bereitstellen, Konfigurationen konsistent verteilen und wiederkehrende Aufgaben kontrolliert ausführen.
So lassen sich Management- und Betriebsprozesse leichter auf andere Teams, Dienstleister oder Plattformen übertragen – und betriebliche Abhängigkeiten reduzieren.
Patch- und Updateprozesse sichern den Handlungsspielraum
Wie wichtig beherrschbare Betriebsprozesse sind, zeigt sich besonders beim Patch- und Update-Management.
Neue Schwachstellen können schnelle Reaktionen erfordern. Behörden müssen wissen, welche Systeme betroffen sind, welche Updates verfügbar sind und wie sie kontrolliert verteilt werden können.
Kritisch wird es, wenn für die Steuerung verschiedener Plattformen mehrere Werkzeuge und das Wissen weniger Spezialisten erforderlich ist. Wie abhängig der Betrieb davon ist, zeigt sich besonders im Sicherheitsfall, wenn schnell reagiert werden muss.
Entscheidend ist, ob eine Behörde ihre Systeme selbst überblicken und Aktualisierungen steuern kann:
- Welche Systeme und Softwarestände sind von einer Schwachstelle betroffen?
- Welche Updates stehen bereit und wurden getestet?
- Welche Systeme wurden aktualisiert und wo bestehen noch Risiken?
Wer diese Fragen nicht kurzfristig beantworten und Updates kontrolliert steuern kann, ist im Sicherheitsfall nur eingeschränkt handlungsfähig.
Enterprise Open Source schafft mehr Optionen
Enterprise Open Source kann helfen, Abhängigkeiten zu reduzieren. Open Source und offene Standards allein garantieren jedoch noch keine Wahlfreiheit.
Das zeigt sich etwa bei Enterprise-Linux-Distributionen: AlmaLinux, Oracle Linux, Red Hat Enterprise Linux und Rocky Linux sind weitgehend kompatibel. Damit besteht die Möglichkeit für einen Wechsel zwischen den Distributionen. Behörden können so unterschiedliche Anbieter, Supportmodelle und Konditionen vergleichen.
Diese Wahlfreiheit kann jedoch wieder eingeschränkt werden, wenn zusätzliche Management- oder Betriebswerkzeuge nur eine bestimmte Distribution unterstützen. Dann entsteht die Abhängigkeit nicht durch das Betriebssystem selbst, sondern durch das Tooling und die darauf ausgerichteten Prozesse.
Entscheidend ist deshalb nicht nur, wie offen die eigentliche Plattform ist, sondern ob auch die eingesetzten Werkzeuge und Betriebsprozesse einen späteren Wechsel zulassen.
Beschaffung muss den späteren Betrieb mitdenken
Die bisherigen Beispiele zeigen: Bei der Beschaffung sollte nicht nur geprüft werden, ob eine Fachanwendung funktional offen ist, sondern auch, wie flexibel sie sich später betreiben, erweitern oder ablösen lässt.
Daraus ergeben sich konkrete Fragen für Ausschreibung und Architektur:
- Lassen sich zusätzliche Betriebssysteme oder Plattformen in bestehende Management- und Betriebsprozesse integrieren?
- Sind Schnittstellen offen dokumentiert und lassen sich Systeme darüber automatisiert verwalten?
- Sind Konfigurationen und Betriebsprozesse reproduzierbar?
- Können Patches und Updates zentral gesteuert und dokumentiert werden?
- Können Daten vollständig in dokumentierten, standardisierten Formaten exportiert werden?
- Sind zentrale Betriebsaufgaben an proprietäre Software oder das Know-how eines einzelnen Anbieters gebunden?
Über zehn oder mehr Betriebsjahre können solche Kriterien wichtiger sein als einzelne Funktionen der Fachanwendung.
Weiterführende Checkliste:
Die Checkliste „Wie souverän ist Ihre IT-Infrastruktur wirklich?“ unterstützt bei einer ersten Standortbestimmung zu Abhängigkeiten und möglichen Handlungsfeldern.
Wahlfreiheit langfristig sichern
Herstellerabhängigkeiten sind in moderner IT nicht grundsätzlich problematisch. Kritisch werden sie, wenn Alternativen faktisch nicht mehr nutzbar sind.
Wahlfreiheit muss deshalb über den gesamten Lebenszyklus gesichert werden.
Vendor Lock-in wird häufig früh angelegt, verfestigt sich im Betrieb und zeigt sich besonders dann, wenn sich Anforderungen oder Rahmenbedingungen ändern.
Wer Beschaffung und Architektur mit Blick auf den späteren Betrieb plant, hält sich langfristig Wechseloptionen offen.
