Hallo zusammen,

ich möchte in der Plauderecke eine Architekturdiskussion anstoßen – bewusst ohne konkretes Produkt‑ oder Framework‑Bashing.

Ausgangspunkt ist ein privates Projekt / Showcase, bei dem ich mich gefragt habe:
Wie müsste man Software heute entwerfen, wenn sie 20 Jahre unverändert betreibbar sein soll?

Statt „State of the Art 2026“ habe ich daher ein paar bewusste Gegenentscheidungen getroffen:

• stabiler Kern (PostgreSQL, klar definierte Domänenlogik)
• Service‑Schicht in Go (kompiliert, wenig Abhängigkeiten)
• Zugriff über mehrere sehr unterschiedliche Clients:
– Web (Browser)
– native Clients (C#, C++20)
– Terminal‑Zugriff (TN3270), testbar sogar auf sehr alter Hardware
• Druck/PDF‑Erzeugung nicht über Office‑Reports, sondern über eine textbasierte Build‑Pipeline (groff) in Docker

Der Retro‑Teil ist dabei weniger Nostalgie als Härtetest:
Wenn eine Anwendung über blockorientierte Terminals funktioniert, erzwingt das automatisch klare Datenmodelle und saubere Schnittstellen.

Mich interessiert nicht „retro vs. modern“, sondern die Frage:

Welche Teile heutiger Softwarearchitektur sind wirklich langlebig – und welche sind es nur, weil wir sie alle benutzen?

Wie seht ihr das aus eurer Praxis?
Gibt es aus eurer Sicht Architekturprinzipien, die den letzten 15–20 Jahren tatsächlich standgehalten haben?

Technologiepapier_Manifest_MovieSystem_v1.pdf

Ein sehr spannendes Thema!

Im Paper selbst schreibst du <Ziel ist nicht „anti‑Microsoft/anti‑Apple“ [...]> ich denke dazu, daß es bei dem Ruf nach Langlebigkeit so ist, daß Microsoft-/Appleprodukte dann nur als Clients zum Einsatz kommen können, weil die ja Funktionen/Kompatibilitäten in manchmal in kürzester Zeit abschalten. Dann müsste das ganze Backend als OpenSource gestaltet sein. Hast du dir Project Nomad schon mal angesehen? Das könnte ja ggf. um die von dir gewünschten Funktionalitäten aufgebohrt werden? Ich hatte da letztes Wochenende bisschen mit rumgebastelt, die Idee an sich ist in jedem Fall super.

Danke für den Hinweis auf das Projekt N.O.M.A.D., das geht auf jeden Fall in die Richtung, die ich grundsätzlich gesucht habe.

Allerdings verfolge ich ein paar Ansätze, in denen sich meine Idee bewusst und grundlegend unterscheidet.

Mein Ziel ist vor allem:

a) eine langfristige Architektur – keine kuratierte Tool‑Sammlung

b) Text‑first – also nicht Browser‑first als primärer Zugang

c) Terminal‑ & Retro‑Zugriff: Ich bin noch im Verein aktiv (Atari ST). Dafür gibt es bei vielen modernen Lösungen – auch bei N.O.M.A.D. – naturgemäß keinen Ansatz

d) 20‑Jahre‑Kompatibilität – das ist für mich der wirklich wichtigste Punkt, der bei vielen bestehenden Lösungen leider fehlt

e) austauschbare Clients – für mich ein absolutes Muss‑Kriterium

N.O.M.A.D. halte ich trotzdem für ein sehr spannendes Projekt, gerade als Referenz dafür, wie viel heute offline‑first und Open‑Source möglich ist. Mein Fokus liegt allerdings etwas stärker auf dem architektonischen Grundgerüst als auf einem integrierten Anwendungspaket.

Wie bewahrt man einen Tropfen vor dem austrocknen? ...

vor 2 Stunden, V___ger hat gesagt:

Wie bewahrt man einen Tropfen vor dem austrocknen? ...

Indem man ihn ins Meer gibt. - aber das ist vielleicht doch etwas zu poetisch für eine Architekturdiskussion. ;)

Der ursprüngliche Ansatz ist in meinen Augen sehr gut durchdacht und setzt trotzdem, Meiner Meinung nach, auf einer Ebene an, die langfristig nicht die stabilste ist.
Denn im Grunde listet auch das Manifest am Ende nur Tools auf: PostgreSQL, Go, groff, TN3270, Docker. Alles gute, bewährte Werkzeugen, Ja. Aber auch Tools, die in 20 Jahren möglicherweise anders aussehen, anders heißen oder durch etwas Besseres ersetzt werden. Damit dann doch wieder eine "kuratierte" Toolsammlung.

