Es geht weiter mit der iSAQB Advanced Beispielaufgabe “Big Spender”! Nach der der Episode über Qualitätsanforderungen und der Episode über die Lösungsstrategie geht es in dieser Folge um den technischen Kontext. Er beschreibt wie das System mit anderen System technisch interagiert und hilft so vor allem bei der Integration der Systeme. Außerdem besprechen wir, wie das System in fachliche Subsysteme aufgeteilt werden kann. 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

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

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

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.

Links

• Beispielaufgabe

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

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

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