Vier Zahlen entscheiden über die Neuentwicklung von Altsystemen

Eine Neuentwicklung eines Altsystems ist gerechtfertigt, wenn Kosten und Risiko seiner Änderung höher sind als Kosten und Risiko seiner Ablösung. Alter, Programmiersprache und architektonische Vorlieben beantworten diese Frage nicht. Vier Messwerte tun es: die Fehlerquote bei Änderungen, der Anteil des Teams, der den Code sicher ändern kann, der nicht mehr unterstützte Anteil der Laufzeitumgebung und die Kosten eines einzigen schweren Vorfalls.

Ich habe erlebt, wie Teams Neuentwicklungen genehmigten, weil ein Framework alt wirkte, und dann feststellten, dass die alte Anwendung zweimal im Jahr geändert wurde und keine Probleme machte. Ich habe auch Teams gesehen, die „schrittweise Verbesserung“ verteidigten, während ein einziger verbliebener Betreuer ein Produktionssystem auf einer nicht mehr unterstützten Laufzeitumgebung trug. Beide Entscheidungen beruhten auf Bauchgefühl, das als Ingenieursarbeit verkleidet war. Stehen die vier Zahlen auf einer Seite, lässt sich die Debatte viel schwerer zurechtbiegen.

Entscheidungen über Neuentwicklungen brauchen Messwerte, keine Altersgrenze

Es gibt kein sinnvolles Alter, ab dem Software automatisch neu entwickelt werden sollte. Ein fünfzehn Jahre alter Dienst mit stabilen Schnittstellen, unterstützten Abhängigkeiten, guten Tests und mehreren sicheren Betreuern kann günstiger zu erhalten sein als ein drei Jahre alter Dienst, der bei jeder Veröffentlichung ausfällt. Das Kalenderalter zeigt, wo man genauer hinschauen sollte, entscheidet aber nichts.

Dasselbe gilt für die Programmiersprache. COBOL, RPG, VB6, Delphi oder eine alte PHP-Version können Probleme bei Personal und Support verursachen, doch ein Sprachname misst keines von beiden. Ein gut verstandener COBOL-Stapellauf, der jede Nacht eine feste Datei verarbeitet, kann noch ein Jahrzehnt verdienen. Ein kleiner JavaScript-Dienst, den nur ein externer Mitarbeiter versteht, kann schon heute ein Betriebsrisiko sein.

Beginnen Sie mit einem Messzeitraum, der den normalen Betrieb und mindestens eine anspruchsvolle Geschäftsphase umfasst. Bei Teams mit regelmäßigen Auslieferungen eignet sich oft ein Quartal. Ein langsamer verändertes System braucht vielleicht mehr Zeit, aber warten Sie nicht ewig auf perfekte Daten. Notieren Sie die Unsicherheit neben jeder Zahl und verbessern Sie die Messung laufend.

Verwenden Sie für alle vier Werte dieselbe Untersuchungseinheit. Entscheiden Sie, ob Sie eine Anwendung, einen einzeln auslieferbaren Dienst oder eine eng gekoppelte Gruppe beurteilen, die gemeinsam bewegt werden muss. Fehler für ein ganzes Portfolio und Betreuer für nur ein Repository zu messen, ergibt eine gepflegte, aber bedeutungslose Bewertung.

Die vier Zahlen beantworten unterschiedliche Fragen:

• Kann das Team das System ändern, ohne die Produktion zu beschädigen?
• Wie viele Personen können diese Änderung ohne Aufsicht vornehmen?
• Wie viel der ausgeführten Software erhält keine Fehlerkorrekturen mehr?
• Was verliert das Unternehmen bei einem schweren Vorfall?

Keiner dieser Werte hat eine universelle Schwelle. Legen Sie eine Grenze passend zu Ihrer Risikobereitschaft fest und schreiben Sie auf, welche Maßnahme beim Überschreiten folgt. Der Nutzen entsteht, wenn dieselbe Regel schon vor dem Ausfall gilt, bevor jemand sie an das gewünschte Ergebnis anpassen kann.

