DeusterDevelopment

Gedanken über Technik, die langfristig funktioniert

Persönlicher Blog über Technik, die langfristig funktioniert. Beobachtungen zu digitalen Systemen, die Menschen einschließen statt ausschließen.

Systeme für das Altern entwerfen (8/8)

Systeme für das Altern entwerfen (8/8)

Systeme, die altern sollen, müssen ohne ihre Autoren funktionieren — das verlangt langlebige Schnittstellen, vorsichtige Versionierung, ehrliche Dokumentation und das bewusste Vermeiden ephemerer Abhängigkeiten. Legacy ist kein Scheitern, sondern Erfolg, der lange genug angehalten hat, um außer Mode zu kommen. Die Frage beim nächsten Projekt lautet nicht „wird das modern sein?", sondern „kann ich mir vorstellen, dass das in zwanzig Jahren noch läuft, ohne dass mich jemand dafür verflucht?".

Der Strangler Fig und andere ehrliche Strategien (6/8)

Der Strangler Fig und andere ehrliche Strategien (6/8)

Inkrementelle Ablösemuster — Strangler Fig, Anti-Corruption Layer, Parallel Run, Branch by Abstraction — funktionieren, weil jeder Zwischenschritt produktionsfähig bleibt und das Risiko pro Schritt begrenzt ist. Auf Folien wirken sie ineffizient, in der Realität sind sie die einzigen Varianten, die zuverlässig ankommen. Disziplin, nicht Geschwindigkeit, ist das knappe Gut.

Rewrites, die nichts heilen  (5/8)

Rewrites, die nichts heilen (5/8)

Rewrites bleiben verführerisch, weil alter Code fremde Entscheidungen enthält und neuer Code sich nach Fortschritt anfühlt, während die Domäne unverändert bleibt. Die meisten verschieben Komplexität, statt sie zu reduzieren, und beruhen auf emotionaler statt messbarer Begründung. Das Härteste an Software ist nicht, neuen Code zu schreiben, sondern alten zu lesen und zu verstehen, warum er funktioniert.

SAP und die Schwerkraft der Geschäftslogik (4/8)

SAP und die Schwerkraft der Geschäftslogik (4/8)

Eine alte SAP-Installation ist keine Software mehr, sondern eine eingefrorene Darstellung dessen, wie ein Unternehmen seine eigene Arbeit versteht. Der wahre Vendor-Lock-in ist nicht technisch, sondern organisatorisch — jede Ablösung öffnet Entscheidungen, die seit fünfzehn Jahren geschlossen waren. Ehrliche Zeitrahmen liegen bei fünf bis sieben Jahren; wer kürzer verspricht, verkauft.

Warum COBOL 2026 immer noch läuft (2/8)

Warum COBOL 2026 immer noch läuft (2/8)

COBOL läuft in Banken und Versicherungen nicht aus Nostalgie, sondern aus nüchterner Kalkulation: deterministisches Verhalten, keine Dependency-Drift, belegbare Stabilität. Ablöseprojekte scheitern selten an der Sprache, sondern an jahrzehntealten, undokumentierten Geschäftsregeln, die erst beim Umzug sichtbar werden. Die Alternative zu Legacy ist nicht Modernität, sondern Risiko.

Legacy ist kein Defekt, sondern ein Zustand (1/8)

Legacy ist kein Defekt, sondern ein Zustand (1/8)

„Legacy" ist ein soziales Urteil, kein technisches Kriterium — es beschreibt meist nur, dass ein System länger existiert, als die Leute im Raum darüber reden wollen. Alter und Veraltetsein werden routinemäßig verwechselt, obwohl sie nichts miteinander zu tun haben müssen. Die ehrliche Designfrage lautet nicht, wie man Legacy vermeidet, sondern wie man Systeme baut, die diesen Zustand würdig erreichen.

Technik hilft nicht allen gleich - Warum Zugang, Sprache und Vertrauen über die Wirkung von Warnsystemen entscheiden (6/6)

Technik hilft nicht allen gleich - Warum Zugang, Sprache und Vertrauen über die Wirkung von Warnsystemen entscheiden (6/6)

Technische Systeme können Risiken sichtbar machen. Wettermodelle, Karten und Warnplattformen werden immer präziser. Doch ihre Wirkung hängt nicht nur von der Qualität der Daten ab. Sie hängt auch davon ab, ob Menschen Zugang zu diesen Informationen haben, ob sie sie verstehen und ob sie ihnen vertrauen. Dieser Beitrag betrachtet, warum technische Lösungen nicht überall gleich wirken – und welche Rolle Zugang, Sprache und Vertrauen dabei spielen.

Die stille Rolle von Infrastruktur - Warum viele Systeme erst sichtbar werden, wenn sie fehlen (5/6)

Die stille Rolle von Infrastruktur - Warum viele Systeme erst sichtbar werden, wenn sie fehlen (5/6)

