Software übernehmen, wenn der Entwickler weg ist: die ersten Schritte

Eine Anwendung läuft seit Jahren. Sie bildet einen Prozess ab, auf den sich im Betrieb alle verlassen, vielleicht die Auftragsabwicklung, vielleicht die Planung. Gebaut hat sie jemand, der nicht mehr da ist. Der Entwickler hat das Unternehmen verlassen, der Dienstleister hat keine Kapazität mehr, oder die Zusammenarbeit hat schlicht geendet.

Solange alles läuft, fällt das kaum auf. Spätestens bei der ersten Störung oder dem ersten Änderungswunsch stellt sich die Frage, wer sich jetzt darum kümmert. Und schnell steht der Gedanke im Raum, das Ganze neu zu machen.

Das kann am Ende die richtige Entscheidung sein. Als erster Schritt kommt sie meist zu früh.

Was zuerst gesichert werden sollte

Bevor jemand über Neubau oder Weiterentwicklung entscheidet, sollte gesichert sein, was da ist. Die folgenden Punkte sind eine Orientierung. Was zuerst kommt, hängt von der Lage ab. Läuft ein Serververtrag aus oder gibt es keine aktuelle Sicherung der Daten, hat das Vorrang.

Quellcode und Zugänge. Wo liegt der Code? Gibt es ein Repository, auf das Ihr Unternehmen selbst Zugriff hat, oder liegt er nur beim bisherigen Entwickler? Wer kennt die Zugänge zu Server, Datenbank, Domain und den angebundenen Diensten? Solange all das erreichbar ist, kostet das Sichern wenig. Ist ein Zugang erst verloren, wird es aufwendig und manchmal unmöglich.

Betrieb und Sicherungen. Wo läuft die Anwendung, wer bezahlt den Server, und wann läuft welcher Vertrag aus? Gibt es Sicherungen der Daten, und hat schon einmal jemand ausprobiert, ob sie sich zurückspielen lassen?

Wissen im Betrieb. Wer arbeitet täglich mit der Anwendung? Wer kennt die Sonderfälle und weiß, warum ein bestimmter Schritt so ist, wie er ist? Ist der bisherige Entwickler noch erreichbar, lohnt sich ein Gespräch mit ihm, selbst wenn es nur eine Stunde dauert.

Das müssen Sie nicht alles allein zusammentragen, bevor Sie jemanden dazuholen. Wer die Anwendung übernehmen soll, kann beim Sichten und Sichern helfen und sieht schneller, was fehlt und was dringend ist. Gerade wenn Unterlagen fehlen, lohnt es sich, früh jemanden dazuzuholen.

Warum der Code allein nicht reicht

Von außen wirkt so eine Anwendung oft chaotisch. Unklare Namen, Ausnahmen an seltsamen Stellen, Teile, die niemand mehr anfassen will. Mit etwas Kontext sieht es meist anders aus. Hinter vielen Ausnahmen steckt ein Sonderfall, der irgendwann aufgetreten ist, eine Regel für einen bestimmten Kunden oder eine Abhängigkeit zu einem anderen Ablauf. Jemand hat das einmal bewusst so gebaut.

Was davon weder aufgeschrieben noch an jemand anderen weitergegeben wurde, ist mit dem Entwickler gegangen. Der Code zeigt, was passiert, aber selten warum. Eine Übernahme beginnt deshalb mit Verstehen: über den Code, die Daten und Gespräche mit den Menschen, die täglich mit der Anwendung arbeiten. Sie wissen über die Sonderfälle oft mehr als jede Dokumentation.

Das ist auch das Risiko eines schnellen Neubaus. Die sichtbaren Funktionen lassen sich nachbauen. Die Sonderfälle, die das alte System still abgefangen hat, fallen oft erst im neuen auf, als Fehler. Weiterbetreiben ist trotzdem nicht automatisch richtig. Wann ein Umbau oder Neubau die bessere Antwort sein kann, beschreibe ich im Artikel Wann sollte man Legacy-Software modernisieren?.

Was eine erste Einschätzung klärt

Dass eine Anwendung seit Jahren im Einsatz ist, spricht dafür, dass sie Abläufe abbildet, auf die sich der Betrieb verlässt. Ob sie sicher ist, ob sie sich gut ändern lässt und ob sie sich nach einem Ausfall wiederherstellen ließe, sagt das nicht. Das klärt eine erste technische Einschätzung, etwa mit diesen Fragen:

  • Ist der Code vollständig, und lässt sich die Anwendung daraus neu aufsetzen?
  • Welche Komponenten bekommen keine Sicherheitsupdates mehr?
  • Wie sind Zugriffe geregelt, und wer kann was sehen oder ändern?
  • Lassen sich Anwendung und Daten aus den vorhandenen Sicherungen wiederherstellen?
  • Wo fehlen Tests oder Wissen, um Änderungen verlässlich zu prüfen?
  • Was ist dringend, und was kann warten?

Erst danach lässt sich sagen, ob die Anwendung vorerst so weiterlaufen kann oder ob etwas zu tun ist.

Damit das Wissen nicht wieder in einem Kopf liegt

Wer eine Anwendung übernimmt, läuft in eine naheliegende Falle. Er arbeitet sich ein, versteht das System, behebt Fehler, setzt Änderungen um. Und nach einem Jahr liegt das Wissen wieder bei einer einzigen Person. Diesmal bei ihm. Dann ist die Abhängigkeit nur verschoben.

Achten Sie deshalb von Anfang an darauf, dass festgehalten wird, was bei der Einarbeitung herauskommt: warum ein Teil so gebaut ist, welche Sonderfälle es gibt, wo die Grenzen der Lösung liegen. Das macht niemanden beliebig ersetzbar. Aber es erleichtert die nächste Übergabe und hilft schon im Alltag, wenn eine Frage auftaucht und der Betreuer gerade nicht erreichbar ist.

Wenn Sie gerade in dieser Lage sind, helfe ich beim Sichten und Sichern, arbeite mich in die Anwendung ein und sage Ihnen, was solide ist, wo Risiken liegen und was als Nächstes sinnvoll ist. Mehr dazu unter Bestehende Software betreuen.

Projekt besprechen