ENGINEERING · 02 / 06
Software entsteht hier für Abläufe, die es tatsächlich gibt: eine Fachanwendung, ein internes Werkzeug, eine Schnittstelle zwischen zwei Systemen, eine Auswertung, die bisher von Hand zusammengetragen wird. Der Maßstab ist nicht die Zahl der Funktionen, sondern ob der Code in zwei Jahren noch gefahrlos geändert werden kann. Deshalb gehören Tests, Migrationen, Protokollierung und Dokumentation zum Umfang und nicht in eine spätere Phase.
Ausgangslage
Viele Fachprozesse laufen über eine Tabelle, die über Jahre gewachsen ist: dreißig Blätter, verschachtelte Formeln, ein paar VBA-Makros und eine Person, die weiß, warum Spalte AB nicht überschrieben werden darf. Sobald zwei Personen gleichzeitig schreiben, entstehen Kopien mit Namen wie Planung_final_v3. Es gibt keine Historie, keine Rechteverwaltung und keine Möglichkeit, einen früheren Stand zu rekonstruieren.
Andere Systeme laufen, lassen sich aber nicht mehr anfassen. Die Fachlogik steckt in Klick-Handlern und Controller-Methoden, es gibt keine Tests, und niemand kann die Anwendung lokal starten, weil sie eine über Jahre gewachsene Serverkonfiguration voraussetzt. Jede Änderung wird deshalb direkt am Produktivsystem ausprobiert. Das Ergebnis ist Stillstand: eine sinnvolle Erweiterung wird verschoben, weil das Risiko niemand abschätzen kann.
Schnittstellen entstehen häufig als Notlösung und bleiben es. Nachts schiebt ein Skript eine CSV-Datei per FTP, ein zweites liest sie ein, und wenn eine Zeile ein Semikolon im Freitextfeld enthält, bricht der Import ab – ohne Meldung. Weil kein Lauf idempotent ist, erzeugt der Wiederholungsversuch doppelte Datensätze. Auffällig wird das erst Tage später in der Buchhaltung.
Und schließlich die Übergabe. Wenn Wissen nur im Kopf eines externen Entwicklers liegt, ist der Code faktisch nicht Ihr Eigentum, auch wenn der Vertrag es so vorsieht. Fehlende README-Datei, Zugangsdaten im Quellcode, kein dokumentiertes Deployment, keine Begründung für zentrale Entscheidungen: Ein internes Team braucht dann Monate, bevor es überhaupt gefahrlos etwas ändern kann.
Vorgehen
Am Anfang steht der reale Ablauf, nicht ein Funktionskatalog. Wir lesen die vorhandene Tabelle oder das Access-Backend, prüfen das bestehende Datenbankschema und sehen den Personen bei der Arbeit zu, die das Werkzeug später benutzen. Daraus entsteht ein schriftlich fixiertes Domänenmodell mit Begriffen, die im Unternehmen tatsächlich verwendet werden, und eine bewusst kleine erste Ausbaustufe, die produktiv gehen kann.
Fachlogik bleibt von Framework, HTTP und Benutzeroberfläche getrennt, damit sie ohne laufenden Server prüfbar ist. Datenintegrität gehört ins Schema: Fremdschlüssel, NOT NULL, CHECK-Constraints und eindeutige Indizes in PostgreSQL 17 statt Regeln, die nur im Anwendungscode existieren. Schemaänderungen laufen ausschließlich über versionierte Migrationsdateien im Repository, sodass jede Umgebung denselben Weg nimmt – auch die Entwicklungsdatenbank einer neuen Kollegin.
Getestet wird dort, wo Fehler teuer sind: Domänenlogik über Unit-Tests, Persistenz und Schnittstellen über Integrationstests gegen eine echte PostgreSQL-Instanz im Container statt gegen Attrappen. Die Pipeline führt bei jedem Push Linter, statische Analyse – tsc, mypy oder go vet – und die vollständige Testsuite aus. Ein Build, der durchläuft, ist damit eine belastbare Aussage und kein Ritual.
Betreibbarkeit ist Teil der Entwicklung. Konfiguration kommt aus Umgebungsvariablen, Logs sind strukturiert, ein Health-Endpunkt macht den Zustand abfragbar, und der Start erfolgt lokal wie in Produktion über dieselben Container-Images. Im Repository liegen README, Migrationen, Testdaten und kurze Entscheidungsnotizen unter docs/adr, die festhalten, warum eine Variante gewählt wurde. Übergabe heißt dann Lesen und Nachfragen statt Rekonstruktion.
Leistungsumfang
01
02
03
04
05
06
Einsatzfälle
Mehrere Personen arbeiten gleichzeitig an derselben Datei, Stände laufen auseinander, und den Auswertungen traut niemand. Der Ablauf selbst ist tragfähig und wird in eine Anwendung mit Datenbank, Rollen und Historie überführt.
Die Software läuft seit Jahren, hat aber keine Tests und kein lokales Setup. Vor der neuen Funktion entstehen ein reproduzierbares Entwicklungsumfeld und Tests für die Bereiche, die angefasst werden.
ERP, Warenwirtschaft und Shop kennen sich bisher nur über einen nächtlichen Dateiabgleich. An dessen Stelle tritt eine dokumentierte Schnittstelle mit klarer Regelung für Feldabbildung, Fehlerfälle und Wiederholung.
Jeden Monat werden Daten aus mehreren Quellen von Hand zusammengeführt, geprüft und verschickt. Der Ablauf wird als Job abgebildet, der jeden Schritt protokolliert und bei Abweichungen aktiv meldet.
Ergebnis
Ablauf
Fragen
Einen Pauschalpreis gibt es nicht, weil der Aufwand fast vollständig von Schnittstellen zu Fremdsystemen, Datenmigration und Berechtigungslogik bestimmt wird – nicht von der Zahl der Bildschirmmasken. Wir schneiden deshalb eine erste, klar umrissene Ausbaustufe heraus und schätzen sie getrennt. Nach deren Auslieferung liegen belastbare Erfahrungswerte für alles Weitere vor.
Immer dann, wenn Ihr Ablauf dem Standard folgen kann. Buchhaltung, Lohnabrechnung und klassisches CRM sind gelöste Probleme, hier ist Eigenentwicklung teurer und riskanter. Individuelle Entwicklung rechnet sich, wenn ein Produkt nur den größeren Teil abdeckt und die Anpassungen samt ihrer Pflege über Versionswechsel hinweg mehr Aufwand verursachen als eine eigene, schlanke Anwendung.
Ja, darauf ist die Arbeitsweise ausgelegt. Quellcode, Migrationen, Testdaten, Infrastrukturdefinition und Dokumentation liegen in Ihrem Repository, der Stack besteht aus offenen Komponenten ohne Lizenzschlüssel. Zur Übergabe gehören eine gemeinsame Durchsprache der Architektur und die Entscheidungsnotizen, die erklären, warum etwas so gebaut ist.
Zuerst wird die vorhandene Datei zur Spezifikation: Formeln, Sonderfälle und stillschweigende Regeln werden dokumentiert und mit den Fachanwendern bestätigt. Danach laufen Altlösung und neue Anwendung eine definierte Zeit parallel, gefüttert aus demselben Datenbestand, und ein Abgleich zeigt jede Abweichung. Erst wenn die Ergebnisse übereinstimmen, wird die Tabelle schreibgeschützt.
Ausschlaggebend sind die Anforderung und die Frage, was Ihr Team langfristig betreuen kann. TypeScript passt für Weboberflächen und Node-Dienste, Python für Datenverarbeitung und Auswertung, Go für langlaufende Dienste mit einfachem Deployment, PHP dort, wo eine bestehende Anwendung weitergeführt wird. Als Datenbank ist PostgreSQL der Standardfall, Redis kommt hinzu, wenn Warteschlangen oder Caching wirklich gebraucht werden.
Verwandte Leistungen
03 / 06
ARCHITECTURE
01 / 06
OPEN SOURCE
05 / 06
DELIVERY
Fachartikel dazu
Warum der Big-Bang-Rewrite scheitert und wie Altsysteme im laufenden Betrieb umgebaut werden: Sicherheitsnetz, Nähte, Strangler Fig, Datenbankmigration.
Quellcode, Kostenverlauf, Support, Exit-Kosten: ein sachlicher Entscheidungsrahmen für die Wahl zwischen Open Source, proprietärer Software und Mischformen.
Continuous Integration, Delivery und Deployment sauber getrennt: Pipeline-Stufen mit Laufzeitzielen, Artefakt-Weitergabe, Rollback, Feature Flags und DORA-Metriken.
Kontakt
Beschreiben Sie kurz Ihr System und die offene Frage. Wir antworten mit einer fachlichen Einschätzung – ohne Vertriebsschleife.