Der Ausgangspunkt.
Das ERP unterstützte den täglichen Retail-Betrieb. Zuverlässigkeit war deshalb eine Produktanforderung, keine Randnotiz der Wartung. Änderungen mussten das System verbessern und zugleich bestehende Arbeit schützen.
Performance, Integrationen und Oberflächenverhalten hingen zusammen. Nur eine Schicht zu behandeln hätte das Problem lediglich an eine andere Stelle im Anfrageweg verschoben.
Was die Arbeit respektieren musste.
Ein operatives ERP lässt wenig Raum für unbedachte Änderungen:
- Bestehende Abläufe mussten die tägliche Retail-Arbeit weiter tragen.
- Datenbank, Backend und Frontend mussten bei Vertragsänderungen zusammenpassen.
- Integrationen mussten an der Systemgrenze verständlich bleiben.
- Performance-Arbeit musste dem realen Anwendungspfad folgen, nicht nur einem isolierten Symptom.
Die Diagnose.
In einem mehrschichtigen ERP ist die sichtbare Verzögerung oder Störung oft nur das letzte Glied. Eine Ansicht kann wegen ihrer Anfrageform, Backend-Arbeit oder eines Datenbankzugriffs langsam sein. Ein Integrationsfehler kann als Frontend-Inkonsistenz erscheinen.
Ich arbeitete durch diesen gesamten Pfad. SQL Server, .NET-Dienste und Browser-Oberfläche wurden als Teile desselben Verhaltens behandelt, einschliesslich der Integrationsgrenze.
Die nützliche Systemsicht.
Die sinnvolle Änderungseinheit war die Ende-zu-Ende-Anfrage: eine Benutzeraktion im Frontend, Anwendungsregeln in .NET, Datenarbeit in SQL Server und der Austausch an der Integrationsgrenze.
Entscheidungen, die zählten.
Die Arbeit setzte auf kontrollierte Weiterentwicklung statt auf eine dramatische Neuentwicklung.
Den ganzen Anfrageweg verfolgen
Performance- und Zuverlässigkeitsarbeit beginnt beim sichtbaren Verhalten und folgt ihm durch Backend und Datenbank.
Das braucht mehr Untersuchung als ein Patch am ersten langsamen Bauteil, verschiebt dafür aber nicht nur den Engpass.
Verträge bewusst ändern
Wenn sich Daten oder Backend-Verhalten ändern, brauchen Frontend und Integrationen einen expliziten, kompatiblen Vertrag.
Kompatibilitätsarbeit wirkt weniger spektakulär, schützt aber die bereits laufenden Geschäftsabläufe.
In auslieferbaren Schritten verbessern
Fokussierte Änderungen sind in einem geschäftskritischen System leichter verständlich und machen die Wirkung jeder Version sichtbarer.
Schrittweise Lieferung verlangt Geduld und klare Grenzen. Dafür bleibt das Risiko erkennbar.
Delivery und Prüfung.
Jede Änderung lässt sich in ihrer eigenen Schicht und erneut im unterstützten Benutzerablauf prüfen. Datenbankverhalten, Backend-Regeln, Integrationsantworten und Frontend-Status müssen übereinstimmen.
Diese Ende-zu-Ende-Prüfung zählt besonders bei täglichen Abläufen. Eine technisch korrekte Änderung ist nicht fertig, wenn sie Routinearbeit schwerer verständlich oder weniger verlässlich macht.
Das qualitative Ergebnis.
Performance, Integrationen und tägliche Zuverlässigkeit verbesserten sich gemeinsam, weil die Arbeit die Grenzen überquerte, an denen diese Themen zusammenkamen.
Das System entwickelte sich weiter, ohne so zu tun, als liesse sich ein geschäftskritisches ERP in einem sauberen Schritt anhalten und ersetzen. Der praktische Weg war: verstehen, verbessern und dabei nützlich halten.