Die Fehlerquote zeigt die Abgabe auf jede Auslieferung

Die Fehlerquote bei Änderungen gibt an, welcher Anteil der Produktionsänderungen Abhilfe erfordert, weil er den Dienst beeinträchtigt, einen Ausfall, eine Rücknahme oder eine dringende Korrektur verursacht hat. DORA verwendet dieses Konzept als Maß für die Leistung der Softwarebereitstellung. Ich würde die Definition eng halten: Zählen Sie Fehler, die durch eine Änderung verursacht wurden, nicht jeden Produktionsvorfall in zeitlicher Nähe zu einer Auslieferung.

Bestimmen Sie vor der Berechnung, was als Produktionsänderung gilt. Beziehen Sie Anwendungsbereitstellungen, Datenbankmigrationen, Konfigurationsfreigaben, Änderungen an Zeitplänen und Infrastrukturänderungen ein, wenn das Team sie als einen Bereitstellungsprozess steuert. Zählen Sie einen gewöhnlichen Wiederholungsversuch nicht als eigene fehlgeschlagene Änderung. Lassen Sie aus zehn Notfall-Commits nach einer schlechten Freigabe auch nicht zehn unabhängige Fehler werden.

Die Grundrechnung ist einfach:

change_failure_rate = failed_production_changes / total_production_changes

Schwierig ist die Einordnung. Halten Sie für jede fehlgeschlagene Änderung den Auslöser, die Auswirkung auf Kunden, die Wiederherstellungsmaßnahme und die Ursache in Code, Daten, Konfiguration oder einer unbekannten Wechselwirkung fest. Eine Ticket-Kennzeichnung wie change-failure genügt, wenn alle sie konsequent verwenden. Prüfen Sie strittige Fälle monatlich mit Entwicklung und Betrieb am selben Tisch.

Vergleichen Sie Rohquoten nicht zwischen Systemen mit völlig verschiedenen Auslieferungsmustern. Eine Anwendung liefert vielleicht hundert kleine Änderungen, eine andere eine gebündelte Freigabe. Setzen Sie die Quote neben Änderungsvolumen und mittlere Wiederherstellungszeit. Zehn Prozent bei zehn umkehrbaren Funktionsschaltern sind ein anderes Geschäftsrisiko als zehn Prozent bei vierteljährlichen Datenbankfreigaben, deren Wiederherstellung sechs Stunden dauert.

Der Verlauf zählt mehr als eine einzelne Messung. Sinkt die Quote nach besseren Tests, besserer Beobachtbarkeit und kleineren Auslieferungen, gewinnt das Team durch Nachbesserung wieder Kontrolle. Bleibt sie nach zwei oder drei gezielten Versuchen hoch, arbeitet die Architektur möglicherweise gegen den Auslieferungsprozess. Suchen Sie nach wiederkehrenden Ursachen: gemeinsam veränderter Zustand, undokumentierte Reihenfolgen in Stapelläufen, versteckte Datenbankverträge und Bereitstellungsschritte, die sich nicht proben lassen. Solche Muster verteuern jede künftige Funktion.

Belohnen Sie ein Team nicht dafür, Änderungen zu vermeiden. Ein System ohne Auslieferungen hat eine undefinierte oder trügerisch perfekte Quote. Erfassen Sie Anforderungen, die wegen des Auslieferungsrisikos verschoben wurden. Wenn Geschäftsänderungen aus Angst vor der Produktion liegen bleiben, belegt das Ausbleiben von Fehlern Stillstand und nicht Gesundheit.

Sichere Verantwortung ist kleiner als der Repository-Zugriff

Der Anteil sicherer Betreuer ist der Teil des zuständigen Entwicklungsteams, der eine bedeutsame Änderung am System selbständig vornehmen, prüfen, ausliefern und im Fehlerfall zurücknehmen kann. Repository-Zugriff zählt nicht. Auch die Fähigkeit, eine Datei zu bearbeiten, während der einzige Experte jeden Schritt vorgibt, zählt nicht.

