Im Zuge der Digitalisierung von Wirtschaft und Verwaltung stellt sich immer häufiger die Frage der existenziellen Abhängigkeit von den „digitalen Assets“, also der Software, mit der die Prozesse der Organisation abgewickelt werden.

Hat diese Software Fehler oder soll sie an ein verändertes Geschäftsumfeld angepasst werden, muss zumeist der Programmcode geändert werden. Hat diesen Programmcode (Quellcode) nur der Softwarehersteller selbst vorliegen, so entsteht eine starke Abhängigkeit, die das Kundenunternehmen in eine schwierige Position bringt, falls der Softwarehersteller ausfällt.

Auf der anderen Seite ist der Quellecode das geistige Eigentum des Softwareherstellers und wird aufgrund seiner leichten Kopierbarkeit als kritisches Betriebs- und Geschäftsgeheimnis gehütet. Die meisten Softwarehersteller (außer natürlich im Open Source-Bereich) geben den Quellcode nicht an ihre Kunden heraus.

Die Hinterlegung des Quellcodes („Software Escrow“) bei einem neutralen und zur Geheimhaltung verpflichteten Dritten mit vertraglich vereinbarter Herausgabepflicht im Ernstfall (z.B. Insolvenz des Anbieters) wird oft als elegante Lösung dieses Interessenkonflikts angesehen. Das ist in vielen Fällen richtig und wird auch vom BSI als Maßnahme zur Risikominderung empfohlen – es gibt aber auch bestimmte Umständen, die eine Quellcode-Hinterlegung und anschließende eigenen Weiterentwicklung unwirtschaftlich oder undurchführbar machen und bei denen andere Lösungen zielführender sind. Diese Umstände werden im Folgenden beschrieben.

Grundsätzliches Problem: Übergabe an neue Entwicklermannschaft

Grundsätzlich besteht das Problem, dass die Übergabe eines IT-Projekts an eine neue Entwicklungsmannschaft aufgrund der notwendigen Einarbeitung und Rüstzeiten immer ein aufwändiges Unterfangen ist und das sogar dann, wenn die vorherigen Entwickler für Rückfragen oder Schulungen noch zur Verfügung stehen. Im Fall der Herausgabe eines Quellcodes bei Insolvenz oder Einstellung des Geschäftsbetriebs sind die neuen Entwickler oft auf sich alleine gestellt und haben neben dem laufenden Softwaresystem im Binärcode nur den herausgegebenen Quellcode und (bestenfalls) die dazugehörige Dokumentation vorliegen. In der Praxis treten dann neben den typischen fachlichen Fehlern bei der Hinterlegung (fehlende Build-Programme, unzureichende Dokumentation, etc.,siehe [Stiemerling, ITRB]) oft die folgenden, im Vorfeld zumeist unbeachteten Probleme auf:

Aufsetzen der Weiterentwicklung dauert lange und kann prohibitiv teuer sein

Gerade für größere Softwaresysteme sind – auch bei einer fachgerechten Hinterlegung – oft erhebliche Investitionen für die Suche nach neuen Entwicklern (oder auch einer kompetenten, dritten Softwarefirma), deren Einarbeitung und das technische Aufsetzen der Weiterentwicklung nach der Herausgabe notwendig. Bei umfangreicher Standardsoftware (z.B. großen Standard-ERP-Systemen) können diese Kosten und die Dauer im Verhältnis zum Preis der Software selbst bzw. möglichen Alternativen prohibitiv hoch sein, so dass eine Quellcode-Hinterlegung – zu Ende gedacht – den angestrebten Zweck nicht erfüllt.

Ein Notfallkonzept mit Sourcecode-Hinterlegung muss also neben der fachgerechten Hinterlegung auch die Arbeitsschritte, die voraussichtliche Dauer und die Kosten des Aufsetzens der Weiterentwicklung nach der Herausgabe berücksichtigen. In der Praxis werden diese Punkte bei einer Hinterlegung zumeist ignoriert – mit dem Resultat des Verbleibens signifikanter Risiken für den Notfallplan bei Ausfall des Softwareanbieters.

Eigenbetrieb einer vormaligen Cloud-Software kann prohibitiv teuer sein

Viele Systeme werden heute nicht mehr „on-premise“ beim Kunden installiert, sondern in der Cloud von speziellen Anbietern zur Verfügung gestellt. Fallen diese Anbieter aus, hilft der ggf. hinterlegte Quellcode zunächst nicht, da der Kunden überhaupt erstmal an seine Daten kommen und den grundsätzlichen Betrieb der Anwendung sicherstellen muss.

Diese Aspekte müssen ebenfalls in einem Notfallplan für den Fall des Ausfalls des Cloud-Anbieters berücksichtigt werden. Dabei ist das Aufsetzen eines eigenen Betriebs oft im Verhältnis zu den bisherigen Softwarekosten prohibitiv teuer, da der Anwender seine Betriebskosten im Gegensatz zu dem Anbieter der Cloud nicht auf viele Kunden umlegen kann.

Zwei Alternativen zur Quellcode-Hinterlegung

