SAA Infodays 2025 - Denken, dann machen

„Komm, wir analysieren das jetzt nicht tot, lass uns loslegen.“, „Wir können das später ja nochmal anders machen.“ Kennt ihr das? Woher kommt eigentlich die Zurückhaltung bei agiler Entwicklung, Zeit in die Gestaltung gut durchdachter Architekturkonzepte zu investieren? Wir machen immer wieder die Erfahrung, dass grundsätzlich gute Ideen der agilen Softwareentwicklung umgedeutet werden, um so den Unwillen für Konzeption zu rechtfertigen.

Aber agile Entwicklung heißt nicht, dass man nicht so genau über die Lösung nachdenken sollte. YAGNI sagt uns nicht, Dinge zu ignorieren, die wir bereits wissen. Und Fokus auf Refactoring bedeutet auch nicht, dass man alle zentralen Architekturentscheidungen ganz leicht wieder ändern kann.

In der Folge wird, wenn es gut läuft, etwas Architekturarbeit im Sprint 0 gemacht, die Systemstruktur rudimentär definiert und etwas über Deployment nachgedacht. Die große Menge an zentralen Konzepte aber wird nicht weit genug ausgearbeitet und zentrale Entscheidungen ad-hoc beim Programmieren getroffen.

Wir finden das schade, denn das macht die Entwicklung oft teurer und das Ergebnis schlechter als es sein müsste. Dabei können agile Entwicklung und Architekturarbeit extrem gut Hand-in-Hand gehen.

In unserem Vortrag plädieren wir dafür, Architekturarbeit konzeptzentriert zu machen und als kontinuierliche Aktivität mit agiler Entwicklung zu verknüpfen. Denn wer an Konzepten arbeitet, denkt automatisch über das nach, was im System wirklich wichtig ist – fachlich wie technisch. Gut gestaltete Architekturkonzepte bilden starke inhaltliche Klammern und fördern so die Kohärenz von Lösungsansätzen. Zusätzlich sorgen sie dafür, dass wiederkehrende Herausforderungen innerhalb eines Systems immer auf einheitliche Art gelöst werden.

Wir beleuchten Architekturkonzepte im Detail und erläutern mit vielen Beispielen, was für uns ein gutes Architekturkonzept ausmacht, welche Arten von Konzepten es gibt und wie sich Konzepte strukturiert gestalten, dokumentieren und beispielsweise in Templates wie arc42 integrieren lassen. Basierend darauf zeigen wir, wie wir in unseren Projekten die Erarbeitung von Architekturkonzepten mit agilen Vorgehen kombinieren. So bauen wir Systeme, die besser gestaltet sind und länger leben können.

Transcript

