Listen Now

Software entwickelt man heutzutage agil - die einzige Alternative wäre noch der Wasserfall. In dieser Episode diskutieren wir, dass man berechtigte Zweifel an der Existenz dieses Modells haben kann. Denn um die Entstehung und Eignung des Modell ranken sich zahlreiche Mythen - und schlichte Missverständnisse. Das besser zu verstehen hilft dabei, das geeignet Vorgehen für das nächste Projekt zu wählen und nicht die Fehler zu begehen, vor denen teilweise seit Jahrzehnten gewarnt wird. Präsentation Links Folge mit Prof. Dr. Christiane Floyd Blog-Beitrag “Wasserfall-Modell? LOL!” Das SAGE-System IBM AN/FSQ-7 Computer Herbert D. Benington: Production of Large Computer Programs Winston W. Royce: Managing the Development of Large Software Systems Laurent Bossavit: The Leprechauns of Software Engineering - How Folklore Turns Into Fact and What to Do About It Folge Hillel Wayne & Laurent Bossavit - Is It All Built on Sand - What Do We Actually Know About Software Development? Folge zu Agilität

Nach der letzten Episode geht es weiter mit dem Architektur-Entwurf für iSAQB-Advanced-Level-Beispielaufgabe “Big Spender”. In dieser Episode diskutieren wir die Lösungsstrategie und den technischen Kontext. Diese Folgen zeigen nicht nur, wie man an den Entwurf einer Software-Architektur herangehen kann - sondern auch, worauf es beim schriftlichen Teil der iSAQB-Advanced-Level-Zertifizierung ankommt. Links Beispielaufgabe Episode zu Benutzerfreundlichkeit / UX mit Aminata Sidibe arc42 Excel mit Berechnungen zur Datenmenge Miro Board als PDF

Wie erstellt man denn nun eine Software-Architektur? In dieser Episode bespricht Eberhard einen konkreten Architektur-Entwurf. Als Beispiel dient die iSAQB-Advanced-Level-Beispielaufgabe “Big Spender”. So verdeutlicht diese Folge nicht nur, wie man an den Entwurf einer Software-Architektur herangehen kann - sondern auch, worauf es beim schriftlichen Teil der iSAQB-Advanced-Level-Zertifizierung ankommt. Spoiler: Eine Architektur-Dokumentation z.B. nach arc42 ist nicht die Lösung. miro Board Export Präsentation Links Beispielaufgabe Episoden zu Qualität Episode zu Benutzerfreundlichkeit / UX mit Aminata Sidibe arc42

Events sind ein wichtiges Element vieler Architekturen. Sie spielen in ganz unterschiedlichen Bereichen eine Rollen: Bei der Analyse mit Event Storming, bei der Implementierung im Domain-driven Design, bei der Verwaltung von Zuständen mit Event Sourcing und bei der Aufteilung von Systemen in lesende und schreibende Teile mit CQRS (Command Query Segregation Principle). In dieser Episode diskutiert Eberhard diese Bereiche und welche Rolle Events in jedem von ihnen spielen. In der Praxis führen Missverständnisse in diesem Bereich immer wieder zu Architektur-Herausforderungen. Links Episode mit Nicole Rauch u.a. zu Event Storming DDD Referenz Martin Fowler zu Event Sourcing Kafka Video Susanne Braun zu Eventual Consistency Episode zu Microservices, Transaktionen und Konsistenz Christian Stettlers Artikel zu Domain Events vs Event Sourcing

Data Mesh ist der neue Hype für Datenanalyse. Während Analyse klassisch nur nervige Anforderungen sind, profitieren dieses Mal Software-Architekt:innen und Entwickler:innen. Wir diskutieren den Ansatz und das Neue daran mit Jochen Christ, Simon Harrer und Theo Pack. Dabei geht es nicht nur um die Umsetzungsmöglichkeiten, sondern auch um den Einfluss auf die Software-Architektur und die Organisation. Schließlich ist Data Mesh gerade entstanden, um trotz dezentraler, selbstorganisierter Teams und lose gekoppelten Komponenten einen zentralisierten Blick auf alle Daten zu liefern. Links Data Mesh Buch Data Mesh Microsite Jochens Artikel bei heise

Weiter geht es mit dem Enturf unserer Architektur aus den letzten Folgen: In dieser Episode wird Aminata Sidibe uns erläutern, wie wir die Hauptanforderung an die Architektur erfüllen können - nämlich Benutzerfreundlichkeit. Dabei geht es um grundlegende Konzepte wie User Experience (UX), Customer Experience (CX) und Informationsarchitektur. Darauf basierend diskutiert Aminata konkrete Maßnahmen, damit unser Produkt beim Benutzer gut ankommt ist und so am Markt erfolgreich sein kann.

In den letzten beiden Episoden haben wir die Grundlagen für die Architektur des Systems geschaffen. In der Praxis sind die Technologien und die anderen Lösungen in den Architekturen oft nicht an den Kundenansprüchen ausgerichtet. In dieser Episode werden wir diskutieren, wie wir dieses Problem lösen können. Wir werden untersuchen, wie das System die erhobenen Qualitätsanforderungen bzw. nicht-funktionalen Anforderungen erfüllen kann. Aus diesen Anforderungen werden wir dann die wesentlichen Technologie-Entscheidungen ableiten und so ein System entwerfen, dass den Anforderungen des Kunden gerecht wird.

