Schon mittelgroße Unternehmen nutzen hunderte einzelne Softwares oder Cloud-Services im Rahmen ihrer IT-Landschaft. Stellt einer der Lieferanten dieser Komponenten seine Tätigkeit ein, wird der geregelte Betrieb der eigenen IT gestört. Handelt es sich selbst betriebene um On-Premises-Software, kann diese nicht mehr aktualisiert werden. Geht es um Cloud-Software, dann ist neben der Weiterentwicklung auch die akute Nutzung durch den Kunden gefährdet.

Unternehmen versuchen sich mit Hilfe eines Software-ESCROW-Vertrags gegen diese Risiken abzusichern. Hierbei hinterlegt der Lieferant den jeweils aktuellen Software-Code bei einer dritten Partei, dem ESCROW-Dienstleister. Im Falle einer Insolvenz oder anderer vorab festgelegter Fälle, erhält der Kunde Zugang zum Code und kann, theoretisch, die Software auch ohne Mitwirkung des Lieferanten eigenständig weiterentwickeln und betrieben.

Macht ESCROW digital souverän?

Daniela: Marcel, würdest Du einem Unternehmen raten, seine extern erworbene, nicht-proprietäre Software über ein Escrow-Agreement abzusichern?

Marcel: Das hängt davon ab, was Du eigentlich mit dem Quellcode machen willst, also welchen Zweck der Quellcode erfüllen soll: willst Du mit dem Quellcode die Software weiterentwickeln oder willst Du lediglich den Betrieb aufrechterhalten. Das sind aus meiner Sicht nämlich zwei ganz unterschiedliche Paar Schuhe.

In den Fällen, in denen mit dem Escrow lediglich die kurz- bis mittelfristige Aufrechterhaltung des Betriebs angestrebt wird, kann ein Escrow durchaus Sinn machen. Nehmen wir mal einen beliebigen Cloud-Service, der in Deinem Unternehmen zur Anwendung kommt. Der Provider dieses SaaS schickt Dir die Nachricht, dass er nächsten Monat den Betrieb des SaaS einstellt. Nun hast Du aber sehr viel kritische Daten da drin, all deine Teams arbeiten mit dieser Anwendung. Du brauchst einfach Zeit zum Reagieren. Gerade in größeren Unternehmen kann solch eine Situation zu einem großen Risiko werden. Mit Quellcode und Dokumentation, die Du aufgrund des Software-Escrows erhältst, kannst Du Dir Zeit kaufen, um auf diese Situation angemessen zu reagieren.

„Mit Software-Escrows kannst du Dir Zeit kaufen.“

Wenn beispielsweise die Übergangsfrist von der Nachricht über die Einstellung bis zur tatsächlichen Einstellung des SaaS kurz ist, kannst Du mit einem Software-Escrow und der darauf beruhenden Herausgabe des Quellcodes, einen ordnungsgemäßen Transfer erreichen. Du kannst sagen „OK, mir ist bewusst, dass die Software nicht langfristig durch mich selbst betrieben werden kann, da sie alt oder minderwertig oder einfach zu komplex für den Eigenbetrieb ist. Du bist aber nicht gezwungen, ad hoc, z. B. innerhalb der nächsten 2 Wochen, eine Entscheidung über eine Alternative zu treffen, sondern kannst diese Entscheidung noch ein halbes Jahr hinauszögern. In diesem halben Jahr kannst Du einen geordneten Transfer sicherstellen.

Daniela: Für die kurzfristige Aufrechterhaltung des Betriebs ist also ein Escrow-Agreement das Mittel der Wahl?

Marcel: Naja, die Größe und Komplexität der Software spielen schon eine Rolle. Auch, wie die Software entstanden ist und weiterentwickelt wurde.   

Daniela: Dann lass uns doch mal einen Schritt zurück gehen und ein paar Grundlagen klären: Wie habe ich mir denn einen Quellcode vorzustellen?

