
Sign up to save your podcasts
Or


KI war schon mehrfach Thema im Stream. Doch diesmal geht darum, wie wir sie für den Stream selbst einsetzen: Es gibt jetzt automatische Transkriptionen und Zusammenfassungen.
Diese neuen Features sind mit Hilfe von KI, Prompt-Driven Development und GitHub Copilot entstanden. In dieser Episode sprechen Ralf und Eberhard darüber, wie sie dabei vorgegangen sind und welche Erfahrungen sie gesammelt haben:
Was hat gut funktioniert? Was weniger? Und vor allem – was haben wir über den praktischen Einsatz von LLMs in echten Projekten gelernt?
So stehen in dieser Halloween-Episode keine Kürbisse, sondern Code und KI im Mittelpunkt.
Oliver Zeigermann und Lisa Maria Schäfer sprechen anhand einer Demo-Applikation über das Thema generative KI.
Wardley Maps sind ein visuelles Werkzeug, das dabei unterstützen kann, Systeme im strategischen Zusammenhang zu betrachten und Entscheidungen bewusster zu treffen. In dieser Episode zeigt Markus Harrer, wie sich mit Wardley Mapping Abhängigkeiten in Softwaresystemen nachvollziehbarer darstellen lassen und wie es helfen kann, Architekturentscheidungen besser einzuordnen. Zusätzlich macht er anhand von Beispielen aus der Legacy-Modernisierung deutlich, wie diese Technik genutzt werden kann, um Diskussionen über den Umgang mit gewachsenen Systemen anzuregen und neue Blickwinkel darauf zu eröffnen. Teilnehmende erhalten Anregungen, wie Wardley Maps im Alltag eine strukturiertere und entspanntere Auseinandersetzung mit Softwaresystemen ermöglichen können.
Links
Slides
Workshop-Folien
Markus Harrer zu Software Analytics
Wardley Maps Meets Software Architecture
Markus Blog Top 5 Learning Wardley Maps
Von schlechten Anforderungen haben wir alle bereits gehört! Aber wie kann man als Softwarearchitekt:in mit fehlenden oder unklaren Requirements umgehen? Und wie hängen Anforderungen und Architekturentscheidungen eigentlich zusammen? In dieser Episode beantwortet Peter Hruschka, Mitbegründer von req42 und langjähriger Requirements-Engineering-Experte, diese und weitere Fragen. Das req42-Template bietet eine schlanke, docs-as-code-kompatible Struktur für Requirements-Dokumentation – und lässt sich nahtlos mit arc42 kombinieren. Peter teilt seine Erfahrungen aus Jahrzehnten der Projektarbeit: Vom Übergang zwischen Problemraum und Lösungsraum über die Rolle von Qualitätszielen bis hin zu praktischen Notationen wie PAM. Spoiler: Requirements Engineering und Softwarearchitektur gehören zusammen!
req42 Homepage
Software Architecture Gathering 15% Rabatt mit Code SATV_SAG2515
Peter Hruschka & Gernot Starke - Requirements Engineering
Gäste: Maximilian Franzke & Danny Koppenhagen
Barrierefreiheit ist kein “Nice-to-have” mehr, sondern wird spätestens durch das Barrierefreiheitsstärkungsgesetz (BFSG) seit Mitte 2025 für viele digitale Dienste zur Pflicht. Doch wie integriert man Accessibility erfolgreich in moderne Web-Architekturen? Unsere Gäste Danny Koppenhagen und Maximilian Franzke zeigen, wie sie barrierefreie Web-Anwendungen entwickeln – von der strategischen Architekturentscheidung bis zur praktischen Umsetzung.
Architektur-Impact: Wie beeinflusst Barrierefreiheit eure Frontend-Architektur und Design System-Entscheidungen?
Praktische Umsetzung: Konkrete Patterns und Techniken für barrierefreie Web-Anwendungen
Tooling & Automatisierung: Welche Tools helfen bei der kontinuierlichen Überprüfung von Accessibility-Standards?
Enterprise-Scale: Herausforderungen bei der Umsetzung in großen Organisationen mit mehreren Teams
Performance vs. Accessibility: Wie balanciert man High-Performance-Anforderungen mit Barrierefreiheit?
Rechtliche Aspekte: Was bedeuten WCAG, EAA und BFSG konkret für Entwicklungsteams?
Danny und Maximilian bringen ihre Erfahrung aus der Entwicklung von Design Systemen sowie der Arbeit im BIK BITV Prüfverbund und dem Austausch auf europäischer Ebene mit und zeigen, wie man von Anfang an “accessibility-first” denkt, statt Barrierefreiheit nachträglich “draufzupacken”. Dabei geht es nicht nur um technische Lösungen, sondern auch um organisatorische Prozesse und die Frage: Wie macht man Barrierefreiheit zu einem natürlichen Teil der Softwarearchitektur?
Links - siehe https://software-architektur.tv/2025/10/10/folge282.html
In vielen Projekten werden Security-Anforderungen immer noch top-down definiert – von Architekt:innen oder Security-Spezialist:innen – ohne das Entwicklungsteam oder die Fachseite wirklich einzubeziehen. Das führt zu unvollständigen Schutzkonzepten und Widerstand bei der Umsetzung.
In diesem Vortrag zeigen wir anhand eines vierstufigen Modells, wie Security kollaborativ geplant und integriert werden kann – von der statischen Systemsicht über Schutzbedarfsanalyse und Bedrohungserkennung bis hin zu konkreten Gegenmaßnahmen.
Mit OWASP Cornucopia Security Poker und Domain Storytelling erarbeiten wir greifbare Methoden, wie fachliche Assets, Angriffsvektoren und Schwachstellen teamübergreifend identifiziert und diskutiert werden können.
So entsteht ein Security-Konzept, das nicht nur sicher, sondern auch akzeptiert und verstanden ist – vom Developer bis zum Datenschutzbeauftragten.
Wir haben diese Episode bei BEDcon 2025 aufgezeichnet.
Links
OWASP Cornucopia
Domain Story Telling mit Henning Schwentner und Stefan Hofer
Anstatt den Code jedes Projekts in einem eigenen Repository zu verwalten, fassen Monorepos mehrere Projekte in einem einzigen Repository zusammen. Das hat Vorteile: Projektübergreifende Änderungen lassen sich dadurch deutlich einfacher umsetzen. Unternehmen wie Google oder Uber setzen auf dieses Konzept – und sie wissen vermutlich, warum.
Was auf den ersten Blick vielleicht wie eine großartige Idee wirkt, bringt auch Herausforderungen mit sich. In dieser Episode werfen wir einen Blick auf Ubers Erfahrungen mit Monorepos und was wir daraus lernen können.
Links
Rachel Potvin, Josh Levenberg: Why Google Stores Billions of Lines of Code in a Single Repository
Aron Lorincz, Goncalo Alvarez, Rasmus Vestergaard (Uber): Controlling the Rollout of Large-Scale Monorepo Changes
Rasmus Vestergaard, Kasper Munck (Uber): Continuous Deployment for Large Monorepos
Residuality theory is a revolutionary new theory of software design that aims to make it easier to design software systems for complex business environments. Residuality theory models software systems as interconnected residues – an alternative to component and process modeling. It uses applied complexity science to make managing uncertainty a fundamental part of the design process. In this episode, we will discuss this novel approach with Barry O’Reilly, veteran architect. Barry will also do a workshop and a talk about this subject at the Software Architecture Gathering.
Links
Barry’s book Residues: Time, Change, and Uncertainty in Software Architecture
Barry’s book The Architect’s Paradox to the Books
Software Architecture Gathering 15% off with SATV_SAG2515
3 Day Workshop in Berlin
“Implementiere Feature X” - und schon spuckt das LLM komplexen Code aus, ohne dass du nach der Architektur gefragt hast. Du bekommst funktionsfähigen Code, aber keine Ahnung, warum diese Entscheidungen getroffen wurden. Das Resultat: Du verbringst mehr Zeit damit, generierten Code zu verstehen als das eigentliche Problem zu lösen.
Oliver Jägle, Senior Engineer bei DB Systel, hat eine überraschende Erklärung: Das LLM ist nicht schuld - wir kommunizieren schlecht, was wir brauchen. Mit “Responsible Vibe MCP” demonstriert er, wie ein intelligenter “Conversation State Manager” als digitaler Projektleiter fungiert und LLMs durch strukturierte Entwicklungsworkflows führt.
Statt sofortiger Code-Dumps führt das Tool systematisch durch Requirements-Klärung: Wer sind die Nutzer? Welche Constraints? Welche Features sind kritisch? Das Ergebnis: Durchdachte, begründete Architektur-Entscheidungen statt zufälliger Tech-Stack-Kombinationen.
Ein praktisches Gespräch über die Transformation von Code-generierenden Maschinen zu durchdachten Entwicklungspartnern - durch bessere Kommunikation statt LLM-Zähmung.
Videotitel
Beschreibung
Du kannst deine Beschreibung mit der Markdown-Sprache formatieren:
Zum Beispiel, um Text fett zu setzen (Text in Fettschrift), oder Text kursiv zu setzen (Text in Kursivschrift)
Du kannst außerdem einen Link auf einen spezifischen Zeitstempel des Videos setzen (z.B. 00:05, indem du einfach „00:05“ schreibst) oder einen klassichen Link setzen ([Titel meines Links](https://example.com))
“Implementiere Feature X” - und schon spuckt das LLM komplexen Code aus, ohne dass du nach der Architektur gefragt hast. Du bekommst funktionsfähigen Code, aber keine Ahnung, warum diese Entscheidungen getroffen wurden. Das Resultat: Du verbringst mehr Zeit damit, generierten Code zu verstehen als das eigentliche Problem zu lösen.
Oliver Jägle, Senior Engineer bei DB Systel, hat eine überraschende Erklärung: Das LLM ist nicht schuld - wir kommunizieren schlecht, was wir brauchen. Mit “Responsible Vibe MCP” demonstriert er, wie ein intelligenter “Conversation State Manager” als digitaler Projektleiter fungiert und LLMs durch strukturierte Entwicklungsworkflows führt.
Statt sofortiger Code-Dumps führt das Tool systematisch durch Requirements-Klärung: Wer sind die Nutzer? Welche Constraints? Welche Features sind kritisch? Das Ergebnis: Durchdachte, begründete Architektur-Entscheidungen statt zufälliger Tech-Stack-Kombinationen.
Ein praktisches Gespräch über die Transformation von Code-generierenden Maschinen zu durchdachten Entwicklungspartnern - durch bessere Kommunikation statt LLM-Zähmung.
Links
Responsible Vibe MCP Server bei GitHub
Responsible Vibe MCP Server Dokumentation
In dieser Folge sprechen Lucas Dohmen und Lisa Maria Schäfer über Web Performance. Sie klären, was sich dahinter verbirgt und warum das Thema wichtig ist – und zwar für alle, die Webseiten entwickeln. Des Weiteren stellen sie Tools zum Messen der Web Performance vor und geben euch Impulse, wie ihr eure Website schneller machen könnt.
Links
Lucas Folien
Web-Performance Hands-on Workshop bei Socreatory 20% Rabatt mit PERFORMANCE_25
Web-Performance Quick Check bei SWAGLab
imPuls zu Web-Performance mit Lucas am 25.9. um 17:00
treo: Core Web Vitals and Sitespeed Test
WebPageTest
From the publisher's feed

9 Listeners

223 Listeners

8 Listeners

3 Listeners

6 Listeners

2 Listeners

1 Listeners

181 Listeners

3 Listeners

6 Listeners

17 Listeners

319 Listeners

20 Listeners

3 Listeners

8 Listeners