Unser Ansatz
Wir ändern Anwendungen so, dass die kritischen Abläufe, Daten und Integrationen des Unternehmens weiter funktionieren.
Eine Änderung an einer laufenden Anwendung ist mehr als ein Code-Deployment. Sie kann Bestellungen, Zahlungen, Rechnungen, Berechtigungen, Integrationen und die Arbeit der Mitarbeitenden betreffen. Deshalb klären wir zuerst, welcher Geschäftsprozess ohne Unterbrechung weiterlaufen muss und wann eine Änderung besonders riskant wäre.
Wichtiger Geschäftsprozess
↓
Kleine, klar beschriebene Änderung
↓
Tests und kontrollierte Einführung
↓
Ergebnis prüfen oder korrigierenEin Framework-Upgrade, eine Datenbankmigration, eine neue Oberfläche und eine Zahlungsintegration in einem Release zu bündeln, erschwert die Fehlersuche. Wir teilen die Arbeit lieber in kleinere Schritte. Bei einem Wechsel des Zahlungsanbieters kann der bestehende Checkout zunächst bleiben, während ein separates Zahlungsmodul entsteht und der neue Weg nur für einen begrenzten Teil der Transaktionen aktiviert wird.
Das beseitigt kein Risiko. Es begrenzt die Auswirkungen und macht das Ergebnis leichter nachvollziehbar.
Tests sollen Verhalten abdecken, das für das Unternehmen wichtig ist: Wer darf auf Daten zugreifen? Wird eine Bestellung nur einmal angelegt? Entsteht die Rechnung? Was passiert beim Ausfall eines externen Dienstes? In älteren Systemen können Tests zunächst das heutige Verhalten festhalten, bevor es geändert wird.
Nach dem Release beobachten wir auch den tatsächlichen Betrieb. CPU-Auslastung allein zeigt nicht, ob Zahlungen bestätigt werden, eine Warteschlange wächst oder Kunden eine Bestellung abschließen können.
Zahlungs-, ERP-, CRM- und Versandintegrationen sollten vom übrigen System getrennt bleiben. Ein Anbieterwechsel erfordert dann keine Änderungen an Bestellungen, Rechnungen und Kundenbereich.
Datenbankänderungen planen wir so, dass alte und neue Anwendungsversionen für eine kurze Zeit zusammenarbeiten können. Dieselbe Sorgfalt gilt für Worker, Importe und Benachrichtigungen. Trifft dieselbe Zahlungsnachricht zweimal ein, muss das System sie erkennen und darf keine zweite Bestellung anlegen. Fehler müssen sichtbar und Wiederholungen sicher sein.
Wenn es sinnvoll ist, beginnen wir mit internen Nutzern, einer Organisation oder einer ausgewählten Transaktionsart. Erst nach der Prüfung im Einsatz wird erweitert.
Auch der Weg zurück wird vor dem Release festgelegt. Manchmal genügt die Rückkehr zum vorherigen Code. Wurden Daten geändert oder hat ein externes System bereits neue Informationen erhalten, ist eine kontrollierte Korrektur im laufenden System oft sicherer.
Wir helfen dabei, die Änderung zu begrenzen, kritische Abläufe zu prüfen, Tests und aussagekräftige Signale vorzubereiten und die Einführung zu planen. Ziel ist eine Weiterentwicklung ohne unnötige Störung des Arbeitsalltags, nicht das Versprechen völliger Störungsfreiheit.