Realtime ohne Neubau

Manche Anforderungen sehen aus, als verlangten sie ein neues System, und verlangen bei näherem Hinsehen nur einen neuen Weg durch das alte. Diese Geschichte handelt von einer solchen Anforderung. Sie ist bewusst allgemein gehalten — ohne System, ohne Beteiligte, ohne Zeitpunkt.

Situation

Ein über Jahre gewachsenes System auf einem älteren Framework-Stand tat, wofür es gebaut war: Es holte Daten über externe Schnittstellen, importierte sie und zeigte sie an. Nun kam eine neue Anforderung — die Oberfläche sollte sich nach diesen Importen in Echtzeit aktualisieren, statt erst beim nächsten Aufruf. Für Echtzeit war die Architektur nie entworfen.

Ausgangsannahmen

Der naheliegende erste Gedanke war, dass ein System, das nie für Echtzeit gedacht war, dafür neu gebaut werden müsse. Echtzeit fühlte sich wie eine Eigenschaft des Ganzen an — etwas, das man einem bestehenden Entwurf nicht nachträglich beibringt, sondern von Grund auf einplant. Unter dieser Annahme schien der Neubau die ehrliche Antwort.

Problem

Ein Neubau hätte Jahre korrekt laufender Fachlichkeit weggeworfen, um eine einzige neue Anforderung zu bedienen. Er wäre teuer und riskant gewesen und hätte alles andere angehalten, während man Bekanntes noch einmal baut. Der Preis stand in keinem Verhältnis zur Anforderung — man hätte ein ganzes Haus abgerissen, um ein Fenster zu öffnen.

Ursache

Bei näherem Hinsehen betraf die Anforderung nicht das ganze System, sondern einen einzigen Pfad: wie importierte Daten den Weg zur Oberfläche finden und wie die Oberfläche von einer Änderung erfährt. Die Annahme „Echtzeit heißt neue Architektur" verwechselte einen lokalen Bedarf mit einem globalen Umbau. Das System musste nicht anders sein — nur ein Weg durch es hindurch musste neu gedacht werden.

Entscheidung

Statt neu zu bauen, wurde der Datenfluss und die Aktualisierung der Oberfläche gezielt neu entworfen — genau der Weg vom Import zur Anzeige — und der Rest unangetastet gelassen. Die Entscheidung war, das Kleine zu ändern, das die Anforderung wirklich berührte, nicht das Große, das sie nur zu berühren schien.

Umsetzung

Der Umbau blieb bewusst eng umrissen. Es wurde bestimmt, an welcher Stelle importierte Daten eintreten; von dort wurde ein Weg geschaffen, der die Oberfläche über Änderungen benachrichtigt; und die Oberfläche wurde so angepasst, dass sie Aktualisierungen entgegennimmt, sobald sie eintreffen. Das bestehende System tat weiter, was es tat — nur der Aktualisierungspfad war neu. Klein, begrenzt, umkehrbar.

Trade-offs

Der nachgezogene Pfad ist nicht der eleganteste, den man auf einem leeren Blatt für ein echtzeitnatives System entwerfen würde; er liegt neben älteren Annahmen und trägt ein wenig von deren Erbe mit. Das war der bewusste Preis dafür, die Anforderung ohne die Kosten und das Risiko eines Neubaus zu erfüllen. Anders hätten wir entschieden, wenn Echtzeit das ganze System durchzogen hätte oder die alte Architektur jede Änderung aktiv bekämpfte — dann wäre ein tieferer Umbau die ehrlichere Antwort gewesen.

Was wir gelernt haben

Eine moderne Anforderung verlangt selten ein modernes System. Die meisten „das kann die Architektur nicht"-Reflexe verwechseln eine lokale Fähigkeit mit einem globalen Neubau. Die brauchbare Frage ist nicht „wurde das System dafür gebaut?", sondern „welcher Pfad muss sich wirklich ändern?" — und dieser Pfad ist fast immer viel kleiner als das System. Wer zuerst den Pfad sucht statt das System zu verurteilen, findet meistens eine Lösung, die um Größenordnungen billiger ist.

Wie das Batunet verändert hat

Seither begegnen wir dem Satz „dafür war die Architektur nicht gebaut" mit einer kleineren Frage zuerst: Welchen einzelnen Fluss berührt die Anforderung? Der Neubau ist damit von der ersten Reaktion zur letzten Option geworden. Wir prüfen, was wirklich neu sein muss, bevor wir etwas für alt erklären.

Weiterführend

• Guide: Legacy-Modernisierung ohne Big Bang — warum man Bestehendes in kleinen Schritten weiterentwickelt statt es zu ersetzen.
• Playbook: Einen Legacy-Monolithen modernisieren — das Vorgehen für gezielte Eingriffe statt Neubau.
• Guide: Software, die in zehn Jahren noch läuft — warum Änderbarkeit den Wert eines Systems über die Zeit bestimmt.
• Decision: Modularer Monolith als Ausgangspunkt — Struktur ändern, wo ein Problem sie verlangt, nicht überall.

Grundlage ist die Batunet Engineering Method: an den Eigenschaften des Problems entscheiden, in kleinen, umkehrbaren Schritten bauen.

Bevor man ein System für unfähig erklärt, lohnt die kleinere Frage: Welcher einzelne Weg durch es hindurch muss sich wirklich ändern? Er ist fast immer kürzer als der Weg zum Neubau.