Definieren Sie eine bedeutsame Änderung anhand der tatsächlichen Arbeit am System. Das kann ein neues Feld durch Datenbank, Dienst und Oberfläche sein, eine Berechnungsänderung mit finanziellen Folgen oder eine Änderung an einem Nachtlauf, ohne dessen Wiederanlauf zu beschädigen. Die Aufgabe sollte jene Grenzen überschreiten, an denen Wissen gewöhnlich verloren geht.

Bewerten Sie jede Person anhand von vier Fähigkeiten:

• Sie kann den betroffenen Ausführungspfad und seine Abhängigkeiten erklären.
• Sie kann die Änderung umsetzen und testen, ohne ein unverstandenes Vorbild zu kopieren.
• Sie kann die Änderung über den echten Produktionsprozess ausliefern.
• Sie kann einen Fehler untersuchen und den Dienst ohne den Systemorakel wiederherstellen.

Zählen Sie jemanden nur, wenn aktuelle Belege alle vier Punkte stützen. Gemeinsames Arbeiten hilft beim Lernen, beweist aber keine selbständige Verantwortung. Codeprüfungen, Teilnahme an Vorfällen und eine erfolgreiche Produktionsänderung sagen mehr aus als eine Selbsteinschätzung.

Berechnen Sie dann:

safe_touch_share = independent_safe_maintainers / relevant_engineers

Notieren Sie außerdem die absolute Zahl. Ein Anteil von 50 Prozent klingt gesund, bis er eine von zwei Personen bedeutet. Umgekehrt können vier fähige Betreuer in einem Team von zwanzig eine stabile interne Anwendung ausreichend abdecken, solange Bereitschaftsdienst und Urlaub nicht alle vier zugleich entfernen.

Dieser Wert macht eine häufig verwischte Unterscheidung sichtbar: verfügbare Dokumentation ist kein Betriebswissen. Ein tausendseitiges Handbuch kann Bildschirme und Tabellen erklären, aber verschweigen, warum die Abrechnung vor dem Abgleich erfolgen muss, welche fehlerhaften Datensätze Mitarbeiter von Hand reparieren oder wie ein Lauf ohne Doppelbuchung fortgesetzt wird. Prüfen Sie das Dokument, indem ein neuer Betreuer es unter Aufsicht benutzt. Seine Fragen gehören zur fehlenden Systemspezifikation.

Ein sinkender Anteil sicherer Betreuer ist oft das früheste Signal für eine Neuentwicklung, weil darin eine Frist verborgen liegt. Ruhestand, Kündigung oder der Abschied eines Dienstleisters können ein schwieriges System über Nacht unveränderbar machen. Wenn Wissenstransfer den Anteil erhöht und die neu geschulten Personen sechs Monate später weiter Änderungen vornehmen, spricht noch etwas für Nachbesserung. Wenn jeder Transferversuch die Arbeit wieder zum selben Experten leitet, nennen Sie die Lage nicht länger Schulung.

Der nicht unterstützte Laufzeitanteil misst Belastung, nicht Peinlichkeit

Der nicht unterstützte Laufzeitanteil ist der Teil des Produktionsstapels, für den der zuständige Hersteller oder das Projekt keine Sicherheits- oder Fehlerkorrekturen mehr liefert. Er umfasst mehr als die Programmiersprache. Zählen Sie Betriebssysteme, Datenbanken, Anwendungsserver, Laufzeitumgebungen, große Frameworks, Treiber und unverzichtbare Vermittlungssoftware.

Erfassen Sie, was tatsächlich läuft, nicht was laut Architekturbild laufen sollte. Lesen Sie Versionen aus Rechnern, Container-Abbildern, Paketdateien, Jobdefinitionen und Datenbankabfragen. Beziehen Sie bei Großrechnern und Midrange-Systemen Compiler, Transaktionsmonitore, Planer und Herstellerkomponenten im Ausführungspfad ein. Notieren Sie die Quelle jedes Supportdatums, damit Beschaffungsgerüchte nicht zur Richtlinie werden.

Eine brauchbare gewichtete Rechnung lautet:

unsupported_runtime_share = sum(weight_of_unsupported_components) / sum(weight_of_all_components)