Viele technische Systeme bleiben im Hintergrund. Sensoren messen, Pegelstationen übertragen Daten, Netzwerke verbinden Messpunkte mit Modellen. Solange diese Infrastruktur funktioniert, fällt sie kaum auf. Doch ohne sie gäbe es keine Vorhersagen, keine Warnungen und keine Entscheidungen auf Basis verlässlicher Daten. Dieser Beitrag betrachtet die oft unsichtbare Rolle technischer Infrastruktur – und warum ihre Stabilität für viele Systeme entscheidend ist.

Was Google Flood Hub gut macht – unabhängig von Google - Warum gute Risikosysteme Entscheidungen unterstützen statt nur Daten zeigen (4/6)

Was Google Flood Hub gut macht – unabhängig von Google - Warum gute Risikosysteme Entscheidungen unterstützen statt nur Daten zeigen (4/6)

Viele technische Systeme zeigen Daten. Nur wenige helfen dabei, diese Daten in konkrete Entscheidungen zu übersetzen. Plattformen wie Google Flood Hub zeigen, wie Risikoinformation verständlicher werden kann: durch klare Sprache, lokale Perspektive und den Fokus auf Konsequenzen statt Rohdaten. Dieser Beitrag betrachtet, welche Gestaltungsprinzipien solche Systeme nützlich machen – unabhängig davon, wer sie entwickelt.

Warum Warnungen oft ignoriert werden - Wenn Information nicht automatisch zu Handlung führt (3/6)

Warum Warnungen oft ignoriert werden - Wenn Information nicht automatisch zu Handlung führt (3/6)

Frühwarnsysteme werden immer präziser. Wettermodelle, Hochwasserprognosen und Katastrophenwarnungen können Risiken oft früh erkennen. Trotzdem werden Warnungen häufig zu spät ernst genommen oder ignoriert. Dieser Beitrag betrachtet, warum das passiert – und warum die Herausforderung weniger technisch als kommunikativ ist.

Von der Simulation zur Entscheidung- Warum eine präzise Karte noch keine gute Entscheidung ermöglicht (2/6)

Von der Simulation zur Entscheidung- Warum eine präzise Karte noch keine gute Entscheidung ermöglicht (2/6)

Kurzzusammenfassung Simulationen werden immer genauer. Wettermodelle, Hochwasserprognosen und Risikokarten können heute sehr präzise zeigen, was möglicherweise passieren wird. Doch zwischen Simulation und Entscheidung liegt eine schwierige Übersetzung. Daten erklären Situationen – sie treffen jedoch keine Entscheidungen. Dieser Beitrag betrachtet, warum selbst präzise Modelle nicht automatisch zu klaren Handlungen führen und warum der Übergang von Information zu Entscheidung oft der schwierigste Teil eines Systems ist.

Wenn Wetterdaten plötzlich relevant werden - Warum Vorhersagen lange abstrakt waren – und heute konkret werden (1/6)

Wenn Wetterdaten plötzlich relevant werden - Warum Vorhersagen lange abstrakt waren – und heute konkret werden (1/6)

Wetterdaten existieren seit Jahrzehnten. Lange waren sie statistisch, abstrakt und meist nur für Spezialisten relevant. Erst durch bessere Modelle, massive Rechenleistung und offenen Datenzugang werden Vorhersagen heute zu etwas, das Entscheidungen verändert – nicht irgendwann, sondern jetzt. Dieser Beitrag betrachtet, warum Wetterprognosen so lange theoretisch blieben, was sich technisch verändert hat und weshalb sie heute zunehmend Teil von Infrastruktur, Planung und Verantwortung werden.

Technology that assumes change will outlive technology that doesn’t - Warum Anpassungsfähigkeit ein zentrales Designprinzip ist (10/10)

Technology that assumes change will outlive technology that doesn’t - Warum Anpassungsfähigkeit ein zentrales Designprinzip ist (10/10)

Technische Systeme werden oft mit der Erwartung gebaut, stabil zu bleiben. Doch kaum eine Umgebung bleibt über Jahre unverändert. Netzwerke werden abgeschaltet. Standards entwickeln sich weiter. Anforderungen verschieben sich. Dieser Beitrag betrachtet, warum langlebige Systeme nicht auf Stabilität setzen, sondern auf Anpassungsfähigkeit – und warum Technik länger überlebt, wenn sie Veränderung von Anfang an einplant.

Why infrastructure maturity feels boring — and that’s a good sign - Warum reife Infrastruktur oft langweilig wirkt (9/10)

Why infrastructure maturity feels boring — and that’s a good sign - Warum reife Infrastruktur oft langweilig wirkt (9/10)

Neue Technologien wirken spannend. Sie versprechen Geschwindigkeit, Innovation und Veränderung. Reife Infrastruktur dagegen wirkt oft unspektakulär. Sie funktioniert einfach – ohne Aufmerksamkeit zu verlangen. Dieser Beitrag betrachtet, warum genau diese Unauffälligkeit ein Zeichen von technischer Reife ist – und warum Systeme am zuverlässigsten sind, wenn sie kaum bemerkt werden.

Automation is not about efficiency, it’s about survivability - Warum Automatisierung ab einer Schwelle zwingend wird (8/10)

Automation is not about efficiency, it’s about survivability - Warum Automatisierung ab einer Schwelle zwingend wird (8/10)

