Kaum ein Software-Projekt kommt heute noch ohne Open-Source-Teile aus. Wie kann man solche Komponenten im Projekt rechtlich und technisch richtig einsetzen? Welche Auswirkungen haben Lizenzen mit einem Copyleft? Was gilt es in Bezug auf Compliance zu beachten? Gerade der EU Cyber Resilience Act bringt das Thema wieder auf die Agenda. Prof. Dirk Riehle ist Professor für Open-Source-Software und diskutiert diese und andere Fragen mit uns.

Links

• Prof. Riehles Trainings

• Prof. Riehles Werkzeuge

• xkcd zu Open-Source-Abhängigkeiten

Software-Architektur gilt als anspruchsvoll und komplex – doch woran liegt das eigentlich?

Auf Mastodon, BlueSky und LinkedIn haben wir gefragt: Was ist die zentrale Herausforderung in der Software-Architektur?

In dieser Episode werfen wir einen Blick auf die Antworten und diskutieren, was Software-Architektur von so herausfordernd macht.

Links

• Umfrage auf BlueSky

• Umfrage auf Mastodon

• Umfrage auf LinkedIn

Letzte Woche haben wir mit Claude in nur einer Stunde eine Architektur für einen Wardley-Map Editor entwickelt. Schnell, spontan, ungeprüft – klassisches “Architektur-Theater” könnte man sagen. Aber was passiert, wenn diese Express-Architektur auf die Realität des Codes trifft?

In dieser Folge testen wir das ultimative “Garbage-In/Garbage-Out” Experiment: Kann Claude Code aus unserer spontanen Architektur funktionierenden Code entwickeln? Oder wird die fehlende Verifikation und Tiefe der Architektur zum Stolperstein?

Mit dabei: Ingo Eichhorst, der als KI-Experte seine Einschätzung zur praktischen Anwendung von LLMs in der Softwareentwicklung einbringt.

Gemeinsam ergründen wir:

• Wie robust sind LLM-generierte Architekturen in der Praxis?

• Wo sind die Grenzen zwischen Architektur-Theorie und Code-Realität?

• Kann Claude Code die Lücken einer “schnellen” Architektur selbst schließen?

• Welche architektonischen Entscheidungen erweisen sich als tragfähig, welche als Luftschlösser?

Ein authentisches Experiment ohne Drehbuch: Werden wir am Ende einen funktionsfähigen Wardley-Map Editor haben – oder lernen wir schmerzhaft, warum gründliche Architektur-Arbeit durch nichts zu ersetzen ist?

Live-Coding meets Architektur-Realitätscheck – mit ungewissem Ausgang.

Links

• Claude-SPARC Script und Web-Tool (autogenerated) Dieses claude-sparc-sh ist gegenüber dem von Reuven Cohen leicht modifiziert: es braucht keine MCP-Tool-Definition uns installiert Claude Code, wenn es noch nicht installiert ist. Dadurch ist es z.B. einfach in einer sicheren Umgebung wie GitHub Codespaces einsetzbar:
• Die dazugehörige Website
• Reuven Cohen auf LinkedIn
• Die Architektur aus dem ersten Teil des Architektur-Theaters
  • GitHub Repo
  • Website
• Der Code aus der Live-Session
• Der Code aus einer vorherigen Test-Session

Ist der Einsatz von LLMs in der Software-Architektur nur Hype und Theater – oder können die LLMs echten Mehrwert schaffen? In dieser besonderen Folge gehen wir einen Schritt weiter als nur darüber zu reden: Wir machen es live!

Unserem Star-Gast Claude (Anthropics LLM) entwickelt unter der Leitung von Ralf in Echtzeit die Architektur für einen Wardley-Map Editor mit draw.io Export-Funktion.

Ihr erlebt hautnah, wie LLMs bei Architektur-Entscheidungen, Struktur-Design und Dokumentation unterstützen – und wo menschliche Expertise unverzichtbar bleibt. Wir fokussieren uns auf die architektonischen Aspekte: Komponenten-Design, Schnittstellen, Datenflüsse und Design-Entscheidungen.

Ein echtes Experiment mit ungewissem Ausgang: Reicht eine Stunde für die Architektur? Bekommen wir vielleicht sogar noch einen funktionsfähigen Prototypen oder ein Proof-of-Concept hin?

Authentisch, ungeschnitten, mit allen Höhen und Tiefen einer echten Architektur-Session.

Spoiler: Am Ende exportieren wir tatsächlich eine Wardley Map nach draw.io – oder scheitern spektakulär beim Versuch.

Links

• GitHub Repo

• Website für das Projekt

Large Language Models (LLMs) wie ChatGPT oder Claude sind in aller Munde und versprechen, auch die Software-Architektur zu revolutionieren. Doch wie nützlich sind diese Tools wirklich für Architekt:innen? Können sie bei der Erstellung von Architekturdokumentationen, Architecture Decision Records oder dem Architecture Communication Canvas helfen? Oder überwiegen die Risiken wie Halluzinationen und fehlendes Verständnis für die Realität? In dieser Folge diskutieren Eberhard Wolff und Ralf D. Müller kontrovers über den Einsatz von LLMs in der Software-Architektur. Sie beleuchten sowohl die Chancen als auch die Fallstricke und diskutieren, wo LLMs helfen können und wo sie versagen. Eine Diskussion zwischen zwei erfahrenen Software-Architekten, deren Meinungen unterschiedlicher nicht sein könnten – mit praktischen Erkenntnissen für alle, die sich fragen: KI-Hype oder echte Hilfe?