Setzen Sie Gewichte nach Exposition und Geschäftsrolle. Ein nicht mehr unterstützter öffentlicher Anwendungsserver verdient mehr Gewicht als ein isolierter Berichtskonverter, der einmal im Monat läuft. Halten Sie die Gewichtung so einfach, dass eine andere Person sie nachvollziehen kann. Wenn ein Ausschuss eine Stunde erklären muss, warum eine Komponente 7,3 Punkte erhält, ist die Genauigkeit erfunden.

Nicht unterstützt bedeutet nicht kompromittiert, und unterstützt bedeutet nicht sicher. Nicht unterstützt heißt, dass der Betreuer keinen normalen Weg für Korrekturen mehr liefert. Ihr Team kann mit Isolation, virtuellen Patches, strenger Eingabekontrolle oder einem bezahlten verlängerten Supportvertrag ausgleichen. Schreiben Sie jede ausgleichende Kontrolle neben die Komponente und prüfen Sie, ob sie wirklich für jeden Eingang gilt.

Achten Sie auf den nicht unterstützten Kern unter unterstützten Rändern. Ein aktueller Browser, Reverse-Proxy und eine aktuelle Datenbank retten keine Geschäftslogik, die eine aufgegebene Laufzeit braucht. Teams aktualisieren mitunter alles um den alten Kern und melden dann wenige veraltete Komponenten. Eine Gewichtung nach Bedeutung in der Ausführung verhindert diese Buchhaltung.

Nachbesserung bleibt vernünftig, wenn nicht unterstützte Komponenten isoliert, stabil, einzeln ersetzbar und durch Kontrollen mit niedrigen Betriebskosten abgedeckt sind. Sie ist schwerer zu verteidigen, wenn eine solche Komponente nicht vertrauenswürdige Eingaben annimmt, Betriebssystemaktualisierungen blockiert oder eine ganze veraltete Bereitstellungskette erzwingt. Dann wächst die Belastung mit: Jede umliegende Aktualisierung muss das älteste Stück berücksichtigen.

Vorfallkosten machen technisches Risiko zur Geschäftsgrenze

Die Kosten eines schweren Vorfalls umfassen den gesamten Geschäftsverlust von der Erkennung bis zur Wiederherstellung und Korrektur, nicht bloß Cloud-Rechnung oder Überstunden der Entwickler. Verwenden Sie wenn möglich einen echten Vorfall. Gab es noch keinen, entwickeln Sie ein Szenario mit Finanzen, Betrieb, Sicherheit und dem Geschäftsverantwortlichen und kennzeichnen Sie jede Annahme.

Berechnen Sie Kosten in nachprüfbaren Kategorien:

incident_cost = lost_margin
              + staff_hours * loaded_hourly_cost
              + customer_remediation
              + contractual_or_regulatory_cost
              + data_reconciliation
              + delayed_business_events

Verwenden Sie entgangene Marge statt Bruttotransaktionswert, sofern die Transaktionen nicht dauerhaft verschwinden. Trennen Sie verspäteten von verlorenem Umsatz. Zählen Sie Handarbeit in Betrieb, Finanzen, Support, Entwicklung und Leitung. Beziehen Sie die Tage nach Wiederherstellung ein, in denen Menschen Datensätze abgleichen, doppelte Aktionen korrigieren, Kunden antworten und vorgeschriebene Meldungen vorbereiten.

Multiplizieren Sie keine erschreckende Stundenzahl mit dem längsten vorstellbaren Ausfall. Definieren Sie den schweren Vorfall genau, etwa vier Stunden ausgefallene Auftragserfassung mit einem Tag Abgleich oder einen fehlerhaften Preislauf, der Kunden vor der Erkennung erreicht. Dokumentieren Sie Volumen, Marge, Personalkosten, Vertragsbedingungen und Wiederherstellungsannahmen. Die Finanzabteilung muss das Modell Zeile für Zeile anfechten können.