Automatisierung wird oft als Mittel zur Effizienzsteigerung verstanden. Weniger Arbeit, schnellere Prozesse, geringere Kosten. In großen Systemen ist Automatisierung jedoch keine Optimierung mehr. Sie wird zur Voraussetzung für Stabilität. Dieser Beitrag beschreibt, warum Systeme ab einer bestimmten Größe nicht mehr manuell betrieben werden können – und warum Automatisierung weniger mit Geschwindigkeit als mit Überlebensfähigkeit zu tun hat.

When troubleshooting no longer scales   - Warum man ab einer bestimmten Größe anders denken muss (7/10)

When troubleshooting no longer scales - Warum man ab einer bestimmten Größe anders denken muss (7/10)

In kleinen Systemen löst man Probleme direkt. Man analysiert, korrigiert, dokumentiert – und weiter geht es. Doch ab einer bestimmten Größe funktioniert dieses Muster nicht mehr. Fehler werden statistisch. Ausnahmen werden Normalzustand. Dieser Beitrag beschreibt, warum Troubleshooting nicht unbegrenzt skalierbar ist – und warum große Systeme anders gedacht werden müssen.

Global deployments force simplicity   - Warum globale Systeme weniger Optionen vertragen (6/10)

Global deployments force simplicity - Warum globale Systeme weniger Optionen vertragen (6/10)

Je größer ein System wird, desto stärker wirkt Vielfalt. Unterschiedliche Länder, Netze, Sprachen, Regulierungen und Nutzungskontexte treffen aufeinander. Was lokal noch flexibel wirkt, wird global schnell fragil. Dieser Beitrag betrachtet, warum globale Systeme nicht mehr Optionen, sondern weniger Komplexität brauchen – und warum Einfachheit oft das Ergebnis von Erfahrung ist.

Entwicklung von Systemen für das Überleben von Netzwerk-Sunsets - Wie man Technik baut, die mit Abschaltungen rechnet (5/10)

Entwicklung von Systemen für das Überleben von Netzwerk-Sunsets - Wie man Technik baut, die mit Abschaltungen rechnet (5/10)

Netzwerke verschwinden. 2G, 3G , und irgendwann gehören auch die heutigen Standards dazu. Technische Systeme, die über Jahre oder Jahrzehnte laufen sollen, müssen dafür nicht nur funktionieren. Sie müssen Übergänge überleben. Dieser Beitrag betrachtet, wie man Systeme plant, um mit Infrastrukturwechseln zu rechnen , statt von ihnen überrascht zu werden.

Wenn Infrastruktur ausläuft - Warum 2G und 3G zeigen, dass Technik immer ein Ablaufdatum hat (4/10)

Wenn Infrastruktur ausläuft - Warum 2G und 3G zeigen, dass Technik immer ein Ablaufdatum hat (4/10)

2G- und 3G-Netze galten lange als stabile Grundlage globaler Kommunikation. Heute werden sie weltweit abgeschaltet – nicht, weil sie versagt hätten, sondern weil technische Infrastruktur nie dauerhaft ist. Dieser Beitrag nutzt den Übergang von 2G und 3G als Beispiel dafür, warum funktionierende Systeme dennoch enden, warum solche Übergänge selten technisch, sondern organisatorisch scheitern – und weshalb gute Technik ihr eigenes Auslaufen mitdenken muss.

Warum globale Technik keine lokalen Regeln mag

Warum globale Technik keine lokalen Regeln mag

Globale Software wirkt oft so, als könne sie überall gleich funktionieren. In der Praxis scheitert sie selten an Technik – sondern an lokalen Regeln, unterschiedlichen Behördenwegen und widersprüchlichen Pflichten. Dieser Beitrag erklärt, warum „ein System für alle“ in Europa und weltweit schnell zu „vielen Varianten desselben Systems“ wird, und warum das Systeme lauter, teurer und fehleranfälliger macht.

Wenn Staaten digitale Technik verbiegen

Wenn Staaten digitale Technik verbiegen

Digitale Systeme entstehen oft mit klaren technischen Zielen: Effizienz, Sicherheit, Verlässlichkeit. Sobald Regierungen eingreifen, verändern sich diese Systeme – nicht immer durch offene Zensur, sondern durch rechtliche, technische und organisatorische Vorgaben. Dieser Beitrag sammelt belegte Beispiele dafür, wie staatliche Eingriffe digitale Technik beeinflussen, wo legitime Interessen bestehen und wo Technik dadurch komplizierter, brüchiger oder widersprüchlich wird.

Wenn Konnektivität keine Funktion mehr ist, sondern Voraussetzung (2/10)

Wenn Konnektivität keine Funktion mehr ist, sondern Voraussetzung (2/10)

Viele digitale Systeme wurden mit der Annahme gebaut, dass Konnektivität verfügbar ist – aber nicht zwingend notwendig. Diese Annahme verändert sich. Immer mehr Systeme funktionieren nur noch, *wenn* sie verbunden sind. Dieser Text beschreibt, was passiert, wenn Konnektivität von einer hilfreichen Eigenschaft zu einer stillschweigenden Abhängigkeit wird.