Welche Architekturfragen ins Team gehören und welche nicht.

📌 Konferenz-Tipp: TACON 2026 in Leipzig (16.–17. September). Ich war letztes Jahr als Keynote dort und fand den Austausch richtig gut 👉 https://swt.fm/tacon

„Vom Monolith zum Microservice komme ich einfach, weil ich muss ja nur doch auseinanderschneiden. In der Theorie ja, in der Praxis vergiss es." - Ralf Enderle

Architektur, die auf Papier perfekt aussieht, ist oft schon überholt, bevor das erste Team damit arbeitet. Mit Ralf Enderle spreche ich darüber, warum das kein unvermeidbares Schicksal ist, sondern eine Frage der richtigen Unterscheidungen. Wir reden darüber, welche Entscheidungen wirklich unumkehrbar sind und welche man getrost der Realität des Projekts überlassen kann, ohne dass die Architektur dabei auseinanderfällt. Mich hat beschäftigt, wie Ralf das auf den Punkt bringt: Entscheidungen, die niemand kennt und die sich nirgends verteidigen, helfen keinem. Wie eine Architektur lernen kann, sich selbst zu melden, wenn sie gebrochen wird, und was Tester dabei konkret einbringen können, das nehme ich aus diesem Gespräch mit.

Ralf Enderle ist Senior Software Architekt sowie AI driven development Evangelist bei eXXcellent solutions. Er ist branchen- und technologieübergreifend unterwegs und unterstützt Projekte in der Konzeption und Weiterentwicklung. Sein Fokus liegt dabei auf der effizienten Entwicklung und dem Schaffen von Synergien über Projekte hinweg. Er ist stetig auf der Suche nach innovativen, soliden und nachhaltigen Lösungen und Konzepten – neue Themen und Trends finden bei ihm immer ein offenes Ohr.

Highlights:

Architekturdokumente, die nur in einem Wiki liegen, verteidigen sich nicht selbst: Erst wenn ADRs und Fitness Functions automatisiert prüfbar gemacht werden, schützen sie die Architektur aktiv vor Verletzungen.
Typ-1-Entscheidungen wie die Wahl zwischen Monolith und Microservice lassen sich in der Praxis kaum umkehren und müssen deshalb mit klarem Begründungsrahmen festgelegt und dauerhaft verteidigt werden.
Typ-2-Entscheidungen wie die Wahl des Logging-Frameworks dürfen und sollen sich ändern, wenn Team-Feedback oder Metriken dagegen sprechen, weil ihr Impact die Architektur nicht gefährdet.
Architektur-Gremien sollten ausschließlich Typ-1-Entscheidungen diskutieren, weil Typ-2-Themen dort Evolution blockieren, die das Team im direkten Austausch einfach zulassen könnte.
KI kann helfen, weiche Architekturregeln technisch prüfbar zu machen: Sie erkennt im Kontext, ob ein Catch-Block zwar geloggt, dabei aber sensible Daten wie Kreditkartennummern offengelegt werden.