Verwenden Sie zwei Kostenmodelle, wenn das System unterschiedliche Fehlerarten hat. Ein Verfügbarkeitsvorfall und ein stiller Fehler der Datenintegrität sehen selten gleich aus. Letzterer kann während des Ausfalls billig wirken, weil niemand ihn erkennt, und bei der Rekonstruktion viel teurer werden. Durchschnittswerte verdecken diesen Unterschied.

Vorfallkosten verändern die Debatte, weil sie bestimmen, wie viel zur Verringerung der Belastung ausgegeben werden sollte. Ein brüchiges System für einen kleinen internen Ablauf kann vernünftig weiter nachgebessert werden. Ein ähnlich brüchiges System, das Buchungen vornimmt oder Fabrikbewegungen steuert, verlangt bei den anderen drei Messwerten geringere Toleranz.

Machen Sie aus Vorfallkosten keinen Zaubertrick mit Erwartungswerten, wenn belastbare Häufigkeitsdaten fehlen. Eine geschätzte Jahreswahrscheinlichkeit mit modellierten Folgen zu multiplizieren ergibt einen sauberen Geldbetrag aus zwei schwachen Eingaben. Lassen Sie Belege für Häufigkeit, Folgen und Unsicherheit sichtbar. Führungskräfte können entscheiden, ohne die Schätzung als Versicherungsmathematik auszugeben.

Stellen Sie die vier Zahlen auf ein Entscheidungsblatt

Ein Entscheidungsblatt zeigt Istwerte, Verlauf, Sicherheit, vereinbarte Grenze und die Maßnahme beim Überschreiten. Eine Seite genügt. Es soll Abwägungen offenlegen, nicht eine Antwort errechnen, der die Leitung blind folgen muss.

Verwenden Sie eine Tabelle wie diese und ersetzen Sie die Beispielgrenzen durch eigene:

Diese Werte dienen nur der Veranschaulichung und sind keine Vergleichsmaßstäbe. Eine Schnittstelle zur Krankenhausabrechnung, ein Etikettendrucker im Lager und ein öffentlicher Katalog brauchen andere Grenzen. Entscheidend ist, dass die Verantwortlichen Limits vor dem nächsten Vorfall wählen und die Belege für jeden Wert aufbewahren.

Fassen Sie die vier Werte nicht vorschnell zu einer gewichteten Punktzahl zusammen. Eine 62 verbirgt, ob das System häufige billige Fehler oder eine einzige katastrophale nicht unterstützte Abhängigkeit hat. Lassen Sie alle vier Achsen sichtbar. Wenn die Leitung einen Status verlangt, verwenden Sie drei Entscheidungszustände:

• Weiter nachbessern, solange die Werte innerhalb ihrer Grenzen bleiben und sich verbessern.
• Eindämmen und vorbereiten, wenn ein Wert die Grenze überschreitet oder mehrere sich verschlechtern.
• Neu entwickeln, wenn die Belastung das vereinbarte Limit überschreitet und glaubwürdige Abhilfe gescheitert ist.

Setzen Sie ein Prüfdatum und benennen Sie die Person, die jeden Wert aktualisiert. Daten zu fehlgeschlagenen Änderungen können aus Bereitstellungs- und Vorfallsaufzeichnungen stammen. Eigentumsnachweise gehören zur Entwicklungsleitung. Laufzeitunterstützung braucht eine Prüfung durch Plattform oder Sicherheit. Finanzen und Geschäftsverantwortliche müssen die Folgen eines Vorfalls bestätigen.

Das Blatt verhindert auch eine schleichende Ausweitung des Umfangs. Wenn nur ein Stapelplaner die fehlende Unterstützung verursacht, ersetzen Sie ihn, statt den ganzen Bestand für verdorben zu erklären. Ist nur die Verantwortung schwach, können Rotation und Dokumentation reichen. Eine Neuentwicklung verdient Zustimmung, wenn die Messwerte auf eine Systemgrenze zeigen, die sich nicht wirtschaftlich vor Ort reparieren lässt.

Nachbesserung gewinnt bei begrenztem und umkehrbarem Risiko

