OOP 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 u agiles Vorgehen kombinieren Matthias Naab | Dominik Rost | Full Flamingo GmbH OOP München | 13.02.2026
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. Programmieren statt Konzipieren!
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. 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 d 3 Sprints Programmieren erse
10. YAGNI You Ain‘t Gonna Need It
11. Baue eine Lösung erst dann, w du sie tatsächlich brauchst “ ”
12. Keine Abstraktion einbauen die man jetzt noch nicht brau
13. Keine Abstraktion einbauen von der man nicht weiß, ob man sie brauchen wird.
14. Ein Konzept im Kopf und au Papier ist viel günstiger zu änd
15. Refactoring
16. Wir können das später ja noch anders machen. “ ”
18. Passendes! Fundament legen
19. Vielen macht Programmiere einfach mehr Spaß als Konzipie
20. Projektlaufzeit Anteil schon getroffener, zentraler Entscheidungen Big Design Upfront Konzeptionelles Vakuum Ausgewogene Konzeption Instabile Konzeption
21. Was sind Architekturkonzept
22. Ich weiß gar nicht, was Du mit „Konzepten“ mein “ ”
23. Strukturen Entscheidunge Softwarearchitektur
24. Anforderung Entscheidung Anforderung Entscheidung Anforderung Entscheidung Anforderung Entscheidung
25. Thema / Problemstellung Anforderung Anforderung Anforderung Anforderung Lösungsansatz Entscheidung Entscheidung Entscheidung Entscheidung E Architekturkonzept
26. Viele von Euch arbeiten bere häufig konzept -zentriert!
27. Beispiel
29. Kontext / Problem Anforderungen / Architekturtreiber Lösungsansatz Architektur- entscheidungen Detaillierte illustrierende Abbildungen Verworfene Alternativen
30. 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
31. Konzepte nicht aus Büchern abschreib fullflamingo.de /blog /architekturdokumentation -niemals -aus -buechern -abschreiben/
32. Arten von Architekturkonzept n
33. 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
34. Eigenschaften von gut Architekturkonzepte n
35. Zielgerichtetheit ▪Klares Ziel ▪Klare Problemstellung ▪Klare Anforderungen
36. Einfachheit & Minimalismus ▪Vermeidung von „Accidential Complexity “ ▪Bewusst vereinfachen ▪Möglichst wenige Rädchen hinzuf
37. Konsistenz & Einheitlichkeit ▪Gleiches gleich lösen ▪Unterschiedliche Fälle „auseinanderziehen“ ▪Systemweit denken, nicht nur lok
38. Präzision ▪Genau arbeiten und beschreiben ▪Details beachten ▪Sonderfälle verstehen
39. Vollständigkeit ▪Der Scope ist stimmig ▪Alles im Scope ist wirklich gelöst ▪Die zentralen Fragen sind beantw
40. Konkretheit & Gute Beispiele ▪Illustration von Problem und Lösu mit konkreten Beispielen ▪Konkrete und klare Sprache in der Beschreibung
41. Aspekte auseinanderzie Lösungsmöglichkeiten detailli Illustrierende Beispie
42. Verständlichkeit ▪Intuitive Zugänglichkeit für Person mit erwartbarem Basiswissen
43. Eleganz ▪Ergebnis der anderen Eigenschaft
44. Erarbeitung von Architekturkonzept n
45. 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
46. 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!
47. 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
48. 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!
49. Dokumentation von Architekturkonzept n
50. 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
51. 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!
52. 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
53. System schlägt Template: Wider Schema F be Architektur - Dokumentationen! fullflamingo.de/blog/system -schlaegt -template -wider -schema -f-bei -architektur -dokumentationen/
54. Dein Konzepte -Kapitel ist zu kurz. Arbeite dran. https:// fullflamingo.de /blog /dein -konzepte -kapitel -ist -zu-kurz -arbeite -dran/
55. Kontext / Problem Anforderungen / Architekturtreiber Lösungsansatz Architektur- entscheidungen Detaillierte illustrierende Abbildungen Verworfene Alternativen
56. Integration von Konzeptar in den Entwicklungsprozes
57. Konzeptarbeit ist Entwicklungsarbeit
58. Konzeptarbeit ist ein eigener im Entwicklungsprozess
59. Sprint Sprint Sprint Sprint Konzeption kommt vor Umsetzung Konzept -Task Umsetzungs -Task Umsetzungs -Task Umsetzungs -Task Umsetzungs -Task
60. 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. ▪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.
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. Beispiel: H orizontale 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.
63. Konzeptarbeit ist eine kontinuierliche Aktivität im Entwicklungsprozess
64. Sprint Sprint Sprint Sprint Konzeption und Umsetzung laufen paralle
65. Was ist, wenn sich die Anforderungen ändern? “ ”
66. 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
67. 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 .
68. Konzepte werden vo Menschen gemacht
69. Jedes Projekt braucht Mensc die konzipieren können und wollen!
70. Wenn die Fähigkeiten zur Konzeption in einem Projektt nicht ausreichen, besteht grö Risiko zu scheitern!
71. 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
72. https://localghost.dev/blog/stop-generating-start-thinking/
73. https://fullflamingo. de /blog/
74. 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 Feedback
75. Feedback Denken, dann machen: Konzept -zentrierte Architekturarbeit u agiles Vorgehen kombinieren Matthias Naab | Dominik Rost | Full Flamingo GmbH OOP München | 13.02.2026