Wie wir ein 30 Jahre altes Wartungssystem neu aufgebaut haben, ohne das alte anzuhalten

Wer unser Kunde ist und an wen er verkauft

Unser Kunde ist ein Softwareunternehmen mit Sitz in der EU. Sein Produkt wird von Werken und Industriegruppen gekauft, und seit den 1990er-Jahren ist es das System, mit dem diese Betriebe ihre Anlagen instand halten.

Stellen Sie sich ein Werk mit zweihundert Maschinen vor. Bei der einen ist alle fünfhundert Betriebsstunden ein Ölwechsel fällig. Die nächste steht zur vierteljährlichen Prüfung an. Eine dritte hängt an einem Ersatzteil, das im Regal liegen muss, bevor sie ausfällt. Wird eines davon übersehen, steht mitten in der Schicht eine Linie still. Genau das verhindert das Produkt unseres Kunden: Es hält die Struktur von Hallen, Linien und Maschinen, plant die wiederkehrenden Arbeiten, stellt die Arbeitsaufträge aus, nach denen die Techniker arbeiten, verwaltet Ersatzteile und liest die Zählerstände — Betriebsstunden, Kilometer —, an denen hängt, wann eine Arbeit fällig wird.

Die Werke, die es kaufen, reichen vom einzelnen Standort bis zu Industriegruppen mit mehreren Gesellschaften unter einem Dach.

Die Frage, die in Verkaufsgesprächen immer wiederkam

Das ältere Produkt ist eine Windows-Desktop-Anwendung, in Delphi auf MS SQL geschrieben und auf einem Server in jedem Werk installiert. Diese Form passte zu der Zeit, in der sie gewählt wurde, und sie bestimmt, wie das Produkt zum Käufer kommt: Um es jemandem zu zeigen, schickt man eine ausführbare Datei, die jemand installiert. Ein neues Werk bedeutet eine weitere Installation und eine weitere Datenbank, um die man sich kümmern muss. Eine neue Version bedeutet eine Datei, die jeden Rechner erreichen muss, auf dem das Produkt läuft.

Als wir uns kennenlernten, hatte sich diese Rechnung längst gegen sie gedreht. Käufer fragten nach einer Browser-Version, und es gab keine zu zeigen. Ein großer Interessent machte deutlich, dass eine Browser-Version Bedingung ist — damit hatte das Problem ein Datum. Ein Neuschreiben innerhalb der alten Technologie hätte Jahre der Kapazität des internen Teams gekostet, während dieselbe Frage in Verkaufsgesprächen weiter aufgetaucht wäre. Und das Verständnis dafür, wie das Ganze zusammenhängt, lag bei den Leuten, die am längsten dabei waren.

Wir haben dreißig Jahre Code gelesen, bevor wir eine eigene Zeile schrieben

Bevor wir irgendetwas entworfen haben, haben wir dokumentiert, was bereits existierte. Wir haben KI-Werkzeuge über den alten Quellcode laufen lassen und ein internes Wiki des Produkts erzeugt: jedes Modul und jede Tabelle, was sie tut, warum es sie gibt und die genaue Stelle im Code, die das belegt. Aus dreißig Jahren Entscheidungen wurde etwas, das eine neue Person an einem Nachmittag lesen kann.

Danach haben wir uns mit den Inhabern zusammengesetzt und stundenlang das reale Produkt durchgesprochen. Genau dort sind wir auf etwas gestoßen, das festzuhalten lohnt. Beide Seiten benutzten die Wörter Firma, Abteilung, Standort und Kunde in unterschiedlicher Bedeutung, und in den Calls sorgte das bereits für Verwirrung. Der Kunde bot an, ein gemeinsames Glossar zu schreiben, mit Beispielkonstellationen von der einfachsten bis zur verschachteltsten. Wir hatten es in der Hand, bevor das Datenmodell feststand, und es hat uns Umwege erspart, deren Korrektur teuer geworden wäre.

Was wir gebaut haben, damit sie es verkaufen können

Eine Web-Plattform, die dieselbe Instandhaltungsarbeit trägt, für die das alte Produkt geschätzt wurde: Anlagenstrukturen, Definitionen von Arbeiten, wiederkehrende und einmalige Aufgaben, Arbeitsaufträge und Berichte. Die Entscheidungen, auf die es den Inhabern ankam:

• Eine Codebasis, zwei Betriebsarten. Die Plattform läuft als Cloud-Dienst oder auf dem eigenen Server eines Werks — Käufer, deren Regeln die Daten im Haus halten, behalten sie im Haus.

• Die Daten jedes Werks liegen auf Datenbankebene getrennt. Das war das Erste, wonach die Inhaber gefragt haben. Bei den Verträgen, die ihre Käufer heute unterschreiben, ist ein Datenleck das Ereignis, von dem sich ein Unternehmen ihrer Größe nicht erholt — die Architektur musste darauf antworten, bevor sie auf irgendetwas anderes antwortete.

• Das Anlegen neuer Kunden ist in eine Admin-Konsole gewandert. Ein neues Werk einzurichten dauert wenige Minuten und erfordert keine Installation. Früher hieß das, einen Server aufzusetzen.