Nachbesserung bleibt richtig, wenn Änderungen selten scheitern, mehrere Personen Verantwortung tragen, nicht unterstützte Komponenten glaubwürdig eingedämmt sind und ein Vorfall innerhalb der Risikobereitschaft bliebe. Eine Neuentwicklung bindet Aufmerksamkeit, die Produkte verbessern könnte, welche Kunden tatsächlich bemerken. Ersetzen Sie keine stabile Software, um ein Architekturbild zufriedenzustellen.

Es gibt mehrere starke Fälle für Nachbesserung. Das System nähert sich vielleicht einer geplanten Stilllegung, weil ein Geschäftsbereich schließt. Sein Verhalten kann durch Vorschriften oder Vertrag festgelegt sein und wenige Änderungen erwarten. Ein Anbieter bietet vielleicht unterstützte Aktualisierungen, die die belastete Laufzeit entfernen, ohne Geschäftslogik anzufassen. Oder die Anwendung liegt hinter einer schmalen kontrollierten Schnittstelle ohne nicht vertrauenswürdige Eingaben und mit erprobter Wiederherstellung.

Nachbesserung braucht klaren Umfang und eine Ausstiegsbedingung. Finanzieren Sie Abhängigkeitsaktualisierungen, Charakterisierungstests, Bereitstellungsautomatisierung, Beobachtbarkeit und Wissenstransfer. Messen Sie danach erneut. Sinken Fehlerquote und steigt sichere Verantwortung, funktioniert die Arbeit. Baut das Team in jedem Zyklus dieselbe brüchige Bereitstellung neu oder schützt eine Laufzeit, die alle anderen Aktualisierungen blockiert, ist das Programm nur noch teurer Aufschub.

Ich widerspreche der beliebten Regel, jeder alte Monolith müsse zuerst in Microservices zerlegt werden. Der Rat klingt schrittweise und deshalb sicherer als eine Neuentwicklung. Tatsächlich verteilt das Herauslösen von Diensten aus Code, dessen Verhalten niemand beschreiben kann, die Unsicherheit oft über ein Netzwerk. Sie schaffen Teilfehler, versionierte Schnittstellen und Betriebsaufwand, bevor Gleichheit bewiesen ist. Erfassen Sie zuerst das Verhalten an der Systemgrenze. Wählen Sie dann Grenzen passend zu Geschäftsfähigkeiten und Dateneigentum.

Eine weitere Möglichkeit ist die gezielte Ablösung. Behalten Sie stabile Berechnungs- oder Stapellogik und ersetzen Sie die nicht unterstützte Oberfläche. Setzen Sie eine Datenbankabhängigkeit hinter einen unterstützten Dienst. Legen Sie ungenutzte Berichte still, bevor Sie sie übertragen. Berechnen Sie die vier Werte nach jeder Entfernung für die verbleibende Grenze neu, denn ein kleinerer alter Kern kann billig genug für dauerhafte Eindämmung werden.

Verwechseln Sie Nachbesserung nicht mit Untätigkeit. Die Entscheidung zum Erhalt nimmt konkrete Arbeit an: Supportverträge, Kontrolltests, Wiederherstellungsübungen, Personalabdeckung und geplante Neubewertung. Wenn niemand diese Punkte finanziert, hat die Organisation nicht Nachbesserung gewählt, sondern ungesteuerten Verfall.

Eine Neuentwicklung muss Verhalten sichern, bevor sie Architektur ändert

Eine vertretbare Neuentwicklung erfasst beobachtbares Verhalten, lässt alte und neue Umsetzung gegen dieselben Fälle laufen und ändert die Architektur nur mit passenden Belegen. Eine Übersetzung Zeile für Zeile bewahrt zufällige Strukturen und kann Fehler wiederholen, ohne den betrieblichen Zusammenhang zu erhalten, der sie beherrschbar machte.

Beginnen Sie mit produktionsnahen Belegen. Zeichnen Sie Anfragen und Antworten auf, sofern Richtlinien es erlauben, erfassen Sie Ein- und Ausgaben von Stapelläufen, bewahren Sie typische Fehlerfälle auf und identifizieren Sie Nebeneffekte wie Dateien, Nachrichten, Datenbankschreibvorgänge und Bedienerabfragen. Entfernen Sie vertrauliche Werte, aber bewahren Sie Verteilungen, Reihenfolge und fehlerhafte Fälle, welche die echten Zweige ausführen.