1. Denken, dann machen: Konzept -zentrierte Architekturarbeit u agiles Vorgehen kombinieren Matthias Naab | Dominik Rost | Full Flamingo GmbH InfoDays Software Architecture Alliance | 28.10.2025
2. #gleichrichtigmachen Software -Architektur. Digital Design. Big Picture Engineering. Matthias Naab Dominik Rost Marcus Trapp
3. Agile Projekte
4. Hilfreiche Praktike ▪Kurze Iterationen ▪Kontinuierliches Liefern von Wert ▪Enge Zusammenarbeit mit Stakeho ▪Pair Programming ▪Fokus auf Testen ▪Flexibles Reagieren auf Änderunge
5. Komm, wir analysieren das je nicht tot, lass uns loslegen. “ ”
6. Wir können das später ja noch anders machen. “ ”
7. Was oft schief läuf ▪Skepsis gegenüber Konzeption ▪Kein Wert auf gute Konzepte geleg ▪Zu wenig Zeit investiert ▪Zu schnell zufrieden ▪Zu wenig Detail ▪Zu ungenau ▪Zu schlecht
8. YAGNI You Ain‘t Gonna Need It
9. Baue eine Lösung erst dann, w du sie tatsächlich brauchst “ ”
10. Keine Abstraktion einbauen die man jetzt noch nicht brau
11. Keine Abstraktion einbauen von der man nicht weiß, ob man sie brauchen wird.
12. Lieber nicht so viel nachdenk Wer weiß, ob sich das später l “ ”
13. Programmieren statt Konzipieren!
14. Sprint Sprint Wie es gerne läuft Task: Umsetzung „Lass uns loslegen !“ ? Umbau Task: Sackgasse Anforderung: Erweiterung & Umbau … Umbau Sprint
15. 2 Tage Nachdenken wurden d 3 Sprints Programmieren erse
16. Programmieren hilft, Dinge konkret zu machen und direk Feedback zu bekommen.
17. Ein Konzept im Kopf und au Papier ist viel günstiger zu änd
18. Macht Programmieren mehr S als Konzipieren?
19. Refactoring
21. Passendes! Fundament legen
22. Projektlaufzeit Anteil schon getroffener, zentraler Entscheidungen Big Design Upfront Konzeptionelles Vakuum Ausgewogene Konzeption Instabile Konzeption
23. Was sind Architekturkonzept
24. Ich weiß gar nicht, was Du mit „Konzepten“ mein “ ”
25. Strukturen Entscheidunge Softwarearchitektur
26. Anforderung Entscheidung Anforderung Entscheidung Anforderung Entscheidung Anforderung Entscheidung
27. Thema / Problemstellung Anforderung Anforderung Anforderung Anforderung Lösungsansatz Entscheidung Entscheidung Entscheidung Entscheidung E Architekturkonzept
28. Viele von Euch arbeiten bere häufig konzept -zentriert!
29. Beispiel
31. Kontext / Problem Anforderungen / Architekturtreiber Lösungsansatz Architektur- entscheidungen Detaillierte illustrierende Abbildungen Verworfene Alternativen
32. Architekturkonzepte ▪Lösungsansatz für eine gegebene Problemstellung ▪Inhaltliche Klammer um eine Menge von Anforderungen, Lösungsideen und Ents ▪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
33. Konzepte nicht aus Büchern abschreib fullflamingo.de /blog /architekturdokumentation -niemals -aus -buechern -abschreiben/
34. Arten von Architekturkonzept n
35. 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
36. Erarbeitung von Architekturkonzept n
37. Startpunkt für Arbeit an Architekturkonze ▪Zunächst: Initiale Zerlegung des Systems in fachliche Elemente, grobes Deployment , grobe Datenstrukturen, grobe Architekturentscheidungen (z.B. auch Architekturstile, A ▪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
38. Iterative Erarbeitung eines Konzepts https://www.microtool.de/wp -content/uploads/2023/06/the -twin -peaks -model.png Twin Peaks Model ▪Springen zwischen Anforderung und Lösung ▪Nach und nach mehr verstehen ▪Mit mehr Design -Fortschritt entstehen neue Fragen und Opt ▪Konzepte sind abhängig von and Konzepten im System ▪Kein geradliniger Weg!
39. Zu berücksichtigende Aspekte bei der Erarbeit 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
40. Kernaktivitäten der Konzeptarbeit Konzept - Design Konzept - Validation Konzept - Dokumentation Präzisierung Persistierung Vorstellung Feedback (intern & extern) Erstellung Klärung Exploration Abwägung Nicht zu schnell zufrieden sein!
41. Eigenschaften von gut Architekturkonzepte n
42. Zielgerichtetheit ▪Klares Ziel ▪Klare Problemstellung ▪Klare Anforderungen
43. Einfachheit & Minimalismus ▪Vermeidung von „Accidential Complexity “ ▪Bewusst vereinfachen ▪Möglichst wenige Rädchen hinzuf
44. Konsistenz & Einheitlichkeit ▪Gleiches gleich lösen ▪Unterschiedliche Fälle „auseinanderziehen“ ▪Systemweit denken, nicht nur lok
45. Präzision ▪Genau arbeiten und beschreiben ▪Details beachten ▪Sonderfälle verstehen
46. Vollständigkeit ▪Der Scope ist stimmig ▪Alles im Scope ist wirklich gelöst ▪Die zentralen Fragen sind beantw
47. Konkretheit & Gute Beispiele ▪Illustration von Problem und Lösu mit konkreten Beispielen ▪Konkrete und klare Sprache in der Beschreibung
48. Aspekte auseinanderzie Lösungsmöglichkeiten detailli Illustrierende Beispie
49. Verständlichkeit ▪Intuitive Zugänglichkeit für Person mit erwartbarem Basiswissen
50. Eleganz ▪Ergebnis der anderen Eigenschaft
51. Übersicht der Eigenschaften guter Architekturk ▪Zielgerichtetheit ▪Einfachheit & Minimalismus ▪Konsistenz & Einheitlichkeit ▪Präzision ▪Vollständigkeit ▪Konkretheit und gute Beispiele ▪Verständlichkeit ▪Eleganz
52. Dokumentation von Architekturkonzept n
53. Warum Architekturkonzepte aufschreiben ▪Falls Architekturkonzepte nicht aufgeschrieben werden: ▪Saubere Erarbeitung ist nicht möglich ▪Niemand kann ein umfangreicheres Konzept in allen Facetten durchdringen und behalten ▪Konzepte können nicht kommuniziert werden ▪Konzepte können nicht einheitlich umgesetzt werden
54. Wo schreibt man Architekturkonzepte auf ▪ Templates wie Arc42 sehen dafür sogar einen Platz vor! ▪ In der Praxis total vernachläs ▪ Selbst in den offiziellen Arc42 Beispielen vernachlässigt!
55. Wie schreibt man Architekturkonzepte au ▪ In der Konzept -Dokumentation auch: ▪ Diagramme verwenden ▪ Architekturentscheidungen dokumentieren ▪ Konzepte können auch länge werden: sauber strukturieren Initialzerlegung Architektur -Konzepte
56. System schlägt Template: Wider Schema F be Architektur - Dokumentationen! fullflamingo.de/blog/system -schlaegt -template -wider -schema -f-bei -architektur -dokumentationen/
57. Dein Konzepte -Kapitel ist zu kurz. Arbeite dran. https:// fullflamingo.de /blog /dein -konzepte -kapitel -ist -zu-kurz -arbeite -dran/
58. Kontext / Problem Anforderungen / Architekturtreiber Lösungsansatz Architektur- entscheidungen Detaillierte illustrierende Abbildungen Verworfene Alternativen
59. Integration von Konzeptar in den Entwicklungsprozes
60. Konzeptarbeit ist Entwicklungsarbeit
61. Konzeptarbeit ist ein eigener im Entwicklungsprozess
62. Sprint Sprint Sprint Sprint Konzeption kommt vor Umsetzung Konzept -Task Umsetzungs -Task Umsetzungs -Task Umsetzungs -Task Umsetzungs -Task
63. 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 gena während der Bearbeitung aufgekommene) zentralen Fragestellungen innerhalb des Scopes lie ▪Das Konzept wurde dem Team vorgestellt und Feedback eingearbeitet. ▪Die Dokumentation des Konzeptes steht im Wiki dem Team zur Verfügung. ▪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.
64. Konzeptarbeit ist eine kontinuierliche Aktivität im Entwicklungsprozess
65. Sprint Sprint Sprint Sprint Konzeption und Umsetzung laufen paralle
66. Was ist, wenn sich die Anforderungen ändern? “ ”
67. 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
68. Konzeptarbeit im Entwicklungsprozess richtig integ ▪ 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 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 Program zu treffen. ▪ Konzepte legen Fundamente . ▪ Änderungen an gebauten Fundamenten sind teuer .
69. Konzepte werden vo Menschen gemacht
70. Jedes Projekt braucht Mensc die konzipieren können und wollen!
71. Im (Informatik -) Studium lernt man das Konzipieren leider nicht!
72. Wenn die Fähigkeiten zur Konzeption in einem Projektt nicht ausreichen, besteht grö Risiko zu scheitern!
73. Fazit Denken, dann machen. ▪ Architekturkonzepte werden häufig vernach ▪ Konzeptarbeit ist Entwicklungsarbeit ▪ Konzepte schaffen die Basis für die Umsetzu ▪ Konzeption schafft Klarheit ▪ Konzeption vermeidet Irrwege ▪ Konzeption lässt sich leichter umbauen ▪ Konzeption kostet nicht mehr ▪ Konzepte müssen„compliant “ umgesetzt werden
74. https://fullflamingo. de /blog/
75. Wir helfen Unternehmen pragma die wichtigen Entscheidungen in Softwareentwicklung abzusicher “ ” Es ist nie zu früh, es gleich richtig zu machen. Und selten zu spät. #gleichrichtigmachen www.fullflamingo.de www.fullflamingo.de
76. Denken, dann machen: Konzept -zentrierte Architekturarbeit u agiles Vorgehen kombinieren Matthias Naab | Dominik Rost | Full Flamingo GmbH InfoDays Software Architecture Alliance | 28.10.2025