Den Ausstieg aus einer Softwarelösung schon beim Einstieg planen
Offener Quellcode erleichtert Änderungen. Welche Daten, Konten und Dienste bei einem Wechsel mitgehen müssen, entscheidet der gewählte Ausstiegsumfang.
Ein Ausstiegsplan sollte schon bei der Wahl einer Softwarelösung benennen, welcher Wechsel später möglich sein soll. Ein neues Entwicklungsteam, eine neue Hostingumgebung und der vollständige Ersatz verbundener Dienste sind unterschiedliche Vorhaben. Wer diese Grenze früh festlegt, kann Abhängigkeiten gezielt akzeptieren und die benötigten Nachweise vereinbaren.
Quelloffener Code lässt externe Abhängigkeiten bestehen
Eine Lizenz nach der Open Source Definition der OSI umfasst unter anderem Zugang zum Quellcode sowie die Möglichkeit, Änderungen und abgeleitete Werke weiterzugeben. Daraus folgt keine automatische Übernahme eines gehosteten Suchdienstes, eines Unternehmenskontos oder der dort gespeicherten Dokumente.
Im fiktiven Portal P-18 ist der Anwendungscode quelloffen lizenziert. Die Originaldokumente liegen in einem separaten Dateispeicher, die Zuordnung von Personen zu Projekten in der Anwendung und der Suchindex bei einem verwalteten Dienst. Ein neuer Entwickler kann den Code bearbeiten. Ob das Portal nach einem Anbieterwechsel dieselben Dokumente mit denselben Zugriffsregeln findet, bleibt eine eigene Frage.
Den Wechselumfang vor der Beschaffung unterscheiden
Für dieses Beispiel sind drei Ziele denkbar. Die Tabelle nennt erwartete Nachweise, keine bereits ausgeführte Migration.
Wechselziel | Was im Beispiel bestehen bleiben darf | Benötigter Nachweis |
|---|---|---|
Hosting, Speicher und Suchdienst | Das neue Team kann mit eigenen berechtigten Konten weiterarbeiten; Zuständigkeiten und benötigte Unterlagen sind übergeben. | |
Neue Hostingumgebung für die Anwendung | Speicher und Suchdienst unter Kontrolle des Unternehmens | Die Anwendung erreicht diese Dienste aus der neuen Umgebung und setzt die vereinbarten Zugriffsregeln weiterhin um. |
Vollständiger Ersatz der verbundenen Dienste | Die verwendeten Anbieter müssen nicht bleiben | Originaldokumente, beschreibende Metadaten und Berechtigungszuordnungen sind übernehmbar; Suche und Zugriffe werden im Ziel neu geprüft. |
Ein kopierter Suchindex ersetzt die Originaldokumente und ihre Zuordnungen nicht automatisch. Für einen Neuaufbau muss feststehen, woher Text, stabile Dokumentkennungen und Berechtigungen kommen. Auch ein Indexformat, das nur der bisherige Dienst versteht, ist noch kein brauchbarer Übergabebeleg für einen anderen Suchdienst.
Eine bewusst erhaltene Bindung kann sinnvoll sein
Ein verwalteter Dienst kann einen Nutzen liefern, der den späteren Wechselaufwand rechtfertigt. Die britische Regierungsleitlinie zu technischem Lock-in empfiehlt, den Wechselaufwand gegen den Nutzen des Bleibens abzuwägen. Sie behandelt auch offene Formate und die Verfügbarkeit von Wissen im Team.
Für den zweiten Tabellenfall kann es sinnvoll sein, den Suchdienst weiterzuverwenden. Dann muss klar sein, wer das Konto verwaltet, Zugänge vergeben kann und den Dienst nach dem Wechsel betreut. Soll auch dieser Dienst ersetzt werden können, gehören Datenzugang und die Prüfung einer Alternative zum zusätzlichen Umfang. Die Bezeichnung „Open Source“ erledigt diese Entscheidung nicht.
Den gewählten Umfang im Auftrag festhalten
Eine ausgefüllte Vereinbarung für das Beispiel könnte lauten: „Die Anwendung soll auf eine andere Hostingumgebung wechseln können. Dokumentenspeicher und Suchdienst bleiben in unseren Unternehmenskonten. Im Ziel werden das Öffnen eines erlaubten Dokuments und die Ablehnung desselben Dokuments für eine eingeschränkte Rolle geprüft.“
Damit ist die erhaltene Bindung sichtbar und die Prüfung an eine konkrete Aufgabe gekoppelt. Wenn später ein vollständiger Produktwechsel nötig wird, lässt sich gezielt feststellen, welche weiteren Daten, Schnittstellen und Kenntnisse dafür fehlen. Der Ausstiegsplan bleibt mit Änderungen am System fortzuschreiben.
Quellen
Weiterlesen
Alle Beiträge
Softwareentwicklung mit ASES
Individuelle Software, Web- und Mobile-Apps