Bauen Sie ein Paritätsprüfwerkzeug, das denselben Fall an beide Systeme sendet und normalisierte Ergebnisse vergleicht. Normalisieren Sie Zeitstempel, erzeugte Kennungen, bedeutungslose Reihenfolgen und andere nicht deterministische Felder ausdrücklich. Verbergen Sie nie einen Unterschied durch einen breiten Textfilter. Jede Normalisierungsregel muss erklären, warum die Abweichung belanglos ist.

Vergleichen Sie bei zustandsbehaftetem Verhalten Übergänge statt letzter Bildschirme. Geben Sie beiden Systemen denselben Datenbankzustand, führen Sie die Aktion aus und vergleichen Sie geänderte Zeilen, gesendete Nachrichten, Dateien und Rückgabewerte. Prüfen Sie für einen Stapellauf sauberen Abschluss, Neustart nach Unterbrechung, doppelte Eingabe, verspätete Eingabe und teilweisen Ausfall eines Folgesystems. Betreiber verlassen sich oft stärker auf solche Randfälle, als Entwickler vermuten.

Danach kann sich die Architektur sicher ändern. Ein Bestand aus COBOL und JCL kann zu Go-Diensten mit Postgres werden, ein numerischer Kern kann Rust rechtfertigen, ein Desktop-Client kann zu TypeScript wechseln. Das sind Entwurfsentscheidungen, keine Ziele an sich. Ziel ist gleichwertiges Geschäftsverhalten mit einem Ausführungsmodell, das das heutige Team betreuen kann.

CodeHero liest den gesamten Quellbaum und prüft das modernisierte System mit einem Paritätswerkzeug gegen aufgezeichneten Produktionsverkehr, statt Dateien einzeln zu übersetzen. Projekte werden in unter 30 Tagen geliefert, auch in regulierten Umgebungen, in denen bereitgestellte Modelle abgeschottet innerhalb des Kundenbereichs laufen können.

Behandeln Sie Paritätsfehler als Entdeckungen in der Spezifikation. Manche zeigen Fehler der Neuentwicklung. Andere decken widersprüchliches Altverhalten, umgebungsabhängige Logik oder Produktionsdaten auf, die angebliche Regeln verletzen. Der Geschäftsverantwortliche muss entscheiden, welche Eigenheiten Vertrag und welche Fehler sind. Entwicklung kann diese Antwort nicht allein aus Code ableiten.

Zustimmung braucht eine berechnete Alternative statt Begeisterung

Ein Vorschlag zur Neuentwicklung muss gegen einen vollständig berechneten Nachbesserungsplan und einen vollständig berechneten Eindämmungsplan antreten. Lautet die Alternative nur „weiter leiden“, ist der Vergleich manipuliert. Berechnen Sie Aktualisierungen, Tests, Spezialistenabdeckung, Supportverträge, Kontrollen, Vorfallbelastung und Funktionsverzögerungen, die Nachbesserung tatsächlich braucht.

Berechnen Sie bei der Neuentwicklung mehr als die Umsetzung. Beziehen Sie Erkundung, Verhaltenserfassung, Datenumwandlung, Parallelbetrieb, Abnahme, Umstellung, Rückfallvorbereitung, Schulung und Stilllegung ein. Benennen Sie Verantwortliche für Geschäftsentscheidungen und Datenprüfung. Eine technisch fertige Ablösung kann scheitern, wenn Finanzen Eröffnungssalden nicht abgleichen oder Betreiber einen halbfertigen Stapellauf nicht retten können.

Verlangen Sie Belege für Zeitpläne. Erfassen Sie Integrationen, Datenspeicher, geplante Läufe, Berichte, Benutzerrollen, externe Dateiaustausche und Betriebsverfahren. Kennzeichnen Sie alles als beobachtet, abgeleitet oder unbekannt. Unbekanntes blockiert das Vorhaben nicht automatisch, aber jemand muss vor der Umstellung entscheiden, wie es geprüft wird.

