Der Ausgangspunkt.
Das laufende Web-ERP war ein Monolith auf SQL Server, C# und .NET Framework 4.8, Entity Framework, KnockoutJS, JavaScript, jQuery, Bootstrap und Crystal Reports. Zuverlässigkeit war eine Produktanforderung, keine Randnotiz der Wartung.
Die Datenbank hatte kein Migrationssystem und gehörte nicht allein der Webanwendung. Ein wesentlich älteres VB6-Desktop-ERP und eine Kassenanwendung nutzten dasselbe Schema. Eine im Web korrekte Änderung konnte deshalb den täglichen Betrieb an anderer Stelle brechen.
Der Umfang reichte von Features, Fehlern, Stored Procedures, Views und Reports bis zu zwei Kuriereinbindungen, Anforderungen, Schulung und Support. Der direkte Austausch mit dem Kunden war entscheidend, um die tatsächliche Nutzung vor einer Änderung zu verstehen.
Was die Arbeit respektieren musste.
Das System konnte sich nur weiterentwickeln, wenn alte und neue Betriebswege weiterhin zusammenpassten:
- Bestehende Abläufe mussten die tägliche Retail-Arbeit weiter tragen.
- Änderungen am SQL-Server-Schema mussten rückwärtskompatibel sein, weil keine Migrationshistorie alle Verbraucher koordinierte.
- Das .NET-Framework-Web-ERP und die älteren VB6-Desktop- und Kassenanwendungen teilten denselben Datenvertrag.
- KnockoutJS, jQuery, Backend-Regeln und Datenbankverhalten mussten bei Änderungen am Webablauf zusammenpassen.
- Anforderungen mussten mit dem Kunden in betrieblicher Sprache geklärt werden, bevor sie zu Code, Reports oder Integrationsverhalten wurden.
- Zwei externe Kuriereinbindungen mussten an der Systemgrenze verständlich bleiben.
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.
Die gemeinsame Datenbank änderte die übliche Bedeutung eines internen Implementierungsdetails. Tabellen, Spalten und Stored Procedures waren zugleich Verträge mit VB6-Software, die keiner modernen Migrationsfolge folgen konnte.
Ich verband Ende-zu-Ende-Tracing mit direkten Kundengesprächen. SQL-Server-Abfragen und Stored Procedures, .NET-Framework-Regeln, KnockoutJS- und jQuery-Oberflächen, Reports, Kurieraustausch und der alte Desktop-Pfad waren Teile desselben Betriebsverhaltens.
Die nützliche Systemsicht.
Die sinnvolle Einheit war der gesamte Betriebsvertrag: eine Aktion in der KnockoutJS- und jQuery-Weboberfläche, Regeln in .NET Framework 4.8, Arbeit am gemeinsamen SQL-Server-Schema und die älteren VB6-Desktop- und Kassenpfade, die von denselben Datensätzen abhingen. Reports und Kurierübergaben bildeten weitere Grenzen um diesen Kern.
Warum Kontinuität eine Architekturentscheidung war.
Dies war die Weiterentwicklung eines laufenden ERP, keine Greenfield-Empfehlung seines Stacks. Die richtige Technologieentscheidung bestand oft darin, einen Betriebsvertrag zu erhalten und gezielt zu verbessern, statt jede Schicht gleichzeitig zu ersetzen.
C#/.NET Framework und KnockoutJS für schrittweise Änderungen beibehalten
- Warum
- Funktionen, Fehler und tägliche Abläufe führten bereits durch diese Schichten. Innerhalb davon zu arbeiten erlaubte, jede Änderung entlang des realen Anfragewegs zu verfolgen und im laufenden Betrieb auszuliefern.
- Was ich ausgeschlossen habe
- Eine Big-Bang-Neuentwicklung von Backend und Frontend hätte bestehendes Verhalten vollständig neu erfassen und ersetzen müssen, bevor kleinere betriebliche Verbesserungen die Benutzer erreicht hätten.
- Der Preis dafür
- Die Arbeit akzeptiert ältere Framework-Grenzen, gemischte Frontend-Muster und fortlaufenden Wartungsbedarf, statt sofort eine saubere moderne Ausgangsbasis zu gewinnen.
SQL Server als gemeinsamen Datenvertrag behandeln
- Warum
- Web-ERP, VB6-Desktop-ERP und Kassenanwendung lasen und schrieben dasselbe Schema. Kompatible SQL-Änderungen schützten Verbraucher, die nicht mit jedem Webrelease wechseln konnten.
- Was ich ausgeschlossen habe
- Eine neue Datenbank oder ein neues Schema im Rahmen der Webarbeit hätte vorausgesetzt, dass alle Verbraucher trotz fehlenden Migrationssystems gleichzeitig umgestellt werden konnten.
- Der Preis dafür
- Additive Änderungen und Übergangsstrukturen können länger bestehen bleiben; das Datenbankdesign muss alte Lese- und Schreibwege ebenso berücksichtigen wie den neuen Pfad.
Crystal Reports und bestehende Reportingwege weiterentwickeln
- Warum
- Reporting war bereits Teil des Betriebssystems und seines SQL-Server-Verhaltens. Dieser bestehende Pfad erlaubte, Reportänderungen mit demselben Daten- und Anwendungsvertrag zu prüfen.
- Was ich ausgeschlossen habe
- Eine neue Reportingplattform zur selben Zeit hätte eine weitere Migration eröffnet und die Übersetzung bestehenden Reportverhaltens verlangt, während Anwendung und Datenbank ebenfalls verändert wurden.
- Der Preis dafür
- Die Lösung behält ältere Reportingwerkzeuge und ihre Gestaltungsgrenzen; Reportarbeit verlangt weiterhin Spezialwissen und eine Prüfung über mehrere Schichten.
Jeweils einen End-to-End-Ablauf liefern
- Warum
- Eine Änderung konnte Bedienoberfläche, .NET-Regeln, SQL-Verhalten und bei Bedarf Reports, Integrationen sowie ältere Anwendungen als einen zusammenhängenden betrieblichen Ausschnitt abdecken.
- Was ich ausgeschlossen habe
- Eine Modernisierung Schicht für Schicht hätte Verhalten zwischen alten und neuen Wegen geteilt und den Nachweis des echten Ablaufs bis zum Abschluss mehrerer Migrationen verschoben.
- Der Preis dafür
- Jeder Ausschnitt muss über alle berührten Schichten und Anwendungen abgeschlossen und geprüft werden; Fortschritt braucht daher klare Grenzen statt der sichtbaren Einheitlichkeit eines schichtweiten Programms.
Regeln für Änderungen im laufenden Betrieb.
Technische Kontinuität setzte den Rahmen; diese Regeln verbanden jede Änderung mit dem gesamten Betriebsweg und dem Feedback der Menschen, die ihn nutzen.
Den ganzen Anfrageweg verfolgen
Performance- und Zuverlässigkeitsarbeit beginnt bei einem Verhalten, das Kunde oder Benutzer beschreiben können, und folgt ihm durch Webstatus, Backend-Regeln und Datenbankarbeit, statt beim ersten sichtbaren Symptom anzuhalten.
Der ZielkonfliktDas braucht mehr Untersuchung als ein Patch am ersten langsamen Bauteil, verhindert aber, dass nur der Engpass verschoben oder ein falsches Symptom behoben wird.
Kompatibilität zum Abnahmekriterium machen
Eine Änderung wird erst abgenommen, wenn sie im Web-ERP und in den älteren Desktop- und Kassenwegen funktioniert, die dieselben Daten nutzen. Stored Procedures, Views, Reports und Kurier-Austausch gehören dazu, sobald der Ablauf sie berührt.
Der ZielkonfliktDie Abnahmefläche ist grösser als das bearbeitete Bauteil, doch ein lokaler Erfolg kann nicht unbemerkt einen anderen täglichen Weg beschädigen.
Im tatsächlichen Kundenablauf definieren, was fertig ist
Kundengespräche übersetzen eine Anforderung vor der Änderung in konkrete Abläufe, Randfälle und Abnahmeprüfungen. Geliefert ist sie erst, wenn das Ergebnis wieder zur täglichen Nutzung passt, nicht wenn eine einzelne Komponente isoliert funktioniert.
Der ZielkonfliktDiese Definition von fertig kostet Koordinationszeit, ist aber günstiger als eine technisch stimmige Interpretation, die nicht zum tatsächlichen Retailprozess passt.
Support und Schulung als Release-Feedback nutzen
Fragen aus Support und Schulung halten Anforderungen mit der Art verbunden, wie Menschen die Arbeit verstehen und ausführen. Dieses Feedback prägt die nächste klar begrenzte Korrektur oder Verbesserung.
Der ZielkonfliktDie Verantwortung für Lieferung endet nicht mit dem Merge, doch Verständnishürden werden sichtbar, solange sie das nächste Release noch beeinflussen können.
Delivery und Prüfung.
Jede Änderung wurde in ihrer Schicht und im Betriebsablauf geprüft: Stored Procedures und Views, .NET-Regeln, Kurierantworten, Crystal Reports und KnockoutJS-Status mussten zusammenpassen.
Datenbankarbeit verlangte zusätzlich eine Kompatibilitätsfrage: Was lesen oder schreiben VB6-ERP und Kassenanwendung nach dieser Änderung? Ohne Migrationen musste die Antwort im Design liegen und durfte nicht auf Rollout-Automation verschoben werden.
Direktes Kundenfeedback vervollständigte die Prüfung der täglichen Abläufe. Eine technisch korrekte Änderung war nicht fertig, wenn sie Routinearbeit schwerer verständlich machte oder nicht mehr zu dem von den Benutzern beschriebenen Betrieb passte.
Das qualitative Ergebnis.
Das dokumentierte Ergebnis war kein einzelner Modernisierungsstart, sondern eine Reihe klar begrenzter Änderungen an Anwendungsfunktionen und Fehlern, SQL-Server-Prozeduren und -Views, Crystal Reports, zwei Kuriereinbindungen und Abläufen für den Wareneingang.
Jede Änderung wurde im Webpfad und, sobald gemeinsame Datensätze betroffen waren, gegen den Datenbankvertrag des VB6-Desktop-ERP und der Kassenanwendung geprüft. So konnte sich das Web-ERP weiterentwickeln, ohne so zu tun, als würde nur eine Anwendung auf das gemeinsame Schema zugreifen.
Diese Fallstudie behauptet keine gemessene Steigerung von Performance oder Zuverlässigkeit. Sie dokumentiert die Liefermethode für das laufende System: den Betriebsablauf mit dem Kunden nachverfolgen, Kompatibilität an den betroffenen Grenzen definieren und den vollständigen Änderungsschnitt prüfen, bevor er als abgeschlossen gilt.
Organisation, Produkt, Benutzer, Anbieter, kommerzielle Daten, KPIs und Liefertermine sind weggelassen. Technologien und Integrationsgrenzen stammen aus der Projektdokumentation.