Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OOP 2026 - Denken, dann machen

Avatar for Matthias Naab Matthias Naab
February 16, 2026
28

OOP 2026 - Denken, dann machen

„Komm, wir analysieren das jetzt nicht tot, lass uns loslegen.“ „Wir können das später ja noch mal 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 Konzepten aber wird nicht weit genug ausgearbeitet und zentrale Entscheidungen werden 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.

Avatar for Matthias Naab

Matthias Naab

February 16, 2026
Tweet

More Decks by Matthias Naab

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. Hilfreiche Praktike ▪Kurze Iterationen ▪Kontinuierliches Liefern von Wert ▪Enge Zusammenarbeit

    mit Stakeho ▪Pair Programming ▪Fokus auf Testen ▪Flexibles Reagieren auf Änderunge
  3. 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
  4. Sprint Sprint Wie es gerne läuft Task: Umsetzung „Lass uns

    loslegen !“ ? Umbau Sackgasse Anforderung: Erweiterung & Umbau … Umbau Sprint Task:
  5. 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
  6. 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
  7. Konkretheit & Gute Beispiele ▪Illustration von Problem und Lösu mit

    konkreten Beispielen ▪Konkrete und klare Sprache in der Beschreibung
  8. 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
  9. 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!
  10. 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
  11. 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!
  12. 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
  13. 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!
  14. 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
  15. System schlägt Template: Wider Schema F be Architektur - Dokumentationen!

    fullflamingo.de/blog/system -schlaegt -template -wider -schema -f-bei -architektur -dokumentationen/
  16. Dein Konzepte -Kapitel ist zu kurz. Arbeite dran. https:// fullflamingo.de

    /blog /dein -konzepte -kapitel -ist -zu-kurz -arbeite -dran/
  17. Sprint Sprint Sprint Sprint Konzeption kommt vor Umsetzung Konzept -Task

    Umsetzungs -Task Umsetzungs -Task Umsetzungs -Task Umsetzungs -Task
  18. 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.
  19. 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.
  20. 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.
  21. 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
  22. 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 .
  23. 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
  24. 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
  25. Feedback Denken, dann machen: Konzept -zentrierte Architekturarbeit u agiles Vorgehen

    kombinieren Matthias Naab | Dominik Rost | Full Flamingo GmbH OOP München | 13.02.2026