Denn was wirklich langlebig ist, ist nicht das Tool, es ist die Logik.

Denn was bedeutet "ein Film"? Was ist "eine Sammlung"? Was bedeutet es, ein Medium eindeutig zu identifizieren? Diese Fragen, die Sprache des Problems selbst, haben sich in den letzten 50 Jahren kaum verändert. Und sie werden das in den nächsten 20 Jahren auch nicht tun.

Das kennt man auch unter dem Begriff "Domain-Driven-Design". Denn die fachliche Beschreibung was ein System tun soll, ist das eigentlich langlebige Artefakt. Denn alles andere, Frameworks, Sprachen, Protokollem, Druckengines sind austauschbar. Solange die Fachlichkeit klar definiert ist.

Deshalb, vielleicht etwas radikal, aber eigentlich konsequent: Die Spezifikation als einziges Artefakt.

Deshalb mit den heutigen Mitteln weiter gedacht, was spricht dagegen, das System auf einem gut formulierten, natürlichsprachigen Prompt aufzubauen? Einer Beschreibung der Logik und nicht der Implementierung.
Die KI darf sich ändern, das Modell dahinter ebenfalls. Aber der Prompt, also die Anforderungsbeschreibung, bleibt konstant.

Ja ja, der Einwand: "Aber die KI ist doch auch ein Tool!" Jup, stimmt. Aber der Prompt in natürlicher Sprache ist eben kein Tool, und der ist die Spezifikation. Und diese bleibt über Generationen wirklich interpretierbar. Denn ein gut geschriebener Satz ist in 20 Jahren noch genauso gültig und lesbar (natürliche Sprache ändert sich nciht so schnell, selbst knapp 1.000 Jahre alte Gedichte und Minnegesänge von Walther von der Vogelweide sind heute noch lesbar), und von jeder zukünftigen Technologie interpretierbar.

Und HTML als Warnung

Was vor 20 Jahren in HTML gebaut wurde, würde heute niemand mehr so bauen. Nicht weil die Anforderungen falsch waren, sondern weil das "Tool" HTML sich verändert hat, und weil die Implementierung die eigentliche Logik eingeschlossen hat wie ein Bernstein. Die Logik ist mit dem Tool zusammengewachsen und damit genauso veraltet.

Das ist das eigentliche Problem bei „20-Jahre-Architekturen": Nicht dass die Tools sich ändern, das ist unvermeidlich. Sondern dass die Logik so tief in die Tools eingebettet wird, dass sie nicht mehr separat überleben kann.

Ws ich sagen will ist nicht, das keine Tools mehr zu verwenden ist, natürlich muss irgendwas gebaut werden. Aber die Investition in Langlebigkeit sollte nicht primär in die Wahl des "richtigen" Tools fließen, sondern in die saubere und werkzeugagnostische Beschreibung dessen, was das System tun soll.

Der Kern ist dann nicht PostgreSQL.

Der Kern ist dann die Antwort auf die Frage: "Was ist eigentlich ein Film in diesem System und welche Regeln gelten für Ihn?"

Sorry, bischen länger geworden die Antwort. ;)

vor 1 Stunde, Enno hat gesagt:

1.000 Jahre alte Gedichte und Minnegesänge von Walther von der Vogelweide sind heute noch lesbar

übersetzbar, bestenfalls. lesbar scheitert schon an diakritischen zeichen die in unserem alphabet nicht vorkommen.

Das Voynich-Manuskript, Rongorongo und Co. lassen grüßen

Danke für den Einwand, der ist absolut berechtigt – vor allem der Hinweis auf Schrift, Diakritik und exakte Reproduktion. Da würde ich gern etwas geraderücken, weil hier aus meiner Sicht zwei Dinge zusammenrutschen, die man trennen sollte.

Ich meine mit der Walther‑von‑der‑Vogelweide‑Analogie nicht, dass natürliche Sprache immer verlustfrei oder eindeutig bleibt. Natürlich braucht es heute Übersetzungen, Kommentare und Kontext – und ja, es gibt Gegenbeispiele wie Voynich oder Rongorongo. Das bestreite ich gar nicht.

Mir geht es eher um den Unterschied zwischen Bedeutung und exakter Reproduktion.

Bei Formularen, Steuerbescheiden oder Zolldokumenten ist exakte Reproduktion das Hauptziel. Da muss das Ergebnis stimmen, idealerweise identisch, und Interpretationsspielraum ist unerwünscht. Dafür sind formale Systeme genau richtig.

Bei Dingen wie Domänenmodellen, Regeln oder Wissen (und dazu zähle ich auch „Was ist ein Film in diesem System?“) ist das Ziel ein anderes: Dass ein Mensch auch in 20 oder 30 Jahren noch nachvollziehen kann, was gemeint war, selbst wenn die konkrete Umsetzung oder das Werkzeug längst weg ist. Das ist dann nicht bitgenau, aber oft erstaunlich robust.