Die Freigabe muss fünf Fragen in klarer Sprache beantworten:

1. Welcher der vier Werte hat seine vereinbarte Grenze überschritten und was belegt das?
2. Welche Abhilfe hat das Team versucht und wie reagierte der Wert?
3. Welche Systemgrenze wird ersetzt, behalten oder stillgelegt?
4. Wie weist das Team Verhaltensgleichheit nach und probt den Rückfall?
5. Welcher Geschäftsverantwortliche akzeptiert verbleibende Unterschiede und Umstellungsrisiko?

Sind die Antworten vage, finanzieren Sie eine kurze Beweisphase statt einer Neuentwicklung. Sie soll Laufzeitinventar, Verantwortungsbewertung, Vorfallmodell, Verhaltensfallbestand und Systemgrenze liefern. Sie soll keine Präsentation über Modernität erzeugen.

Zur Freigabe gehören auch Abbruchbedingungen. Bleiben Paritätslücken in einem folgenreichen Ablauf, lässt sich die Datenumwandlung nicht abgleichen oder erfüllt die Ablösung eine betriebliche Wiederherstellungsanforderung nicht, wartet die Umstellung. Bereits ausgegebenes Geld macht ein ungeprüftes System nicht sicher.

Prüfen Sie die Entscheidung nach jeder wesentlichen Änderung neu

Die Entscheidung verfällt, sobald sich System, Team oder Geschäftsfolge ändern. Berechnen Sie die vier Werte nach einer großen Abhängigkeitsaktualisierung, einem Verantwortungswechsel, einer Übernahme, einer Lastverschiebung, einer neuen regulatorischen Pflicht oder einem schweren Vorfall neu. Ein Jahr lang unberührtes Entscheidungsblatt wird selbst zur Altdokumentation.

Halten Sie die Belege nah an der normalen Entwicklungsarbeit. Bereitstellungsdaten müssen nachgebesserte Änderungen erkennen lassen. Vorfallsprüfungen sollten durch Änderungen verursachte Fehler von anderen Störungen trennen und echte Arbeits- und Abgleichkosten festhalten. Fähigkeitsbelege kommen aus gelieferter Arbeit. Das Laufzeitinventar muss sich aus laufenden Umgebungen erneuern, nicht aus einem jährlichen Fragebogen.

Beobachten Sie Richtung und Grenzen. Vier Werte knapp innerhalb ihrer Limits, die sich gemeinsam verschlechtern, rechtfertigen Vorbereitung. Ein Wert außerhalb seines Limits, der sich schnell verbessert, kann eine weitere Nachbesserungsrunde rechtfertigen. Schreiben Sie Ausnahme, Verantwortlichen und Ablaufdatum auf das Blatt, damit vorübergehende Toleranz nicht unbemerkt zur Dauerregel wird.

Die schwersten Fälle liefern widersprüchliche Signale. Ein System kann stabil sein und bei Vorfällen wenig kosten, während die Verantwortung zusammenbricht. Es kann viele fähige Betreuer haben und trotzdem von einer nicht unterstützten öffentlichen Laufzeit abhängen. Mitteln Sie die unangenehme Achse nicht weg. Entscheiden Sie, ob eine glaubwürdige Kontrolle diesen Wert vor der verborgenen Frist bewegen kann.

Das erste nützliche Treffen ist kein Workshop zur Neuentwicklung. Es ist eine Prüfung, zu der Entwicklung, Betrieb, Sicherheit, Finanzen und Geschäftsverantwortliche jeweils Belege für eine Zahl bringen. Legen Sie am Ende Grenzen fest und finanzieren Sie die daran gebundene nächste Maßnahme. Sprechen die Zahlen für Nachbesserung, bessern Sie ohne Entschuldigung nach. Zeigen sie, dass jede sichere Änderung von schwindendem Wissen, aufgegebener Software und untragbaren Vorfallkosten abhängt, bezahlen Sie nicht länger für die Illusion, ein weiterer Patch werde die Kontrolle zurückbringen.