Was ein T3-Motor mir über Legacy-Systeme beigebracht hat

Mein VW T3 ist Baujahr 1989. Der Motor — ein Saugdiesel mit der freundlichen Bezeichnung „1Y" oder, je nach Stimmung, „der Trecker" — leistet 70 PS auf einem guten Tag. Er hat keinen Computer, keine Lambdasonde, kein OBD. Er hat eine Einspritzpumpe, Wirbelkammern und das, was die Werkstattliteratur nüchtern „mechanische Robustheit" nennt. Wenn er nicht anspringt, liegt es an einer von vielleicht zwölf Dingen, und elf davon kann man mit einem Schraubenschlüssel der richtigen Größe und etwas Geduld klären.

Ich nenne diesen Motor hier nicht aus Nostalgie. Sondern weil er mir, jedes Mal wenn ich am Wochenende in der Garage darunterliege, dasselbe ins Ohr flüstert wie jeder Industriekunde, der mich Montag wieder anruft: Alt ist nicht kaputt. Alt ist nur alt.

Die Versuchung des großen Wurfs

In der Industrie-IT begegnet mir eine Erzählung in Endlosschleife. Sie geht so: „Das System ist von 2008. Wir müssen es ablösen." Auf der Folie steht „Modernisierung", in der Roadmap „Greenfield-Ansatz", und in der Excel daneben eine Zahl, die die Geschäftsführung kurz blass werden lässt, bevor sie nickt.

Dann sitzt man sechs Monate später im Workshop und stellt fest, dass das alte System Dinge tat, von denen niemand mehr wusste, dass es sie tat. Eine Plausibilitätsprüfung, die vor zwölf Jahren ein Praktikant in einer Nachtschicht eingebaut hat, weil ein Lieferant ständig kaputte Datensätze schickte. Ein Mapping, das einen historischen Sondernamen für ein Bauteil auf die heutige Klassifikation hebt. Eine Skript-Zeile, ohne die der ganze Wartungs-Report seit 2014 nicht stimmen würde.

Das alte System war nicht schlecht. Es war nur unsichtbar geworden — weil es funktionierte.

Was der Motor anders macht

Wenn am T3-Diesel etwas nicht stimmt, frage ich mich nicht zuerst, ob ich einen neuen Motor brauche. Ich frage, welcher Teil nicht stimmt. Glühkerzen? Förderbeginn der Pumpe? Verstopfter Vorfilter? Jeder dieser Teile ist ersetzbar, einzeln, ohne dass ich den Rest des Fahrzeugs anfasse. Niemand würde ernsthaft vorschlagen, wegen eines Förderbeginns von zwei Grad zu früh einen neuen Bus zu kaufen.

In der IT machen wir genau das routinemäßig. Eine Anwendung ist langsam geworden — also bauen wir sie neu. Ein Modul ist schwer zu verstehen — also schreiben wir das System um. Eine Schnittstelle macht Ärger — also wechseln wir das gesamte Backend. Es ist, als ob man wegen einer schiefen Spurstange das ganze Auto verschrottet.

Der Unterschied liegt nicht in der Technik. Er liegt in der Haltung. Wer am Bulli schraubt, geht davon aus, dass das Fahrzeug grundsätzlich in Ordnung ist und ein konkretes Problem hat. Wer in der IT „Modernisierung" hört, geht davon aus, dass das System grundsätzlich verloren ist und nur abgelöst werden kann. Beides ist meist falsch — aber die zweite Annahme ist deutlich teurer.

Drei Symptome, die ich gelernt habe zu lesen

Mit der Zeit bekommt man ein Ohr dafür, wann ein System wirklich am Ende ist und wann nur die Vorschriftsmäßigkeit nachlässt. Drei Symptome, an denen ich meistens unterscheide:

1. Niemand traut sich mehr ran.

Das ist das schlimmste Symptom — und es gilt für Diesel-Einspritzpumpen genauso wie für SAP-Schnittstellen. Wenn jeder im Team einen Bogen um ein Modul macht, weil „beim letzten Mal alles kaputtging", dann ist nicht das Modul das Problem, sondern das Vertrauen. Reparieren heißt hier: Dokumentation neu schreiben, einen Testlauf einrichten, jemanden bezahlen, der das Ding ein Wochenende ruhig durchgeht. Das kostet weniger als jede Neuentwicklung — aber niemand bekommt einen Award dafür.

2. Die Werkzeuge passen nicht mehr.

Wenn ich für meinen T3 einen Spezial-Abzieher brauche, den es nirgendwo mehr zu kaufen gibt, dann ist das ein echtes Problem — aber ein lösbares. Bei Software heißt das gleiche: Die Build-Chain läuft nur noch auf einer alten Maschine. Der Compiler ist abgekündigt. Die letzte Person, die die Konfiguration verstanden hat, ist in Rente. Auch das ist kein Grund, das System abzulösen. Es ist ein Grund, einmal in die Werkzeugkette zu investieren, statt jährlich in Workarounds.

3. Die Anforderungen haben das System überholt.

Das ist der einzige der drei Punkte, der wirklich für einen Neubau spricht. Wenn das System konzeptionell etwas leisten soll, wofür es nicht entworfen wurde — Echtzeit statt Batch, multi-mandantenfähig statt mono, Web statt Client — dann hilft Reparatur nicht. Aber dieser Fall ist deutlich seltener, als die meisten Modernisierungs-Folien suggerieren. In neun von zehn Fällen lautet die ehrliche Antwort: „Wir wollen es schöner. Wir brauchen es nicht anders."

Was bleibt vom Vergleich

Ich bin kein Romantiker. Manchmal ist ein System am Ende. Manchmal hilft nur ein neuer Motor — oder zumindest ein gründlich überholter, mit neuen Kolbenringen, frischer Pumpe und einem ehrlichen Testlauf an der Bremse. Aber dieser Schritt verdient eine eigene Entscheidung. Er sollte nicht das Reflex-Vorgehen sein, sobald jemand das Wort „Legacy" in den Mund nimmt.

Was der T3 mir beigebracht hat, ist eine bestimmte Reihenfolge des Fragens. Bevor ich etwas wegwerfe, will ich wissen, was es tut. Bevor ich es ersetze, will ich wissen, was an seine Stelle treten soll und warum. Und bevor ich „Modernisierung" sage, will ich verstehen, was am Alten konkret schmerzt — nicht im Datenblatt, sondern am Montagmorgen um halb neun, wenn die Anlage anfährt.

Das ist keine Anti-Innovations-Haltung. Es ist die Haltung von jemandem, der schon mal mit ölverschmierten Händen unter einem Fahrzeug lag und festgestellt hat: Das Teure ist meistens nicht das Teil. Das Teure ist die ungeprüfte Annahme, dass es das Teil sein muss.