Marcel: Selbst bei kleineren Anwendungen besteht der Quelltext aus Hunderten von Dateien, welche im Repository abgelegt sind. Diese Dateien beinhalten nicht nur den aktuellen Stand der Software, sondern bilden neben der aktuellen Version auch alle vormals aktuellen Versionen der Software ab. Der komplette Entwicklungsbaum ist im Quelltext dargestellt. Folglich kann man anhand des Quelltextes – je nach dessen Qualität – auch noch Jahre später zurückverfolgen, was wie entwickelt wurde. Die vielen Dateien gehören zusammen und bilden die Software ab. Mittels weiterer Programme wird aus den vielen Dateien die laufende Anwendung erzeugt. Je nach Größe gibt es nicht „nur“ Hunderte von Dateien, sondern eben Tausende.

Weiter werden Architektur und Aufbau des Quellcodes stark durch den Charakter der Anwendung beeinflusst. Häufig hast Du es nicht mit einer einzelnen Software zu tun, die Du einfach entpacken und installieren kannst, und los geht’s. Meistens handelt es sich um einen breiten Satz an unterschiedlichen Systemen, die zusammenarbeiten und ein Gesamtkonstrukt darstellen. Dies ist vergleichbar mit einem Auto. Das Auto ist nicht nur die Hülle aus Blech, da ist auch ein Motor, da sind die Reifen, das sind etliche kleine, einzelne Komponenten, welche zusammengehören und zusammen funktionieren. So kann man sich das, stark vereinfacht, auch bei Software vorstellen. 

Daniela: Und was muss ich konkret mit dem Quellcode machen, damit die Applikation weiterläuft?

Marcel: Prinzipiell ist da schon noch einiges zu tun. Erst muss man aus dem Quellcode die Software bauen und die Umgebung aufsetzen, in der sie laufen soll. Dann muss die Software richtig konfiguriert und mit den notwendigen Drittsystemen verbunden werden, auf die sie sich vielleicht verlässt.

Das Deployment, also die Bereitstellung der Software für die EndnutzerInnen, läuft heute oftmals über ein einen automatisierten Prozess, das sogenannte „CI/CD“, im Hintergrund.

Wenn man das alles korrekt und gut dokumentiert übergeben bekommt, und dabei keinerlei exotische Tools oder Technologien genutzt werden, dann kann eine Escrow-Vereinbarung funktionieren.

Daniela: Klingt nicht so einfach. Welchen Unterschied macht denn die Software-Architektur?

Marcel: Die Architektur der Software ist sehr relevant. Vergleicht man monolithische Software mit verteilten Anwendungen (oder auch Cloud-Native-Applikationen), dann wird es interessanterweise leichter sein, einen Monolithen zu starten und zu betreiben. Denn dort befindet sich alles in einer Box. Für die Inbetriebnahme musst Du nur diese eine Box starten.

„Ein Monolith ist einfacher zu starten und zu betreiben als verteilte Systeme“

Bei verteilten Architekturen ist das anders. Hier wird eine große Applikation in kleine Häppchen unterteilt. Diese Komponenten arbeiten miteinander, jede hat ihre spezifische Aufgabe und hat eine zuständige Person oder Team, an die Du Dich wenden kannst. Und jede muss gesondert gestartet werden. Zudem ist die moderne Anwendungslandschaft darauf ausgelegt, Logik nach außen zu verlagern. Das bedeutet, dass eine funktionsfähige Einzelkomponente ohne funktionierenden Kontext dem Unternehmen gar nicht weiterhilft. Nur im Zusammenspiel mit den notwendigen anderen Diensten ergibt sich dann die Gesamtapplikation, welche den Geschäftsprozess abdeckt.

Diese Interdependenzen zwischen Komponenten, teilweise von unterschiedlicher Teams oder Anbietern, machen den Betrieb von verteilten Services so viel aufwändiger. Zwar gibt es auch hier Automatisierungen, dennoch begibst Du Dich mit diesen Cloud-Native-Softwares in sehr viele Abhängigkeiten, die Du dann – im Falle des eigenständigen Weiterbetriebs – auch soweit verstehen musst, dass Du sie betreiben kannst. Daher ist der Betrieb von verteilten Anwendungen komplizierter als von Monolithen.

Dafür aber ist die Weiterentwicklung der verteilten Anwendungen einfacher bzw. eher möglich, als die eines Monolithen, gerade wenn letzterer eine alte, über Jahre gewachsene Software ist.

„Verteilte Anwendungen sind meist einfacher weiterzuentwickeln.“

