Von TBWaage zu TBScale: Warum wir unsere Wiegesoftware von Grund auf neu entwickelt haben
1998 geboren, über 25 Jahre im Dauereinsatz — und dann die Entscheidung: kein Weiterbau, sondern Neuentwicklung. Ein Einblick in die Architektur-Entscheidungen hinter unserer neuen Wiegesoftware.
1998 haben wir TBWaage ausgeliefert — unsere erste Wiegesoftware für die Schüttgutbranche. Sie hat über 25 Jahre lang in Werken gewogen, Lieferscheine gedruckt und Fakturen gefüttert. Software, die ein Vierteljahrhundert produktiv läuft, macht vieles richtig. Und trotzdem haben wir 2023 entschieden: Wir bauen sie nicht weiter. Wir bauen sie neu.
Dieser Beitrag erzählt, warum — und welche Architektur-Entscheidungen hinter TBScale stecken.
Warum überhaupt neu?
Die ehrliche Antwort: TBWaage war nicht kaputt. Sie war ausgereift, stabil, von hunderten Anwendern täglich genutzt. Aber sie stand auf einem technologischen Fundament, das seine Grenzen erreicht hatte:
- Neue Anforderungen passten strukturell nicht mehr hinein — Selbstbedienung, Kennzeichenerkennung, digitale Lieferscheine und REST-Schnittstellen waren in einer Architektur aus den späten Neunzigern nur mit wachsendem Aufwand nachrüstbar.
- Jede Erweiterung wurde teurer — nicht linear, sondern spürbar überproportional. Das klassische Zeichen, dass ein System sein Design-Budget aufgebraucht hat.
- Die Hardware-Landschaft hatte sich verändert — Touch-Terminals, IP-Kameras, moderne Waagenelektronik. Die Schnittstellen von damals waren dafür nie gedacht.
Ein Rewrite ist trotzdem die teuerste und riskanteste Option, die es in der Software-Entwicklung gibt. Wir haben sie bewusst gewählt — mit einer Bedingung an uns selbst: Die Neuentwicklung muss alles können, was die alte konnte, bevor sie irgendetwas Neues kann. Ein Werk, das seit 20 Jahren mit unserer Software wiegt, verzeiht keine Regression.
Die Architektur-Entscheidungen
- Ein Stack, durchgängig
TypeScript im Frontend wie im Backend. Ein Team, eine Sprache, geteilte Typen von der Waage bis zur Oberfläche — Schnittstellen-Missverständnisse verschwinden auf Compiler-Ebene.
- PostgreSQL als Fundament
Relationale Integrität ist bei Wiegedaten nicht verhandelbar. Jede Wiegung ist ein rechtlich relevanter Vorgang — Transaktionssicherheit, Constraints und nachvollziehbare Historie kommen aus der Datenbank, nicht aus Anwendungscode.
- Wenige Drittpakete, viel Kontrolle
Jede Dependency ist eine Wette auf fremde Wartung. Bei Software, die 20+ Jahre leben soll, wetten wir lieber auf uns selbst — Kernfunktionen entstehen im Haus.
- Hardware-Anbindung als eigene Schicht
Waagenelektronik, Drucker, Terminals, Kameras — sauber isoliert hinter einer Abstraktionsschicht. Neue Hardware heißt: ein Adapter, nicht ein Umbau.
Der schwierigste Teil war nicht der Code
Wer eine Legacy-Modernisierung plant, unterschätzt fast immer denselben Punkt: Das Wissen steckt nicht in der alten Codebasis — es steckt in den Sonderfällen. 25 Jahre Werks-Realität bedeuten 25 Jahre Randfälle: die Waage, die bei Minusgraden anders kalibriert; der Kunde mit dem historischen Konditionsmodell; der Lieferschein-Druck, der auf genau einem Druckermodell anders umbricht.
Parallelbetrieb statt Stichtag
Ein Big-Bang-Wechsel („Freitag alte Software, Montag neue“) war für uns nie eine Option. Stattdessen:
- Pilot-Werke liefen TBScale zuerst parallel zur Bestandssoftware — gleiche Wiegungen, beide Systeme, Ergebnisse verglichen
- Modul für Modul produktiv — erst die Kern-Verwiegung, dann Selbstbedienung, dann die Spezialfälle
- Rückweg offen halten — jedes Pilot-Werk hätte jederzeit zurückwechseln können. Das nimmt Druck raus, auf beiden Seiten.
2025 sind TBScale und das Selbstbedienungs-Terminal TBTouchScale in den Live-Betrieb gegangen. Der Moment, in dem das erste Werk komplett umgestellt hat und die Woche danach schlicht ereignislos war — das war der eigentliche Erfolg.
Was bleibt
Die wichtigste Erkenntnis aus zwei Jahren Neuentwicklung: Software für die Baustoffbranche wird nicht im Büro fertig, sondern an der Waage. Man kann Architektur planen, Stacks evaluieren und Schichten sauber schneiden — ob es trägt, entscheidet sich beim ersten Fahrzeug in der Einfahrt um 5:40 Uhr morgens.
Deshalb steht bei uns jede Architektur-Entscheidung unter demselben Vorbehalt wie 1998: Sie muss im Werk funktionieren. Alles andere ist Deko.
Alle Beiträge aus der Entwicklung.
Wie wir Software bauen, konzipieren und entscheiden — regelmäßig neue Einblicke aus dem Maschinenraum von TBSoft.