Nachdem wir in der vorherigen Episode begonnen haben, Qualitätsszenarien zu definieren und den System-Kontext zu erstellen, werden wir in dieser Episode die Lösung in einzelne Komponenten strukturieren. Das ergibt für die Implementierung eine Struktur vor, die den Code aufteilt. Links Bausteinsicht in arc42

In dieser Episode erstellen wir eine Software-Architektur live. So sieht man, auf welche Aspekte es bei der Software-Architektur tatsächlich ankommt - und nicht in der Theorie sondern in der Praxis. Und wer denkt, dass es bei der Software-Architektur um die Aufteilung in Komponenten und die Struktur der Software geht - macht Euch auf Überraschungen gefasst. Links Miro Board arc42

Das Gesetz von Conway stellt einen Zusammenhang zwischen der Organisation und der Software-Architektur her. Seit dem Microservices-Hype wird Conway’s Law häufig als Architektur-Werkzeug gesehen. Aber die meisten haben das ursprüngliche Paper von Melvin Conway gar nicht gelesen. In dieser Folge diskutieren wir die Inhalte des Papers - und was wir daraus für die Architektur-Arbeit lernen können. Links Conway’s Paper Adrian Colyer über Conway’s Paper Vortrag Beten wir Komplexität an? Episode mit James Lewis

Software Architektur ist ein neuer Podcast. Software-Architekt:innen berichten von ihrem Karriere-Weg in der Software-Architektur. Weitere Info: https://software-architektur.tv/beruf.html

Software-Architektur im Stream hat jetzt über 100 Folgen - aber eine fundamentale Frage haben wir noch nicht diskutiert: Was ist Software-Architektur? In dieser Folge wollen wir endlich dieser Frage nachgehen. Und natürlich schließt sich daran die Frage an, was Software-Architekt:innen in ihrer Rolle leisten sollten. Links Tweet zu Software-Architekt:innen-Aufgaben Post bei Mastodon zu Software-Architekt:innen-Aufgaben Folge zu Modularisierung Folge zu Quaitätsszenaire Folge mit Daniel Terhorst-North zu SOLID vs. CUPID Folge mit Prof. Christiane Floyd zu “menschenzentrierter Software-Entwicklung”

In der Software-Entwicklung sind zahlreiche Gruppen unterrepräsentiert. Bei diesem Panel wollen wir diskutieren, wie Diversity erhöht werden kann. Diversity mit Lars Hupel, Lena Kraaz und Aminata Sidibe

Die Klima-Katastrophe ist eine der wichtigsten Herausforderungen, denen wir uns stellen müssen. Dieses Panel diskutiert, was Software-Entwicklung dazu beitragen kann. Links SoftAWERE: Tools and Labels for Energy-efficient Software Applications scaph repl schnittstelle Scaphandre: metrology agent dedicated to electrical power consumption metrics Intel RAPL Intel: Running Average Power Limit Energy Reporting Stackoverflow: How does Intel’s RAPL estimate the power consumption? Reading RAPL energy measurements from Linux Intel Open Source Blog zu RAPL EET: A Device to Support the Measurement of Software Consumption Buch: Software Sustainability mit einem Kapitel von Jutta Umweltbundesamt: KPI4DCE: Das ressourceneffiziente Rechenzentrum – Kennzahlen und Indikatoren Umweltbundesamt zu KPI3DCE 2.0 Open Source Library für das Messen von Strom/Embedded CO2 einer Server-Side Software Anwendung von Max Code Repository Blog The Hippocratic License Hippocratic - An Ethical License for Open Source Projects Developers for Future Artikel in der c’t zum Thema Episode zu Klimawandel & Software Architektur mit Martin Lippert und Stefan Roock

Resiliente Organisation und resiliente Software-Architektur: Die Organisation hat großen Einfluss auf die Architektur. Wie kann man sich diesen Zusammenhang zu Nutze machen? Links DevOps und Team Topologies mit Anja Kammer - Live vom INNOQ Technology Day Delegation Poker

Daten beispielsweise lokal zu kopieren, um offline zu arbeiten, ist eine Herausforderung. Wir diskutieren, wie man sie meistern kann. Links CRDT Homepage Lars: An Introduction to Conflict-Free Replicated Data Types INNOQ Technology Lunch

Wir kennen alle DevOps - aber was ist DevSecOps und warum gehört ausgerechnet Sicherheit dazu?# Thoughtworks Technology Radar

Technical debt is a well-known concept - but data can also cause technical debt. Links Data Technical Debt Refactoring Databases Agile Data Homepage

Testing alone is not enough - the alternative is quality engineering. Links Book: TMAP Quality for DevOps Teams TMAP

Software is developed in teams so design decision must be done collaboratively. Links Book: Jitske Kramer - Jam Cultures: About Inclusion; Joining in the Action, Conversation and Decisions Book: Sam Kaner - Facilitator’s Guide to Participatory Decision-Making Book: Thomas Wedell-Wedellsborg - What’s Your Problem?: To Solve Your Toughest Problems, Change the Problems You Solve Blog: Rebecca Wirfs-Brock: Architecture Decisions Should Be Made At the Last Responsible Moment Sketchnote: Dale Carnegie: How to Win Friends and Influence People