Ich verdiene mein Geld damit, alte Systeme wieder änderbar zu machen. Und in einem Teil der Erstgespräche sage ich am Ende: Lassen Sie das. Nicht, weil das System zu schlecht wäre, sondern weil Modernisieren die Antwort auf eine Frage ist, die in diesem Fall gar nicht gestellt wurde.
Die Debatte um Altsysteme läuft fast immer zwischen zwei Lagern. Die einen wollen modernisieren, Schritt für Schritt, bei laufendem Betrieb. Die anderen wollen neu bauen. Beide Seiten streiten darüber, wie das System weiterlebt. Dass es vielleicht gar nicht weiterleben sollte, kommt selten auf den Tisch.
Dieser Artikel ist über die Fälle, in denen genau das die richtige Antwort ist. Er kommt von jemandem, der am Gegenteil verdient, und das sollten Sie beim Lesen im Kopf behalten. Ich habe versucht, das zu meinem Vorteil zu nutzen: Die Kriterien unten sind die, nach denen ich selbst entscheide, ob ich ein Vorhaben annehme.
Vier Ausgänge, nicht zwei
Ein Altsystem, über das jemand nachdenkt, hat vier mögliche Ausgänge, und nur einer davon ist mein Geschäft.
Modernisieren. Das System bleibt, wird aber Stück für Stück in einen Zustand gebracht, in dem Änderungen wieder planbar sind. Es ist die richtige Antwort, wenn das System etwas tut, das Sie brauchen, das kein Produkt von der Stange tut, und das Sie in fünf Jahren noch brauchen.
Einfrieren. Das System bleibt, bekommt aber keine neuen Funktionen mehr. Es wird abgesichert, isoliert und mit einem Enddatum versehen. Das ist die richtige Antwort, wenn die Restlaufzeit absehbar ist und kürzer als jede Modernisierung.
Durch Standardsoftware ersetzen. Das System wird abgelöst durch ein Produkt, das ein Anbieter für tausend andere Unternehmen betreibt. Richtig, wenn das, was das System tut, Sie nicht von Ihrem Wettbewerb unterscheidet.
Abschalten. Das System hört auf zu existieren, seine Daten wandern in ein Archiv. Richtig, wenn niemand mehr davon abhängt, und das kommt häufiger vor, als die Beteiligten glauben.
Der Neubau taucht in dieser Liste nicht auf, und das ist Absicht. Ein Neubau ist keine eigene Antwort auf die Frage, was aus dem System werden soll. Er ist eine Art, zu modernisieren, und zwar die riskanteste; warum, steht in einem eigenen Artikel. Wer die Frage „Modernisieren oder Neubau" stellt, hat die eigentliche Entscheidung schon getroffen, ohne sie zu bemerken: dass das System weiterleben soll.
Die Frage, die vor allen anderen kommt
Vor der Technik, vor dem Budget, vor der Frage nach dem Team steht eine einzige Frage: Was tut dieses System für Ihr Geschäft, das kein anderes System genauso tun könnte?
Die Antwort sortiert alles weitere. Ein System, das Rechnungen schreibt, Urlaubstage zählt oder Bestellungen an ein Lager weitergibt, tut etwas, das hunderttausend andere Unternehmen auch tun. Diese Funktion unterscheidet Sie von niemandem. Sie muss laufen, sie darf nichts kosten, und sie ist kein Grund, ein eigenes System zu unterhalten.
Ein System, das Ihr Preismodell abbildet, das kein Wettbewerber hat, Ihre Lieferlogik, mit der Sie schneller sind als der Markt, oder eine Redaktionsplattform, um die herum ein Verlag zwanzig Jahre lang seine Arbeitsweise gebaut hat, tut etwas anderes. Es ist der Grund, warum Kunden bei Ihnen kaufen. Solche Systeme lohnen die Modernisierung, weil ihr Wert nicht im Code steckt, sondern in dem, was der Code weiß.
Ein Test, der in der Praxis erstaunlich gut trägt: Wenn dieses System morgen durch ein Produkt von der Stange ersetzt würde, welcher Ihrer Kunden würde es merken? Wenn Ihnen kein Kunde einfällt, sondern nur Kollegen, die sich umgewöhnen müssten, haben Sie ein Commodity-System. Dann ist die Frage nicht, wie Sie es modernisieren, sondern warum Sie es überhaupt noch betreiben.
Die unangenehme Wahrheit dabei: Die meisten Systeme, die als „geschäftskritisch" bezeichnet werden, sind kritisch im Sinne von „darf nicht ausfallen", nicht im Sinne von „unterscheidet uns". Beides fühlt sich von innen gleich an. Von außen ist es der Unterschied zwischen Modernisieren und Ersetzen.
Einfrieren: wenn das System ausläuft, bevor es gefährlich wird
Es gibt Systeme, deren Ende schon feststeht. Die Produktlinie, die sie abrechnen, läuft aus. Der Vertrag, den sie verwalten, endet in drei Jahren. Das Unternehmen wird übernommen, und der Käufer bringt seine eigene Plattform mit. In solchen Fällen ist jede Modernisierung Geld, das in ein Auslaufmodell fließt.
Die Alternative heißt Einfrieren, und sie wird regelmäßig missverstanden. Einfrieren heißt nicht, nichts mehr zu tun. Es heißt, eine ganz bestimmte Menge an Dingen zu tun und alles andere zu unterlassen:
- Keine neuen Funktionen. Das ist der Kern und der Teil, der am schwersten durchzuhalten ist, weil der Wunsch nach „nur einer kleinen Änderung" nicht aufhört, nur weil das System ein Enddatum hat.
- Sicherheitsaktualisierungen ja. Ein eingefrorenes System steht weiter im Netz. Die Laufzeitumgebung wird gepflegt, bekannte Lücken werden geschlossen. Was nicht mehr gepflegt werden kann, weil die Version ihr End of Life erreicht hat, wird isoliert. Zend Framework 1 ist so ein Fall: seit 2016 ohne Support und in vielen Häusern noch im Betrieb.
- Isolieren. Das System bekommt so wenig Netzzugang wie möglich, so wenige Zugänge wie möglich, und es hängt nicht mehr an anderen Systemen, die weiterleben sollen. Ein eingefrorenes System darf beim Ausfall nichts mitreißen.
- Ein Datum und eine Person. Wann wird es abgeschaltet, und wer trägt die Verantwortung bis dahin. Ohne beides ist es nicht eingefroren, sondern nur verlassen.
Der letzte Punkt ist der, an dem sich Einfrieren von Vernachlässigen unterscheidet, und in der Praxis ist der Unterschied oft nur eine Behauptung. Ein System, um das sich seit Jahren niemand kümmert, wird gern rückwirkend als „eingefroren" bezeichnet. Es ist keins. Einfrieren ist eine Entscheidung mit Datum. Vernachlässigung ist das Fehlen einer Entscheidung, und sie kommt ohne Datum, ohne Isolation und ohne Sicherheitsaktualisierungen.
Wenn Sie ein System einfrieren, schreiben Sie das Datum in einen Kalender, der jemandem gehört. Nicht in ein Dokument.
Standardsoftware: der Preis ist nicht die Lizenz
Wenn die Frage aus dem zweiten Abschnitt ergibt, dass Ihr System nichts tut, was Sie unterscheidet, ist ein Produkt vom Markt meist die günstigere Antwort. Ein Anbieter, der dieselbe Funktion für tausend Kunden betreibt, macht das billiger, sicherer und mit weniger Ausfällen als jedes einzelne Unternehmen es für sich selbst könnte.
Wo dieser Weg scheitert, ist fast immer dieselbe Stelle: die zwanzig Prozent, für die das alte System einmal gebaut wurde. Das Standardprodukt kann achtzig Prozent von dem, was Ihres kann. Die restlichen zwanzig sind die Eigenheiten, die Sonderfälle, die Ausnahme für den einen Großkunden. Genau die haben vor fünfzehn Jahren dazu geführt, dass jemand ein eigenes System gebaut hat, statt eins zu kaufen.
An dieser Stelle gibt es zwei Wege, und nur einer davon ist ein Ersatz.
Der erste: Sie passen Ihren Prozess an das Produkt an. Das ist billig, es tut weh, und es ist der einzige Weg, bei dem Sie am Ende wirklich Standardsoftware betreiben. Die zwanzig Prozent werden zum Teil aufgegeben, zum Teil außerhalb des Systems gelöst, zum Teil stellt sich heraus, dass sie niemand mehr braucht.
Der zweite: Sie passen das Produkt an Ihren Prozess an. Erweiterungen, Anpassungen, eigene Module, ein Dienstleister, der das Produkt „auf Sie zuschneidet". Das ist teuer, es tut zunächst nicht weh, und in drei Jahren haben Sie wieder ein Altsystem. Nur eins, das Ihnen nicht gehört: Jedes Update des Anbieters wird zur Frage, ob Ihre Anpassungen überleben, und die Person, die sie gebaut hat, ist dann vielleicht schon nicht mehr da.
Die Regel, die ich daraus ziehe: Was Sie am Produkt anpassen, ist Ihr nächstes Altsystem. Standardsoftware kaufen heißt, den eigenen Prozess zu ändern. Wer dazu nicht bereit ist, sollte nicht kaufen, sondern die erste Frage noch einmal stellen: Vielleicht sind die zwanzig Prozent ja doch das, was Sie unterscheidet. Dann gehört das System modernisiert, nicht ersetzt.
Abschalten: der Ausgang, den niemand vorschlägt
Von den vier Ausgängen ist das Abschalten der, der in Gesprächen am seltensten vorkommt, und dafür gibt es drei Gründe, die alle nichts mit dem System zu tun haben.
Erstens verdient niemand daran. Der Dienstleister nicht, der Softwareanbieter nicht, das interne Team nicht. Zweitens hat das Team Angst: Es kennt das System, seine Arbeit hängt daran, und Abschalten klingt nach einem Urteil über die Jahre davor. Drittens weiß niemand genau, was noch daran hängt, und die Sorge, etwas Unbekanntes mit abzuschalten, wiegt schwerer als die bekannten Kosten des Weiterbetriebs.
Der dritte Grund ist der einzige technische, und er lässt sich auflösen. Die Frage „braucht das noch jemand" muss nicht geschätzt werden. Sie lässt sich messen:
- Zugriffsprotokolle der letzten neunzig Tage. Wer meldet sich an, wie oft, und was tut er dann. Bei Systemen, die als unverzichtbar gelten, ist diese Liste erfahrungsgemäß kürzer, als alle erwarten. Manchmal steht darauf nur der eine Kollege, der monatlich einen Bericht exportiert.
- Was von außen darauf zugreift. Schnittstellen, geplante Abfragen, Skripte, die ein anderes System füttern. Das sind die Abhängigkeiten, die beim Abschalten wirklich wehtun, und sie stehen ebenfalls in den Protokollen.
- Welche Berichte gelesen werden. Ein System, dessen einziger Zweck ein Bericht ist, den seit zwei Jahren niemand öffnet, hat seinen Zweck verloren. Das ist keine Vermutung, das steht im Zugriffsprotokoll des Berichts.
Wenn die Messung nahelegt, dass niemand mehr davon abhängt, folgt kein Stecker, sondern eine Reihenfolge. Erst wird das System auf Nur-Lesen gestellt: Wer etwas ändern will, bekommt eine Meldung und einen Ansprechpartner. Dann bleibt es einige Wochen so, und in dieser Zeit meldet sich, wer es wirklich braucht. Erst dann wird es abgeschaltet, und die Daten wandern dorthin, wo sie hingehören.
Dieser letzte Punkt ist wichtiger, als er klingt. Aufbewahrungspflichten, etwa für Geschäftsunterlagen, sind ein häufiges Argument gegen das Abschalten. Sie sind fast immer ein Argument für ein Archiv, nicht für einen Betrieb. Dass Daten lesbar bleiben müssen, heißt nicht, dass die Anwendung laufen muss, die sie einmal erzeugt hat. Ein Export in ein Format, das in zehn Jahren noch jemand öffnen kann, erfüllt diesen Zweck besser als ein Server, den in zehn Jahren niemand mehr starten kann. Welche Fristen für Sie gelten und was genau aufzubewahren ist, klären Sie mit Ihrem Steuerberater; das hier ist keine Rechtsberatung, sondern der Hinweis, dass die Frage „läuft es noch" und die Frage „ist es noch da" zwei verschiedene sind.
Wann Modernisieren doch die richtige Antwort ist
Damit dieser Artikel nicht als „schalten Sie alles ab" gelesen wird: Es gibt eine klare Menge von Fällen, in denen Modernisieren die einzige vernünftige Antwort ist, und sie ist nicht klein.
Das System tut etwas, das Sie unterscheidet, und Sie brauchen es in fünf Jahren noch. Es lässt sich nicht kaufen, weil kein Anbieter Ihre Logik kennt. Und es lebt: Es gibt Leute, die damit arbeiten, Kunden, die davon abhängen, ein Geschäft, das wächst. Die Redaktionsplattform, die ein Verlag über zwanzig Jahre um seine Arbeitsweise herum gebaut hat, ist so ein Fall, und sie wurde modernisiert, nicht ersetzt; der Fall steht auf der Seite zur Legacy-Modernisierung.
Dass ein System alt ist, ist übrigens kein Argument gegen es. Alter Legacy Code, der seit fünfzehn Jahren jeden Tag Geld verdient, hat fünfzehn Jahre Kontakt mit der Wirklichkeit hinter sich. Das ist ein Wert, keine Last. Was ihn zur Last macht, ist nicht sein Alter, sondern der Zustand, in dem niemand mehr wagt, ihn anzufassen. Und genau dieser Zustand lässt sich beheben, ohne ihn wegzuwerfen: Stück für Stück, jedes einzeln produktiv, das alte System schrumpft, während das neue wächst. Das Muster heißt Strangler Fig, und es ist der Unterschied zwischen einer Modernisierung und einem Neubau, der sich Modernisierung nennt.
Was Modernisieren nicht ist: die Voreinstellung. Es ist einer von vier Ausgängen, und er sollte gewählt werden, weil die Fragen unten dorthin führen. Nicht, weil es der einzige ist, den jemand angeboten hat.
Vier Fragen, die die Entscheidung tragen
Wenn ich ein System ansehe, laufen die Kriterien aus den Abschnitten oben auf vier Fragen hinaus. Sie lassen sich in einer Stunde beantworten, wenn die Leute im Raum sind, die es wissen.
Erstens: Unterscheidet es uns? Würde ein Kunde merken, wenn es durch ein Produkt von der Stange ersetzt wäre? Nein: kaufen oder abschalten. Ja: modernisieren oder einfrieren.
Zweitens: Wie lange brauchen wir es noch? Steht ein Ende fest, das näher liegt als jede Modernisierung? Ja: einfrieren, mit Datum. Nein: die anderen drei.
Drittens: Wer nutzt es, gemessen? Nicht wer es angeblich braucht, sondern wer sich in den letzten neunzig Tagen angemeldet hat und was von außen darauf zugreift. Fast niemand: abschalten, in der Reihenfolge von oben. Viele: die anderen drei.
Viertens: Wissen wir, was es tut? Gibt es Menschen, die das Verhalten erklären können, Tests, Dokumentation, irgendetwas außer dem Code selbst? Diese Frage entscheidet nicht den Ausgang, aber sie entscheidet den Preis jedes Ausgangs. Ein System, das niemand versteht, ist teuer zu modernisieren, riskant zu ersetzen und gefährlich abzuschalten, weil niemand weiß, was mitgeht. Wenn die Antwort Nein lautet, kommt vor jeder Entscheidung eine Bestandsaufnahme, egal welche Entscheidung danach fällt.
Diese vier Fragen sind übrigens genau das, was am Ende einer Bestandsaufnahme beantwortet ist. Deshalb biete ich sie als Einstieg zum Festpreis an, ausdrücklich mit dem Satz, dass Sie danach auch gegen mich entscheiden können. Ein Teil der Bestandsaufnahmen endet nicht in einer Modernisierung durch mich, und das ist kein Misserfolg des Werkzeugs. Es ist der Zweck.
Der teuerste Ausgang ist, nicht zu entscheiden
Es gibt einen fünften Zustand, der auf keiner Liste steht, weil er kein Ausgang ist. Es ist der Zustand, in dem sich die meisten Altsysteme befinden: Über sie wurde nie entschieden.
Sie laufen weiter, weil sie laufen. Sie kosten weiter, weil niemand die Kosten zusammenrechnet. Sie werden nicht modernisiert, weil das ein Budget bräuchte, nicht eingefroren, weil das ein Datum bräuchte, nicht ersetzt, weil das einen Prozess ändern würde, und nicht abgeschaltet, weil niemand weiß, was daran hängt. Jede der vier Entscheidungen wäre billiger als dieser Zustand, und keine wird getroffen, weil der Zustand keinen Termin hat, an dem er wehtut.
Bis er einen bekommt. Der Entwickler geht, die Version fällt aus der Sicherheitsunterstützung, der Server stirbt, ein Prüfer fragt nach. Dann wird die Entscheidung getroffen, unter Zeitdruck, mit den Optionen, die in dem Moment noch übrig sind, und das sind nie alle vier. Was in dieser Woche zu tun ist, steht in einem eigenen Artikel, aber der eigentliche Fehler liegt Jahre davor.
Wenn Sie aus diesem Artikel eines mitnehmen, dann dies: Jedes Altsystem in Ihrem Haus sollte einen der vier Ausgänge auf sich stehen haben, mit Begründung und mit Datum. Welcher es ist, ist weniger wichtig, als dass es einer ist. Und wenn der Ausgang Modernisieren heißt, dann bitte, weil die Fragen dorthin geführt haben, nicht weil ich der war, der zufällig im Raum saß.
