Regulierte Engineering-Plattform
Ein gewachsenes Produkt wurde über Frontend, GraphQL und Datenoperationen bis zur Delivery von Anwendungs-Workloads auf OpenShift weiterentwickelt und stabilisiert.
Engineering-Plattform ansehenSoftware-Modernisierung
Bestehende Software modernisieren, ohne den Betrieb zu verwetten.
Ich modernisiere Legacy-Software schrittweise. Bestehender Wert bleibt erhalten, während riskante Grenzen sichtbar, testbar und veränderbar werden.
Der Weg folgt dem konkreten Produktziel. Ein vollständiger Rewrite ist keine Standardantwort, sondern nur dann sinnvoll, wenn die belegten Risiken ihn rechtfertigen.
Wann Modernisierung passt
Das System arbeitet noch, aber jede Änderung wird teurer.
Ich steige ein, wenn ein bestehendes Produkt weiterliefern muss und technische Risiken nicht länger ignoriert werden können.
- Neue Funktionen dauern zu lange, weil Änderungen mehrere unklare Systemgrenzen berühren.
- Frameworks, Laufzeiten oder Abhängigkeiten verhindern sichere Updates und Releases.
- Wichtige Geschäftslogik ist ungetestet, schlecht dokumentiert oder an einzelne Personen gebunden.
- Ein geplanter Rewrite wäre teuer, lang und würde den laufenden Produktfortschritt gefährden.
Verantwortung
Modernisierung braucht einen Lieferweg, keinen Big Bang.
Ich verbinde Analyse und Umsetzung. Jede technische Maßnahme muss ein Produkt- oder Betriebsrisiko konkret reduzieren.
- Systemgrenzen, Datenflüsse, Abhängigkeiten und Betriebsrisiken erfassen
- Priorisierte technische Seams und überprüfbare Zwischenziele definieren
- Frontend, Backend, APIs oder Datenpfade schrittweise erneuern
- Tests, Delivery und Observability entlang der Änderung verbessern
- Alte Pfade kontrolliert entfernen und Wissen an das Team übergeben
Belege
Modernisierung mit laufendem Betrieb.
Beide Cases verbinden bestehende Systeme, kontrollierte Änderungen und Produktionsverantwortung.
E-Commerce Cloud Migration
Eine bestehende Commerce-Landschaft wurde stufenweise aus einem providerbetriebenen Legacy-Stack in eine kontrollierbare Plattform überführt.
Cloud-Migration ansehenZusammenarbeit
Risiko in kleinen, produktiven Schritten abbauen.
Die Reihenfolge richtet sich nach Geschäftswert, technischer Kopplung und Produktionsrisiko.
Risiken belegen
Code, Architektur, Daten, Delivery und Betrieb werden an konkreten Änderungsfällen untersucht.
Seams schneiden
Ich definiere Grenzen, an denen neue und bestehende Teile kontrolliert zusammenarbeiten können.
Schrittweise liefern
Änderungen gehen mit Tests, Telemetrie und klarer Rückfalloption in Produktion.
Altlast entfernen
Ersetzte Pfade werden bewusst abgeschaltet, dokumentiert und aus der Betriebsverantwortung entfernt.
Fragen
Vor dem Start häufig geklärt.
Wann ist ein Rewrite trotzdem sinnvoll?
Wenn belegte Systemgrenzen, Technologie- oder Betriebsrisiken eine schrittweise Änderung wirtschaftlich schlechter machen. Diese Entscheidung folgt einer konkreten Analyse.
Kann während der Modernisierung weiterentwickelt werden?
Ja. Der Plan wird gerade so geschnitten, dass Produktarbeit und Risikoreduktion parallel kontrollierbar bleiben.
Beginnt das Projekt mit einem Audit?
Eine kurze Analyse ist meist die erste Phase. Sie endet mit priorisierten Entscheidungen und einer praktischen Validierung, nicht nur mit einer Präsentation.
Übernehmen Sie auch Plattform- und Delivery-Themen?
Ja, wenn sie die Modernisierung blockieren oder deren Produktionsrisiko bestimmen. Anwendung und Betrieb werden nicht künstlich getrennt.
Modernisierung
Welches Risiko verhindert gerade den nächsten sinnvollen Produktschritt?
Beschreiben Sie System, Änderungsziel und bekannte Grenze. Ich ordne ein, wie sich die Modernisierung sinnvoll schneiden lässt.