• Der Quellcode liegt beim Kunden selbst, mit vollem Zugriff auf Repository und Historie und ohne Lizenz auf unserer Seite.

• Die Arbeit wurde in kleinen Paketen geschätzt, vorab freigegeben und erst nach der Lieferung abgerechnet.

Ihr internes Delphi-Team ist geblieben. Wir haben mit ihm Arbeitssessions zur KI-gestützten Entwicklung gemacht, und heute kommt es im alten Produkt schneller voran, während die neue Plattform daneben wächst. Diese Zusammenarbeit hat dem Team zugleich geholfen, dem älteren Produkt mit mehr Sicherheit zu begegnen.

Der Entwickler dahinter war einen Anruf entfernt

Die Plattform wurde von Aleksey Andruschenko geführt, unserem Senior Developer, mit dem übrigen Team an seiner Seite. Die Inhaber mussten keine Frage über Zwischenstationen schicken. Wenn etwas an ihrem Geschäft unklar war, riefen sie Aleksey an und klärten es im selben Gespräch.

Dieser Zugang ist so viel wert wie das, was er selbst eingebracht hat. Aleksey ist tief in das Geschäft des Kunden eingestiegen: wie ein Werk aufgebaut ist, was ein Instandhaltungsplaner an einem Dienstagmorgen tut, auf welche Teile des alten Produkts die Werke nie verzichten würden. Tief genug, um bei einer Anforderung zu widersprechen, wenn sie dem Produkt nicht gedient hätte, das unser Kunde verkaufen muss. Entscheidungen, die sonst auf den nächsten Zyklus gewartet hätten, fielen direkt im Gespräch.

Was sich für das Geschäft geändert hat

• 3 Wochen von der freigegebenen Architektur bis zur ersten funktionierenden Version des Kern-Workflows, live am Bildschirm gezeigt.

• 78 erfasste Änderungen in einem einzigen freigegebenen Arbeitspaket geliefert, im Rahmen der Schätzung.

• Das interne Team des Kunden blieb auf dem Altprodukt, während die neue Plattform daneben entstand.

• Ein neues Werk einzurichten ging von der Installation eines eigenen Servers samt Datenbank auf das Anlegen eines Kontos in der Konsole zurück — in Minuten.

• Die laufenden Cloud-Kosten für die gesamte Plattform liegen im unteren dreistelligen Euro-Bereich pro Monat.

• Das alte Produkt blieb durchgehend im Einsatz, und kein Werk wurde umgezogen, bevor es so weit war.

Wo wir den Kurs korrigiert haben

Während wir die erste Version formten, hat uns der Kunde dabei geholfen, das Produkt an der Arbeitsrealität der meisten seiner Kunden auszurichten. Wir hatten damit begonnen, uns die kompliziertesten Konstellationen im Bestand genau anzusehen, weil sich Fehler dort am schwersten korrigieren lassen. Die Inhaber holten die Diskussion zum Normalfall zurück: Die meisten Werke, an die sie verkaufen, haben einen einzigen Standort, und die erste Version musste einfach genug bleiben, damit diese Kunden sie ohne Reibung einrichten und benutzen können. Die verschachtelte Struktur blieb im Plan, wanderte aber aus dem Fundament heraus. Diese Entscheidung hat das Produkt leichter verkäuflich und leichter einführbar gemacht.

Mit dem steigenden Tempo haben wir außerdem den Lieferrhythmus angepasst. Schnelle Iterationen gaben dem Kunden früh funktionierende Screens, machten es aber ebenso wichtig, die Qualität zwischen den Releases zu schützen. Deshalb haben wir jedem Zyklus einen Stabilisierungstag hinzugefügt — manuelle Prüfung, Aufräumen und automatisierte Tests — und ihn zu einem festen Teil jedes Pakets gemacht statt zu etwas, das am Ende erledigt wird.

Wird Ihr Produkt von der Technologie gebremst, in der es entstanden ist?

Das Muster hinter diesem Fall ist bei etablierten Softwareprodukten verbreitet. Das Geschäft wächst, die Erwartungen der Kunden ändern sich, und die ursprüngliche Technologie beginnt zu begrenzen, was das Produkt als Nächstes kann. An diesem Punkt lautet die Frage nicht, ob das interne Team fähig ist. Sie lautet, ob das die beste Verwendung seiner Zeit ist.

Aus unserer Sicht sollten starke interne Teams bei dem Produktwissen bleiben, das nur sie haben: die Kunden, die Abläufe, die Sonderfälle, all das, was das Produkt wertvoll macht. Wenn der nächste Schritt einen anderen Technologie-Stack verlangt, kann ein externes Team diesen Teil der Arbeit tragen, während die eigenen Leute nah am Produkt bleiben und das bestehende System am Laufen halten.

Wenn Ihr Produkt an diesem Punkt steht, holen Sie sich ein Team dazu, das mit den Technologien Ihrer nächsten Version bereits gearbeitet hat. Sehen Sie, wie wir an Legacy-Modernisierung und an die Entwicklung individueller Web-Plattformen herangehen, oder buchen Sie ein Gespräch mit uns.

Diese Bilder wurden angepasst, um die NDA des Kunden einzuhalten. Die Software-Oberfläche bleibt unverändert.