iSAQB Community-Meetup Rhein/Main 2026 - Denken, dann machen: konzeptzentrierte Architekturarbeit und agiles Vorgehen kombinieren

„Komm, wir analysieren das jetzt nicht tot, lass uns loslegen.“ Kennt ihr das? Warum die Zurückhaltung, in gute Architekturkonzepte zu investieren? Das Ergebnis wird so oft teurer und schlechter als nötig.

Wir plädieren dafür, Architekturarbeit konzeptzentriert zu machen und als kontinuierliche Aktivität mit agiler Entwicklung zu verzahnen. Anhand vieler Beispiele zeigen wir, wie man Konzepte strukturiert gestaltet und mit agilen Vorgehen kombiniert. Denn wer an Konzepten arbeitet, denkt über das nach, was im System wirklich wichtig ist.

Transcript

1. Denken, dann machen: Konzept-zentrierte Architekturarbeit und agiles Vorgehen kombinieren Matthias Naab | Dominik Rost | Full Flamingo GmbH iSAQB Community-Meetup Rhein/Main | 17.06.2026
2. #gleichrichtigmachen Software-Architektur. Digital Design. Big Picture Engineering. Matthias Naab Dominik Rost Marcus Trapp
3. Agile Projekte
4. Hilfreiche Praktiken ▪Kurze Iterationen ▪Kontinuierliches Liefern von Wert ▪Enge Zusammenarbeit mit Stakeholdern ▪Pair Programming ▪Fokus auf Testen ▪Flexibles Reagieren auf Änderungen
5. Komm, wir analysieren das jetzt nicht tot, lass uns loslegen. “ ”
6. Programmieren statt Konzipieren!
7. Was oft schief läuft! ▪Skepsis gegenüber Konzeption ▪Kein Wert auf gute Konzepte gelegt ▪Zu wenig Zeit investiert ▪Zu schnell zufrieden ▪Zu wenig Detail ▪Zu ungenau ▪Zu schlecht
8. Sprint Sprint Wie es gerne läuft Task: Umsetzung „Lass uns loslegen!“ ? Umbau Sackgasse Anforderung: Erweiterung & Umbau … Umbau Sprint Task:
9. 2 Tage Nachdenken wurden durch 3 Sprints Programmieren ersetzt!
10. YAGNI You Ain‘t Gonna Need It
11. Baue eine Lösung erst dann, wenn du sie tatsächlich brauchst. “ ”
12. Keine Abstraktion einbauen, die man jetzt noch nicht braucht.
13. Keine Abstraktion einbauen, von der man nicht weiß, ob man sie brauchen wird.
14. Ein Konzept im Kopf und auf Papier ist viel günstiger zu ändern!
15. Refactoring
16. Wir können das später ja nochmal anders machen. “ ”
18. Passendes! Fundament legen
19. Vielen macht Programmieren einfach mehr Spaß als Konzipieren.
20. Projektlaufzeit Anteil schon getroffener, zentraler Entscheidungen Big Design Upfront Konzeptionelles Vakuum Ausgewogene Konzeption Instabile Konzeption
21. Was sind Architekturkonzepte?
22. Strukturen Entscheidungen Softwarearchitektur
23. Anforderung Entscheidung Anforderung Entscheidung Anforderung Entscheidung Anforderung Entscheidung
24. Thema / Problemstellung Anforderung Anforderung Anforderung Anforderung Lösungsansatz Entscheidung Entscheidung Entscheidung Entscheidung E Architekturkonzept
25. Viele von Euch arbeiten bereits häufig konzept-zentriert!
26. Beispiel
28. Kontext / Problem Anforderungen / Architekturtreiber Lösungsansatz Architektur- entscheidungen Detaillierte illustrierende Abbildungen Verworfene Alternativen
29. Architekturkonzepte ▪Lösungsansatz für eine gegebene Problemstellung ▪Inhaltliche Klammer um eine Menge von Anforderungen, Lösungsideen und Entscheidungen ▪Beantworten aller zentralen Fragen ▪Erstrecken sich von konzeptionellen Grundlagen bis technische Details ▪Sind so detailliert wie sie sein müssen ▪Bilden die konzeptionelle Grundlage für die Umsetzung ▪Die Ausgestaltung ist immer spezifisch für das System, das wir bauen
30. Konzepte nicht aus Büchern abschreiben! fullflamingo.de/blog/architekturdokumentation-niemals-aus-buechern-abschreiben/
31. Arten von Architekturkonzepten
32. Arten von Architekturkonzepten ▪ Fachliche Konzepte ▪ Konzept für Rundung von Beträgen bei Abrechnungen ▪ Konzept zur Zuordnung von Produkten über verschiedene Händler hinweg ▪ Konzept zur Definition und Ausführung von Geschäftsregeln ▪ Qualitätskonzepte ▪ Konzept für horizontale Skalierung ▪ Internationalisierungskonzept ▪ Konzept für Datenverschlüsselung ▪ Technische Konzepte ▪ Logging-Konzept ▪ Error Handling-Konzept ▪ Daten-Persistenz-Konzept Eher projektspezifisch Häufig anzutreffen
33. Eigenschaften von guten Architekturkonzepten
34. Zielgerichtetheit ▪Klares Ziel ▪Klare Problemstellung ▪Klare Anforderungen
35. Einfachheit & Minimalismus ▪Vermeidung von „Accidential Complexity“ ▪Bewusst vereinfachen ▪Möglichst wenige Rädchen hinzufügen
36. Konsistenz & Einheitlichkeit ▪Gleiches gleich lösen ▪Unterschiedliche Fälle „auseinanderziehen“ ▪Systemweit denken, nicht nur lokal
37. Präzision ▪Genau arbeiten und beschreiben ▪Details beachten ▪Sonderfälle verstehen
38. Vollständigkeit ▪Der Scope ist stimmig ▪Alles im Scope ist wirklich gelöst ▪Die zentralen Fragen sind beantwortet
39. Konkretheit & Gute Beispiele ▪Illustration von Problem und Lösung mit konkreten Beispielen ▪Konkrete und klare Sprache in der Beschreibung
40. Aspekte auseinanderziehen Lösungsmöglichkeiten detaillieren Illustrierende Beispiele
41. Verständlichkeit ▪Intuitive Zugänglichkeit für Personen mit erwartbarem Basiswissen
42. Eleganz ▪Ergebnis der anderen Eigenschaften
43. Erarbeitung von Architekturkonzepten
44. Startpunkt für Arbeit an Architekturkonzepten ▪Zunächst: Initiale Zerlegung des Systems in strukturelle Elemente, Deployment, Datenstrukturen, grundlegende Architekturentscheidungen (z.B. auch Architekturstile, Architekturmuster) ▪Dann: Arbeit an Architekturkonzepten ▪Liste mit identifizierten notwendigen Konzepten (oder auch Elemente im Backlog) ▪Konzepte priorisieren und auswählen zur Erarbeitung ▪Erarbeitung der Konzepte kann auf Teams und Personen verteilt werden ▪Konzepte als zentrale und leitende Strukturierungsmerkmale einer Architektur
45. Iterative Erarbeitung eines Konzepts https://www.microtool.de/wp-content/uploads/2023/06/the-twin-peaks-model.png Twin Peaks Model ▪Springen zwischen Anforderungen und Lösung ▪Nach und nach mehr verstehen ▪Mit mehr Design-Fortschritt entstehen neue Fragen und Optionen ▪Konzepte sind abhängig von anderen Konzepten im System ▪Kein geradliniger Weg!
46. Zu berücksichtigende Aspekte bei der Erarbeitung von Architekturkonzepten ▪Kontext ▪Problemstellung ▪Anforderungen ▪Zentrale Entscheidungen ▪Zentrale beteiligte Funktionale Elemente ▪Zentrale Datenelemente ▪Grobes Systemverhalten im Konzept ▪Spezialfälle und Ausnahmefälle ▪Auswirkungen auf Qualitätsattribute / Tradeoffs ▪Verworfene Alternativen Parallele zur Gesamtarchitektur à Divide & Conquer
47. Kernaktivitäten der Konzeptarbeit Anforderungen & Konzept-Design Konzept- Validation Konzept- Dokumentation Präzisierung Persistierung Vorstellung Feedback (intern & extern) Erstellung Klärung Exploration Abwägung Nicht zu schnell zufrieden sein!
48. Dokumentation von Architekturkonzepten
49. Warum Architekturkonzepte aufschreiben? Falls Architekturkonzepte nicht aufgeschrieben werden: ▪Erarbeitung ▪Saubere Erarbeitung ist nicht möglich ▪Niemand kann ein umfangreicheres Konzept in allen Facetten durchdringen ▪Verwendung ▪Konzepte können nicht kommuniziert werden ▪Konzepte können nicht einheitlich umgesetzt werden ▪Niemand kann sich ein umfangreiches Konzept in allen Facetten merken
50. Wo schreibt man Architekturkonzepte auf? ▪ Templates wie Arc42 sehen dafür sogar einen Platz vor! ▪ In der Praxis total vernachlässigt ▪ Selbst in den offiziellen Arc42 Beispielen vernachlässigt!
51. Wie schreibt man Architekturkonzepte auf? ▪ In der Konzept-Dokumentation auch: ▪ Diagramme verwenden ▪ Architekturentscheidungen dokumentieren ▪ Konzepte können auch länger werden: sauber strukturieren! Initialzerlegung Architektur-Konzepte
52. System schlägt Template: Wider Schema F bei Architektur- Dokumentationen! fullflamingo.de/blog/system-schlaegt-template-wider-schema-f-bei-architektur-dokumentationen/
53. Dein Konzepte-Kapitel ist zu kurz. Arbeite dran. https://fullflamingo.de/blog/dein-konzepte-kapitel-ist-zu-kurz-arbeite-dran/
54. Kontext / Problem Anforderungen / Architekturtreiber Lösungsansatz Architektur- entscheidungen Detaillierte illustrierende Abbildungen Verworfene Alternativen
55. Integration von Konzeptarbeit in den Entwicklungsprozess
56. Konzeptarbeit ist Entwicklungsarbeit
57. Konzeptarbeit ist ein eigener Task im Entwicklungsprozess
58. Sprint Sprint Sprint Sprint Konzeption kommt vor Umsetzung Konzept-Task Umsetzungs-Task Umsetzungs-Task Umsetzungs-Task Umsetzungs-Task
59. Definition of Done für Konzept-Tasks ▪Es wurde ein sinnvoller Scope für das Konzept definiert. ▪Es wurde ein Konzept ausgearbeitet, das Antworten für alle (in der Aufgabe genannten und weitere während der Bearbeitung aufgekommene) zentralen Fragestellungen innerhalb des Scopes liefert. ▪Das Konzept wurde dem Team vorgestellt und Feedback eingearbeitet. ▪Das Team hat bestätigt, dass der Scope passt und das Konzept eine geeignete Lösung darstellt, die es erlaubt, die Anforderungen zu erfüllen. ▪Die Dokumentation des Konzeptes steht im Wiki dem Team zur Verfügung.
60. Beispiel: Horizontale Skalierung ## Task: Konzept für horizontale Skalierung des Order-Processing-Services ### Thema / Problemstellung Der Order-Processing-Service skaliert nicht zuverlässig bei Lastspitzen. Ziel ist ein Architekturkonzept zur horizontalen Skalierung — inklusive Entkopplung von Zuständen, Idempotenzstrategie und Anpassungen an Daten- und Prozessmodell. ### Zu lösende Fragestellungen - Welche Komponenten halten Zustand und wie können sie ausgelagert werden? - Welche Architekturansätze verwenden wir, um horizontale Skalierung zu ermöglichen (Eventing, Queueing, Worker- Pools)? - Wie kann Idempotenz sichergestellt werden (z. B. Request-Keys, dedizierte Tabellen, Outbox-Pattern)? - Wie werden Race Conditions und konkurrierende Schreibzugriffe verhindert? - Welche Infrastrukturkomponenten (Load Balancer, Auto-Scaling Policies) sind erforderlich? - Wie kann die Lösung schrittweise ins bestehende System integriert werden? ### Akzeptanzkriterien - Ein Zielbild der skalierbaren Architektur liegt als Diagramm + Beschreibung vor. - Zustandsbehaftete Komponenten wurden identifiziert und Maßnahmen zur Auslagerung beschrieben. - Vorschlag für Idempotenzmechanismen ist enthalten und anhand eines Order-Flows beschrieben. - Datenflussdiagramme für Lastspitzen-Szenarien sind Teil der Dokumentation. - Risiken (z. B. erhöhte Latenzen, komplexere Fehlerbehandlung) sind benannt. - Ein Migrationspfad in mehreren Schritten ist ausgearbeitet.
61. Beispiel: Logging- / Observability-Konzept ## Task: Logging- / Observability-Konzept ### Thema / Problemstellung Das System verfügt über uneinheitliche Log-Ausgaben und keine klare Strategie für Metriken und Tracing. Für Betrieb, Monitoring und Debugging wird eine standardisierte und skalierbare Observability-Lösung benötigt. ### Zu lösende Fragestellungen - Was soll geloggt werden, in welcher Granularität und mit welchen Log-Levels? - Wie werden Trace- und Correlation-IDs serviceübergreifend propagiert? - Welche Metriken (technisch & fachlich) sind erforderlich? - Welche Tools/Stacks kommen infrage (OpenTelemetry, ELK/EFK, vendor-spezifisch)? - Welche Anforderungen gibt es bzgl. Kosten, Latenz, Datenhaltung? - Wie wird die Observability-Strategie in bestehende Services integrierbar gemacht? ### Akzeptanzkriterien - Ein Artikel liegt vor, der Logging-, Metrics- und Tracing-Strategie beschreibt. - Der Artikel enthält konkrete Beispiele für Logformate sowie Regeln für Log-Level-Verwendung. - Es liegt ein Vorschlag für ein technisches Zielsetup (z. B. OpenTelemetry + XYZ Backend) vor. - Metriken sind nach Kategorien gegliedert (Systemmetriken, Business-Metriken). - Risiken und Alternativen sind beschrieben (z. B. Kosten, Vendor-Lock-in). - Integrationsempfehlungen für bestehende Services sind enthalten.
62. Konzeptarbeit ist eine kontinuierliche Aktivität im Entwicklungsprozess
63. Sprint Sprint Sprint Sprint Konzeption und Umsetzung laufen parallel
64. Was ist, wenn sich die Anforderungen ändern? “ ”
65. Arbeit und Änderungen an Konzepten Unabsehbare Änderung der Anforderungen Unsichere Anforderungen in der Zukunft ? ? Absichtliche Nichtbeachtung bekannter Anforderungen Mangelnde Tiefe in Konzepterarbeitung ! ! Unvermeidbar Suboptimales Vorgehen
66. Konzeptarbeit im Entwicklungsprozess richtig integrieren ▪ Scope eines Konzepts richtig wählen. ▪ Es ist sinnvoll Aspekte und Anforderungen erstmal wegzulassen, die sehr unsicher sind. ▪ Es kann sinnvoll sein, Aspekte und Anforderungen erstmal wegzulassen, um Komplexität zu reduzieren, um kurzfristig schneller zu sein. ▪ Es ist nicht sinnvoll, Aspekte und Anforderungen zu ignorieren, die sicher kommen werden. ▪ Aspekte außer Acht zu lassen sollte nicht dazu führen, dass die Erreichung von bekannten Zielen und Anforderungen praktisch unmöglich wird. ▪ Man kann ein Konzept umfassend(er) ausarbeiten und zunächst nur kleine Teile umsetzen. ▪ Konzeptarbeit braucht Zeit, die aber meist gut investiert ist. ▪ Es ist nicht sinnvoll, beim Konzeptionieren weniger nachzudenken und mehr Entscheidungen ad hoc beim Programmieren zu treffen. ▪ Konzepte legen Fundamente. ▪ Änderungen an gebauten Fundamenten sind teuer.
67. Konzepte werden von Menschen gemacht
68. Jedes Projekt braucht Menschen, die konzipieren können und wollen!
69. Wenn die Fähigkeiten zur Konzeption in einem Projektteam nicht ausreichen, besteht größtes Risiko zu scheitern!
70. Fazit Denken, dann machen. ▪ Architekturkonzepte werden häufig vernachlässigt ▪ Konzeptarbeit ist Entwicklungsarbeit ▪ Konzepte schaffen die Basis für die Umsetzung ▪ Konzeption schafft Klarheit ▪ Konzeption vermeidet Irrwege ▪ Konzeption lässt sich leichter umbauen ▪ Konzeption kostet nicht mehr ▪ Konzepte müssen„compliant“ umgesetzt werden
71. https://localghost.dev/blog/stop-generating-start-thinking/
72. https://fullflamingo.de/blog/
73. Wir helfen Unternehmen pragmatisch, die wichtigen Entscheidungen in der Softwareentwicklung abzusichern. “ ” Es ist nie zu früh, es gleich richtig zu machen. Und selten zu spät. #gleichrichtigmachen www.fullflamingo.de
74. Denken, dann machen: Konzept-zentrierte Architekturarbeit und agiles Vorgehen kombinieren Matthias Naab | Dominik Rost | Full Flamingo GmbH iSAQB Community-Meetup Rhein/Main | 17.06.2026