Links

• Umfrage zur Nutzung der Website

• Folge KI = Bullshit?

• Dirks Experiment

• Arc42 Dokumentation für den AsciiDoc-Linter

• Francesco Salvi, Manoel Horta Ribeiro, Riccardo Gallotti & Robert West: On the conversational persuasiveness of GPT-4 nature human behavior

• Ziwei Ji, Nayeon Lee, Rita Frieske, Tiezheng Yu, Dan Su, Yan Xu, Etsuko Ishii, Yejin Bang, Delong Chen, Wenliang Dai, Ho Shu Chan, Andrea Madotto, and Pascale Fung (Center for Artificial Intelligence Research (CAiRE), Hong Kong University of Science and Technology, Hong Kong): Survey of Hallucination in Natural Language Generation

• ChatGPT halluziniert immer mehr und OpenAI weiß nicht, warum

• Episode zu Wardley Maps Meets Software Architecture

• Servo verbietet AI-Contributions

• Desaströser Commit von CoPilot an Dot Net

• cURL-Maintainer: "Habe die Nase voll" – wegen KI-Bug-Reports

• ChatGPT beantwortet: Ist der Einsatz von LLMs eine wichtige Maßnahme, um besser und produktiver Software Architekturen zu erstellen oder gibt es andere, erfolgversprechendere Möglichkeiten?

• AsciiDoc Linter

• LLM Prompts for Architecture Documentation

Eigentlich definiert Architektur “nur” die Struktur der Software. Aber das Gesetz von Conway weißt schon auf den Zusammenhang zwischen Architektur und Organisation hin. Durch das Inverse Conway Maneuvre ist klar geworden, dass die geschickte Aufstellung der Organisation die Architektur maßgeblich beeinflussen kann. Dieser Vortrag zeigt auf, dass Team Topologie auch erhebliche Konsequenzen für die Architektur-Arbeit hat: Team Topologies fungiert nicht nur als Werkzeug für Architektur, sondern muss auch in die architektonische Planung einbezogen werden.

Links

• Folien

• D.L. Parnas: Information Distribution Aspects of Design Methodology

• Frederick P. Brooks: The Mythical Man-Month

• Episode zu Modularisierung

• Fachliche Architektur - Warum und wie?

• Episode zu Team Topologies

• Episode zur DevOps Study

• Fearless Change - Neue Ideen etablieren

• Software Architektur - Den menschlichen Faktor verbessern!

Agile Entwicklung verspricht einen besseren Umgang mit Unsicherheit – und doch dominieren in vielen Projekten weiterhin detaillierte Pläne, Feinkonzepte und Architektur mit Big Design Up Front. Warum fällt es so schwer, loszulassen?

Diese Episode beleuchtet die psychologischen Gründe hinter dem Festhalten an Planung: das Bedürfnis nach Sicherheit, die Angst vor Chaos und die Illusion von Kontrolle. Und sie zeigt, welche Bedingungen nötig sind, damit Teams sich wirklich auf das Unplanbare einlassen können – mit Vertrauen, Mut und einer gesunden Fehlerkultur.

Links

• Are We Engineers? With Hillel Wayne

• Zukunftssichere Architekturen - Keine gute Idee?

• Prof. Christiane Floyd zu “menschenzentrierter Software-Entwicklung”

• Postagilität - Was kommt jetzt? mit Tanja Friedel und Uwe Vigenschow

• Software-Entwicklung = Lernen

• Intro to Beyond Estimates with Woody Zuill

• Gibt es das Wasserfallmodell überhaupt?

Der Begriff „Agilität“ ist in den letzten 20 Jahren für alles Mögliche benutzt worden. Dadurch ist Agilität bedeutungsleer geworden. Andererseits ist es durch den Fokus auf Methoden entkoppelt vom Ziel, was wir über die Werkzeuge erreichen wollen. Das ist in den aktuellen Zeiten umso dramatischer, weil die Resilienz von Organisationen, also ihre Fähigkeit, sich einem dynamischen und komplexen Umfeld anzupassen, Krisen zu überstehen und gleichzeitig zu wachsen, eigentlich nur mit echter Agilität erreichbar ist.

Tanja Friedel und Uwe Vigenschow glauben, dass die Zukunft der Softwareentwicklung in einer Rückbesinnung auf die Werte und Prinzipien liegt, die hinter Agilität ursprünglich standen. Außerdem ist eine Fokussierung auf die Ergebnisse zentral - statt auf Hilfsmittel zur Zielerreichung wie Prozesse oder sinnentleertes Feel Good. Sie ziehen die Lehren aus über 20 Jahren Agilität und zeigen den Einfluss z.B. von KI und Homeoffice auf. Und sie berichten, wie sie Kunden dabei helfen, die Arbeitsweisen anzupassen, Anforderungen anders zu erheben und die Struktur der Software anzupassen.

Links

• Die diskutierten Workshops

• Virtueller Kaffee

• Henry Mintzberg: Managers not MBAs

• LinkedIn-Post