Im Zuge der Digitalisierung von Wirtschaft und Verwaltung stellt sich immer h\u00e4ufiger die Frage der existenziellen Abh\u00e4ngigkeit von den \u201edigitalen Assets\u201c, also der Software, mit der die Prozesse der Organisation abgewickelt werden.<\/p>\n
Hat diese Software Fehler oder soll sie an ein ver\u00e4ndertes Gesch\u00e4ftsumfeld angepasst werden, muss zumeist der Programmcode ge\u00e4ndert werden. Hat diesen Programmcode (Quellcode) nur der Softwarehersteller selbst vorliegen, so entsteht eine starke Abh\u00e4ngigkeit, die das Kundenunternehmen in eine schwierige Position bringt, falls der Softwarehersteller ausf\u00e4llt.<\/p>\n
Auf der anderen Seite ist der Quellecode das geistige Eigentum des Softwareherstellers und wird aufgrund seiner leichten Kopierbarkeit als kritisches Betriebs- und Gesch\u00e4ftsgeheimnis geh\u00fctet. Die meisten Softwarehersteller (au\u00dfer nat\u00fcrlich im Open Source-Bereich) geben den Quellcode nicht an ihre Kunden heraus.<\/p>\n
Die Hinterlegung des Quellcodes (\u201eSoftware Escrow\u201c) bei einem neutralen und zur Geheimhaltung verpflichteten Dritten mit vertraglich vereinbarter Herausgabepflicht im Ernstfall (z.B. Insolvenz des Anbieters) wird oft als elegante L\u00f6sung dieses Interessenkonflikts angesehen. Das ist in vielen F\u00e4llen richtig und wird auch vom BSI als Ma\u00dfnahme zur Risikominderung empfohlen<\/a> – es gibt aber auch bestimmte Umst\u00e4nden, die eine Quellcode-Hinterlegung und anschlie\u00dfende eigenen Weiterentwicklung unwirtschaftlich oder undurchf\u00fchrbar machen und bei denen andere L\u00f6sungen zielf\u00fchrender sind. Diese Umst\u00e4nde werden im Folgenden beschrieben.<\/p>\n Grunds\u00e4tzliches Problem: \u00dcbergabe an neue Entwicklermannschaft<\/strong><\/p>\n Grunds\u00e4tzlich besteht das Problem, dass die \u00dcbergabe eines IT-Projekts an eine neue Entwicklungsmannschaft aufgrund der notwendigen Einarbeitung und R\u00fcstzeiten immer ein aufw\u00e4ndiges Unterfangen ist und das sogar dann, wenn die vorherigen Entwickler f\u00fcr R\u00fcckfragen oder Schulungen noch zur Verf\u00fcgung stehen. Im Fall der Herausgabe eines Quellcodes bei Insolvenz oder Einstellung des Gesch\u00e4ftsbetriebs sind die neuen Entwickler oft auf sich alleine gestellt und haben neben dem laufenden Softwaresystem im Bin\u00e4rcode nur den herausgegebenen Quellcode und (bestenfalls) die dazugeh\u00f6rige Dokumentation vorliegen. In der Praxis treten dann neben den typischen fachlichen Fehlern bei der Hinterlegung (fehlende Build-Programme, unzureichende Dokumentation, etc.,siehe [Stiemerling, ITRB]<\/a>) oft die folgenden, im Vorfeld zumeist unbeachteten Probleme auf:<\/p>\n Aufsetzen der Weiterentwicklung dauert lange und kann prohibitiv teuer sein<\/strong><\/p>\n Gerade f\u00fcr gr\u00f6\u00dfere Softwaresysteme sind – auch bei einer fachgerechten Hinterlegung – oft erhebliche Investitionen f\u00fcr 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\u00dfen Standard-ERP-Systemen) k\u00f6nnen diese Kosten und die Dauer im Verh\u00e4ltnis zum Preis der Software selbst bzw. m\u00f6glichen Alternativen prohibitiv hoch sein, so dass eine Quellcode-Hinterlegung \u2013 zu Ende gedacht \u2013 den angestrebten Zweck nicht erf\u00fcllt.<\/p>\n 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\u00fccksichtigen. In der Praxis werden diese Punkte bei einer Hinterlegung zumeist ignoriert \u2013 mit dem Resultat des Verbleibens signifikanter Risiken f\u00fcr den Notfallplan bei Ausfall des Softwareanbieters.<\/p>\n Eigenbetrieb einer vormaligen Cloud-Software kann prohibitiv teuer sein<\/strong><\/p>\n Viele Systeme werden heute nicht mehr \u201eon-premise\u201c beim Kunden installiert, sondern in der Cloud von speziellen Anbietern zur Verf\u00fcgung gestellt. Fallen diese Anbieter aus, hilft der ggf. hinterlegte Quellcode zun\u00e4chst nicht, da der Kunden \u00fcberhaupt erstmal an seine Daten kommen und den grunds\u00e4tzlichen Betrieb der Anwendung sicherstellen muss.<\/p>\n Diese Aspekte m\u00fcssen ebenfalls in einem Notfallplan f\u00fcr den Fall des Ausfalls des Cloud-Anbieters ber\u00fccksichtigt werden. Dabei ist das Aufsetzen eines eigenen Betriebs oft im Verh\u00e4ltnis zu den bisherigen Softwarekosten prohibitiv teuer, da der Anwender seine Betriebskosten im Gegensatz zu dem Anbieter der Cloud nicht auf viele Kunden umlegen kann.<\/p>\n Zwei Alternativen zur Quellcode-Hinterlegung<\/strong><\/p>\n Ergibt sich bei der systematischen Betrachtung der notwendigen Arbeitsschritte nach Herausgabe des Quellcodes, dass dadurch das Problem des Ausfalls des Softwareanbieters nicht zufriedenstellend gel\u00f6st werden kann, so stellt sich die Frage nach sinnvollen Alternativen.<\/p>\n 1. Teilquellcode-Offenlegung und Co-Development<\/em><\/strong><\/p>\n 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\u00fcckgehalten, sondern \u00fcbergeben wird. Insbesondere bei individuellen ERP-Anpassung, die auf Standardsoftware basieren, werden h\u00e4ufig industriespezifische \u201eAdd-Ons\u201c angeboten, die dann auf einen konkreten Kunden zugeschnitten worden sind. Da diese Add-Ons h\u00e4ufig ebenfalls in der Folge \u00a0als Standardprodukte vermarktet werden, wollen die Anbieter ihren Quellcode typischerweise auch f\u00fcr solche \u201eAdd-Ons\u201c nicht offen liegen.<\/p>\n In solchen F\u00e4llen ist es aber durch geschickte Verhandlung trotzdem oft m\u00f6glich, dem Risiko des Ausfalls (zumindest des Add-On-Anbieters) dadurch zu begegnen, dass eine Quellcode-Offenlegung f\u00fcr das individualisierte \u201eAdd-On\u201c 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\u00e4llt der Add-On-Anbieter dann tats\u00e4chlich aus, hat der Kunde einen gro\u00dfen Teil der notwendigen Arbeitsschritte zur kompletten \u00dcbernahme der Weiterentwicklung bereits geleistet. Ein (wesentlich unwahrscheinlicherer) Ausfall des zumeist sehr gro\u00dfen Anbieters des zugrundeliegenden ERP-Systems kann dann ggf. als verbleibendes, geringes Restrisiko verkraftet werden.<\/p>\n 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\u00fctzen, so stellt sich die Frage, ob dieser Anbieter der richtige Partner f\u00fcr das angedachte Projekt ist.<\/p>\n 2. Im Notfall: Daten\u00fcbernahme in ein Alternativsystem<\/em><\/strong><\/p>\n Bei kritischen Standardsystemen (z.B. Finanzbuchhaltung, Backupsysteme) bietet sich statt einer Quellcode-Hinterlegung auch die Entwicklung eines Notfallplans auf Basis der Daten\u00fcbernahme in ein Alternativsystem an. Wenn die Daten und Funktionen einer bestimmten Softwareklasse z.B. aus gesetzlichen oder technischen Gr\u00fcnden \u00e4hnlich sind, so kann ein \u00a0Notfallplan entwickelt werden, der vorsieht, z.B. die Buchhaltungsdaten in einem Standardformat zu exportieren um dann direkt den n\u00e4chsten Monatsabschluss in einem neuen System durchf\u00fchren zu k\u00f6nnen. Selbst bei moderat individualisierten Systemen ist die Konzeptionierung solcher Notfallstrategien m\u00f6glich, insbesondere wenn es vor Einf\u00fchrung der Systeme bereits einen \u201ePapierprozess\u201c gegeben hat, der im Ernstfall w\u00e4hrend einiger Zeit bis zur Fertigstellung des neu individualisierten Systems durchgef\u00fchrt werden kann.<\/p>\n Fazit: Sinnhaftigkeit von Software-Hinterlegung muss systematisch, d.h. als Element eines umfassenden Notfallplans, gepr\u00fcft werden<\/strong><\/p>\n 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\u00fcfung oft heraus, dass die notwendigen Schritte nach der Herausgabe viel zu lange dauern w\u00fcrden und\/oder ggf. prohibitiv teuer w\u00e4ren.<\/p>\n In diesen F\u00e4llen muss der Softwarekunde sinnvolle Alternativen entwickeln, um mit einem Ausfall des Herstellers umzugehen.<\/p>\n Eine M\u00f6glichkeit bei komplexen Systemen ist es, zumindest die \u00dcbergabe der Teile des Codes, die von kleineren Anbietern stark individualisiert wurden, direkt im Rahmen der Entwicklung in Form des Quellcodes zu verlangen.<\/p>\n Eine weitere Alternative ist es, als Notfallplan den Datenexport \u00fcber Standardformate in ein neues System eines Drittherstellers vorzusehen, ggf. mit zeitweisem R\u00fcckfall auf \u201ePapierprozesse\u201c.<\/p>\n Welche Strategie f\u00fcr 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<\/a> (der neben dem Ausfall von Softwareanbietern auch RZ-Ausf\u00e4lle etc. betrachtet) betrachtet und insbesondere im Hinblick auf die Durchf\u00fchrbarkeit der notwendigen Schritte nach der ggf. vorgesehen Quellcode-Herausgabe bewertet werden.<\/p>\n