Daniela: Was ist mit Größe und Komplexität. Welche Rolle spielen diese Faktoren bei der Aufrechterhaltung des Betriebs?

Marcel: Bei einem kleinen Start-up kann ein Escrow-Agreement Sinn ergeben, und zwar unabhängig von der Architektur, einfach weil die Anwendungen meist nicht so groß und über Jahre gewachsen ist. Dies dürfte sowohl für den Betrieb als auch die Weiterentwicklung gelten.

Daniela: Jetzt hast Du bereits ein Beispiel genannt, wo ein Escrow Sinn ergeben könnte, Wie sieht es denn bei einer größeren, aber modern entwickelten Softwares und deren Weiterentwicklung aus? Zum Beispiel Salesforce? Wäre hier ein Escrow mit dem Ziel der Weiterentwicklung sinnvoll machbar?

Marcel: So ziemlich unmöglich. Das ist eines der größten Softwareunternehmen des Planeten, das nicht ohne Grund Tausende von Entwicklern beschäftigt. Da ich dort nicht gearbeitet habe und deren Code nicht kenne, kann ich nur im Allgemeinen sagen: Auch Software-Stacks von Unternehmen der Cloud-Generation sind inzwischen über Jahre gewachsen und Salesforce ist inzwischen auch nicht mehr so jung. Es kann sein, dass sie theoretisch super-sauberen Code besitzen, der top gewartet ist, aber das ist in Anbetracht der breiten Code-Basis und der 25-jährigen Geschichte unwahrscheinlich.

Zudem hat Salesforce viele Software hinzugekauft. Dies spricht gerade bei Startups nicht notwendigerweise dafür, dass alles gut dokumentiert ist. Denn: Jungunternehmen stehen unter einem hohen, kurzfristigen Erfolgsdruck, ihre Produkte in Form eines MVPs an den Markt zu bringen. Hier herrscht meist auch im Code Unordnung bis Chaos.

Mein Eindruck von außen ist es zudem: Viele Großunternehmen integrieren ihre zugekauften Softwares nicht so tief, wie sie es technisch könnten und wie es für die NutzerInnen optimal wäre. Ich würde also bei Salesforce vermuten, dass dort die Code-Basis ein heterogener Flickenteppich von vielleicht 50 Unternehmen ist.

„Escrows für die digitalen Software-Riesen abzuschließen, macht für normale Unternehmen keinen Sinn.“

Ein Escrow-Vertrag für SAP oder Salesforce abzuschließen ist daher technisch nicht sinnvoll, denn die Einarbeitung in deren Code wäre für ein normales Unternehmen in kurzer Zeit ausgeschlossen. Ein Escrow ist aber in der Regel auch nicht nötig, denn es ist sehr unwahrscheinlich, dass diese Unternehmen Pleite gehen. Sie besitzen eine sehr große und inflexible Kundenbasis, sie könnten durch Preiserhöhungen kurzfristig ihre Liquiditätsengpässe auflösen. 

Daniela: Bei welcher Software bzw. welcher Art von Unternehmen ist denn eine Weiterentwicklung nach Herausgabe des Quellcodes realistisch?

Marcel: Wie oben schon erwähnt, kann ein Escrow Agreement bei einem kleinen (!) Start-up Sinn machen. Hier würde ich weniger nach dem Technologie-Stack gehen. Entscheidend ist für den Fall der Weiterentwicklung dann doch, wie gewachsen die Codebasis schon ist.

Was ich auch schon erlebt habe und für sinnvoll erachte, ist, Individualisierungen einer Standard-Software mit einem Escrow-Agreement abzusichern.  

Daniela: Wie sieht es bei einer Cloud-Native-SaaS-Lösung aus? Was ist hier speziell zu beachten?

Marcel: Was man schnell bei Cloud-Native-SaaS aus den Augen verliert, ist, dass solch eine Lösung oft aus anderen Lösungen zusammengestrickt ist. Im Hintergrund des SaaS läuft also Software von verschiedenen Drittanbietern, wie etwa AWS. Die sich daraus ergebenden Abhängigkeiten sind zu beachten. Hier müsste man eine Dependency Map aufsetzen, in der dann festgehalten ist, wer womit an welcher Stelle mit dem Software-Anbieter zusammenarbeitet.