Eine praktische Erfahrung aus meinem Alltag passt da ganz gut:
Ich habe mir einen Monsieur Cuisine gekauft, um überhaupt erst kochen zu lernen. Dabei nutze ich zwei Apps. In der Lidl‑Kochen‑App kann ich Rezepte einfach kopieren, abwandeln und in mein eigenes Kochbuch übernehmen. In der Monsieur‑Smart‑App sind die Rezepte komplett gegen Kopieren gesperrt.

Beides funktioniert – aber nur bei der ersten lerne ich wirklich etwas. In der zweiten führe ich Abläufe aus. Das Rezept ist dort kein Wissen, sondern ein geschützter Prozess.

Und genau diesen Unterschied meine ich auch in der Architektur:
Wenn Logik und Bedeutung zu tief in Tools, Formate oder Workflows eingebaut sind, ist das System zwar bequem, aber kurzlebig. Wenn die Bedeutung zuerst sauber beschrieben ist, kann man sie später immer wieder neu umsetzen – auch mit anderen Werkzeugen.

Kurz gesagt:
Formale, exakte Systeme sind unverzichtbar, aber sie sollten nicht der einzige Träger der Bedeutung sein. Die Bedeutung selbst muss irgendwo leben, wo sie auch Menschen noch verstehen können.

Um zu verstehen, warum ich mich für diesen Stack (Go, Retro-Anbindung, kein modernes Web-UI-Bling-Bling) entschieden habe, möchte ich mein Positionspapier zur Informatikbildung teilen. Mir geht es darum, dass gerade Auszubildende wieder lernen, Systeme zu bauen und zu durchdringen, statt nur Oberflächen zu bedienen. Mein Projekt ist der technische Prototyp für genau diesen didaktischen Ansatz.

Positionspapier_Informatikbildung_Gestaltbare_Systeme.pdf

vor 2 Stunden, tkreutz2 hat gesagt:

Eine praktische Erfahrung aus meinem Alltag passt da ganz gut:
Ich habe mir einen Monsieur Cuisine gekauft, um überhaupt erst kochen zu lernen. Dabei nutze ich zwei Apps. In der Lidl‑Kochen‑App kann ich Rezepte einfach kopieren, abwandeln und in mein eigenes Kochbuch übernehmen. In der Monsieur‑Smart‑App sind die Rezepte komplett gegen Kopieren gesperrt.

Beides funktioniert – aber nur bei der ersten lerne ich wirklich etwas. In der zweiten führe ich Abläufe aus. Das Rezept ist dort kein Wissen, sondern ein geschützter Prozess.

Oh, das ist ein sehr cooles Beispiel. Ich bin einfach zu alt und lebe scheinbar mehr in der Vergangenheit um Beispiele und Analogien zu finden. ;)

Sehe aber dass wir mit unseren Ansichten sehr in die gleiche Richtung denken. Sobald Bedeutung nur noch als geschützter Prozess existiert und nicht mehr als verstehbares Wissen, ist sie langfristig verloren – egal ob Rezept oder Domänenmodell.

Und dein didaktischer Ansatz aus dem zweiten Post macht das für noch runder: Wer Systeme wirklich durchdringen will und soll, muss zuerst verstehen was das System tun soll, bevor er lernt wie man es baut. Die Spezifikation vor dem Stack, sozusagen.

Bearbeitet Samstag um 08:013 Tage von Enno

Ich habe zwei Punkte, die ich gerne einwerfen würde: Einerseits wurde meiner Meinung nach bei Postgres, Go, ... zu kurz gedacht. Das sind ja auch nur Tools, die erstmal irgendwo laufen müssen. Dazu braucht es Compiler und Betriebssystem. Andererseits ist die reine Spezifikation ja auch keine Lösung. Das muss erst noch implementiert werden, ist soweit also nur reine Theorie und in der Praxis unbrauchbar.

Ich stelle mir die Frage: Wozu? Die meisten Programme (sofern nicht zu viele externe Bibliotheken eingebunden werden) werden wohl auch noch in 20 Jahren laufen. Was einmal läuft bricht ja nicht automatisch über Nacht. Docker, VMs & Co erlauben hier auch lange veraltete Software zumindest noch virtuell zu unterstützen. Der Go oder Rustcompiler oder die JVM werden nicht auf einmal magisch verschwinden. Insofern denke ich was Technologien anbelangt tut es vermutlich jede, die man initial im Kopf haben würde. Software die einfach nur in 20 Jahren unverändert laufen soll ist eingefroren in der Zeit und die externen Abhängigkeiten sehr überschaubar. Solange man diese kontrollieren kann, wird auch die Software funktionieren. Natürlich kann man die Abhängigkeiten noch weiter reduzieren, indem man die Schnittstellen, an denen man am ehesten Veränderungen vermutet austauschbar macht.