Ergibt sich bei der systematischen Betrachtung der notwendigen Arbeitsschritte nach Herausgabe des Quellcodes, dass dadurch das Problem des Ausfalls des Softwareanbieters nicht zufriedenstellend gelöst werden kann, so stellt sich die Frage nach sinnvollen Alternativen.

1. Teilquellcode-Offenlegung und Co-Development

Gerade bei Entwicklungsprojekten mit einem hohen Grad an individuellen Anforderungen und einem hohen Investment in kundenspezifische Codeanteile sollte man als Kunde immer darauf bestehen, dass der Quellcode nicht zurückgehalten, sondern übergeben wird. Insbesondere bei individuellen ERP-Anpassung, die auf Standardsoftware basieren, werden häufig industriespezifische „Add-Ons“ angeboten, die dann auf einen konkreten Kunden zugeschnitten worden sind. Da diese Add-Ons häufig ebenfalls in der Folge  als Standardprodukte vermarktet werden, wollen die Anbieter ihren Quellcode typischerweise auch für solche „Add-Ons“ nicht offen liegen.

In solchen Fällen ist es aber durch geschickte Verhandlung trotzdem oft möglich, dem Risiko des Ausfalls (zumindest des Add-On-Anbieters) dadurch zu begegnen, dass eine Quellcode-Offenlegung für das individualisierte „Add-On“ ausgehandelt wird. Wichtig dabei ist aber, dass intern beim Kunden ein gewisses Entwicklungs-Know-How zusammen mit der technischen Weiterentwickelbarkeit vor Ort aufgebaut wird. Fällt der Add-On-Anbieter dann tatsächlich aus, hat der Kunde einen großen Teil der notwendigen Arbeitsschritte zur kompletten Übernahme der Weiterentwicklung bereits geleistet. Ein (wesentlich unwahrscheinlicherer) Ausfall des zumeist sehr großen Anbieters des zugrundeliegenden ERP-Systems kann dann ggf. als verbleibendes, geringes Restrisiko verkraftet werden.

Weigert sich ein Anbieter eines stark im Quellcode zu individualisierenden Systems, den Quellcode mit diesem System auszuliefern und insbesondere ein Co-Development intern beim Kunden zu unterstützen, so stellt sich die Frage, ob dieser Anbieter der richtige Partner für das angedachte Projekt ist.

2. Im Notfall: Datenübernahme in ein Alternativsystem

Bei kritischen Standardsystemen (z.B. Finanzbuchhaltung, Backupsysteme) bietet sich statt einer Quellcode-Hinterlegung auch die Entwicklung eines Notfallplans auf Basis der Datenübernahme in ein Alternativsystem an. Wenn die Daten und Funktionen einer bestimmten Softwareklasse z.B. aus gesetzlichen oder technischen Gründen ähnlich sind, so kann ein  Notfallplan entwickelt werden, der vorsieht, z.B. die Buchhaltungsdaten in einem Standardformat zu exportieren um dann direkt den nächsten Monatsabschluss in einem neuen System durchführen zu können. Selbst bei moderat individualisierten Systemen ist die Konzeptionierung solcher Notfallstrategien möglich, insbesondere wenn es vor Einführung der Systeme bereits einen „Papierprozess“ gegeben hat, der im Ernstfall während einiger Zeit bis zur Fertigstellung des neu individualisierten Systems durchgeführt werden kann.

Fazit: Sinnhaftigkeit von Software-Hinterlegung muss systematisch, d.h. als Element eines umfassenden Notfallplans, geprüft werden

Software-Hinterlegung kann ein sinnvolles Mittel sein, um dem Risiko des Ausfalls eines Softwareanbieters entgegenzuwirken. Gerade bei umfangreichen und komplexen Softwaresystemen stellt sich bei einer solchen systematischen Prüfung oft heraus, dass die notwendigen Schritte nach der Herausgabe viel zu lange dauern würden und/oder ggf. prohibitiv teuer wären.

In diesen Fällen muss der Softwarekunde sinnvolle Alternativen entwickeln, um mit einem Ausfall des Herstellers umzugehen.

Eine Möglichkeit bei komplexen Systemen ist es, zumindest die Übergabe der Teile des Codes, die von kleineren Anbietern stark individualisiert wurden, direkt im Rahmen der Entwicklung in Form des Quellcodes zu verlangen.

Eine weitere Alternative ist es, als Notfallplan den Datenexport über Standardformate in ein neues System eines Drittherstellers vorzusehen, ggf. mit zeitweisem Rückfall auf „Papierprozesse“.

Welche Strategie für ein Unternehmen die Richtige ist, muss systematisch bei der – sowieso immer sinnvollen und oft sogar erforderlichen – Erstellung eines umfassenden IT-Notfallplans z.B. nach dem Standard BSI-100-4 (der neben dem Ausfall von Softwareanbietern auch RZ-Ausfälle etc. betrachtet) betrachtet und insbesondere im Hinblick auf die Durchführbarkeit der notwendigen Schritte nach der ggf. vorgesehen Quellcode-Herausgabe bewertet werden.

Mehr Informationen zu Escrow auf den neuen Themenseiten der ecambria experts: escrow.ecambria-experts.de