Bei der Hinterlegung muss man dann nicht nur darauf achten, dass das kleine Stück Code des SaaS-Anbieters selbst hinterlegt wird. Man muss auch die Abhängigkeiten mit den Drittanbietern und den Umstand, dass Daten weiterer Kunden im SaaS bzw. beim Drittanbieter liegen, bedenken. Wenn Drittanbieter eingebunden werden, dann werden gewisse Systemkonfigurationen und Einstellungen vorgenommen. Hierzu müsste es eben auch eine Infrastruktur-Dokumentation geben, die vom Escrow erfasst wird. Es ist sehr viel, was berücksichtigt werden muss, und das müsste wiederum im Escrow sehr konkret dargestellt werden.

Daniela: Die Fälle, in denen Escrow Sinn ergibt, schmelzen dahin. Ich fasse mal als Zwischenstand zusammen: Aufrechterhaltung des Betriebs bei monolithischer Architektur ist leichter als bei verteilten Anwendungen. Aufrechterhaltung des Betriebs und Weiterentwicklung bei kleineren Start-ups kann mit Hilfe eines Escrows funktionieren. Die punktuelle Weiterentwicklung einer verteilten Software ist im Grundsatz leichter als die Weiterentwicklung eines Monolithen. Im Übrigen kommt es sehr auf die gewachsene Codebasis sowie die Dokumentation der fraglichen Software an. 

Dort, wo ein Escrow überhaupt noch sinnvoll erscheint, wie schätzt Du die Aufwände zur Einarbeitung in den Quellcode ein?

Marcel: Beim Betrieb kann ich auf das zurückgreifen, was da ist, ohne dass ich Aufwand in die Einarbeitung des Codes zur Entwicklung in neue Features investieren müsste. Wenn Probleme in der Software auftauchen, kann ich mit Bugfixes arbeiten. Die Probleme muss ich nicht unbedingt grundlegend reparieren. Dafür brauchst Du ein paar Leute, die das nötige Know-How haben. Das ist machbar, natürlich unter vorstehenden Einschränkungen wie gewachsene Codebasis einer sehr großen Software, Stichwort Salesforce, etc.

Bei der Weiterentwicklung hingegen gehört ein tieferes Verständnis darüber, was da eigentlich passiert, dazu. Das heißt, Du brauchst erstens mehr Zeit, und zweitens nicht nur Leute, die die Software betreiben können, sondern Du musst eine Produkt-Organisation für die Software aufbauen, Teams aufsetzen, die sich hinsetzen und verstehen, was da passiert.

„Vor Eintritt des Escrow-Falles, muss ich mich darum kümmern, dass der im Escrow hinterlegte Code auch funktioniert.“

In diesem Zusammenhang fallen mir noch weitere Aufwände ein, die ich für erforderlich oder zumindest für sehr nützlich halte. Man müsste schon im Vorhinein, also vor Eintritt des Escrow-Falles, einige Leute abstellen, die sicherstellen, dass das, was hinterlegt wird, auch läuft. Der Escrow-Agent beherbergt ja nur den Code und die Dokumentation. Doch das reicht alleine nicht, um ad hoc eine Anwendung zu installieren und zu betreiben. Alle Informationen, die zur Betriebsfähigkeit notwendig sind, müssten ebenfalls beim Escrow-Anbieter hinterlegt werden. Das kann umfangreich sein. Hierzu kann man auch auf einen externen Dienstleister zurückgreifen – so es diesen am Markt gibt.

Daniela: Gibt es Alternativen, gerade mit Blick auf kritische Anwendungen?

Marcel: Schwierig. Auf die großen Player setzen, da ist das Insolvenzrisiko nicht so hoch. Dann wäre es gut, sich eine Unterstützung durch die Entwickler des Software-Anbieters für eine Übergangsfrist zu sichern. Ob sich das vertraglich machen lässt, kann ich nicht beurteilen. Dann könnte man noch darüber nachdenken, sich vom Software-Anbieter eine dedizierte Landschaft auf eigener Infrastruktur aufsetzen zu lassen nach dem Vorbild etwa von DELOS. Und dann könnte man natürlich auf Open Source zurückgreifen.

Daniela: Vielen Dank für Deine Zeit!