Wenn ich darüber hinaus noch mehr Sicherheiten will, dann muss man sich vermutlich stark an Open Software orientieren. Wenn du einmal den Sourcecode besitzt, wird es schwer sein, dir den wieder wegzunehmen. Insofern halte ich es schon für sinnvoll auf z.B. Linux, LLVM & Co zu setzen. Ob ich z.B. Postgres einsetze hängt in erster Linie aber auch eher davon ab, welche Daten ich verarbeite und was meine Anforderungen an die Verarbeitung sind, als dass ich maximale Unabhängigkeit will. Sind die Anforderungen nicht allzu hoch und ist Unabhängigkeit wirklich ein Ziel, dann ist so eine (einfache) Datenbank auch schnell selber geschrieben. [Mir ist durchaus bewusst, dass man analoge Argumente auch für OS und Compiler bringen kann, nur das sind noch seltenere Anwendungsfälle].

Schlussendlich bin ich aber auch hier von Hardware und OS abhängig. Was wenn mein OS nicht mehr unterstützt wird? Was, wenn es keinen Support für die Hardware gibt? Alte Hardware läuft nicht für immer und auch hier muss vorgesorgt werden. Klar wird es vermutlich Linuxtreiber für die Hardware geben - und wenn nicht, dann sind diese auch schnell selbst geschrieben. Aber diese Diskussion ist ein Fass ohne Boden. Wo hört man auf?

Das Positionspaper finde ich im Übrigen richtig gut. Es stößt mir schon länger auf, dass Informatik mit "Tools lernen" gleichgesetzt wird. Module wie "Betriebssysteme" oder "Computerarchitektur", aber auch theoretische Informatik sind auch unter Studenten eher unbeliebt. Ich denke oft, dass sich Leute "früher" vielleicht besser mit der Materie ausgekannt haben, weil weniger Abstraktion dazwischen war, weniger Resourcen verfügbar waren und die Leute so kreativer sein mussten. Und das gilt nicht nur für Informatik. Ob BASIC oder der Nano-Pi genau die richtige Abstraktionsebene für den Einstieg sind, darüber lässt sich sicherlich streiten. Dennoch bin ich ein großer Fan!

Bearbeitet vor 11 Stunden11 h von 0x00

Ein Bild, das mir hilft:

Ich denke Architektur eher wie eine loseblättrige Wissenssammlung als wie ein eingefrorenes Programm.

Seiten können ergänzt oder ersetzt werden, aber das Buch als Ganzes bleibt lesbar – auch wenn manche Kapitel aus unterschiedlichen Jahrzehnten stammen.

Im KI‑QS‑System denke ich Architektur inzwischen wie eine Art externer Speicher fürs Denken:
Entscheidungen, Zustände und Argumente müssen außerhalb des flüchtigen Tools liegen.

Die Software selbst wird damit zu etwas Lebendigem –
nicht, weil sie ständig neu ist, sondern weil sie Gedanken und Strukturen über Zeit konserviert, auch wenn sich die Werkzeuge ändern.

Meine Erfahrung ist, dass Softwarearchitektur oft sehr abstrakt gelehrt wird –
der Bezug zu konkreten Best‑Practice‑Methoden und realen Entwicklungsprozessen fehlt dabei häufig.

Ich arbeite aktuell an einem Pilotprojekt mit zwei Säulen:
zum einen an einem KI‑QS‑System, zum anderen an einem Living‑Dokumentationssystem, das die Architektur während ihrer Entstehung kontinuierlich mitdokumentiert.

Ziel ist es, aus einer zunächst persönlichen Loseblattsammlung
in fest definierten Zyklen ausgewählte Kapitel zu konsolidieren und dauerhaft zu binden –
während der Rest weiter evolviert.

Architektur wird damit nicht nur beschrieben, sondern über Zeit nachvollziehbar gemacht.

Ein Aspekt aus meinem aktuellen Architekturentwurf:
Ich trenne bewusst zwischen einem deterministischen Kern (Zustände, Entscheidungen, Verlauf)
und probabilistischen Randkomponenten (z. B. KI‑Tools),
die jederzeit austauschbar oder abbrechbar sind, ohne den Gesamtzustand zu gefährden.

Das hat sich gerade bei KI‑Systemen als extrem hilfreich erwiesen.

Bearbeitet vor 4 Stunden4 h von tkreutz2