Softwarearchitektur
für Product Owner
"Technologie?
Das machen die Teams"
"architecture are the parts that are hard to change later"
Qualität 100%
Kunden 0%
Engineering-Driven
Startups
Stakeholder-Driven
Startups
Das Problem mit der Architektur:
Wieviel ist genug?
Die Kathedrale und
der Basaar
Intentional Architecture
Emergent Architecture
Intentional vs
Emergent Architecture
Und wie geht man jetzt vor?
Stakeholderinteressen
Business Drivers
Features
Nonfunktionale
Anforderungen
Verantwortung des
Product Owners.
Architecture
TradeOff
Analysis
Method
Qualitätskriterien
ISO 25010
Verantwortung des
Product Owners.
Realoptionen
Die Qualitätskriterien der ungewissen Zukunft
Verantwortung des
Product Owners.
Verantwortung des
Product Owners.
Workshop
mit dem C-Level
Szenarien
"Wenn die Plattform erfolgreich wird wollen wir innerhalb von 3 Monaten 50.000 parallele Nutzer können."
"Wenn mehrere Teams an der Plattorm arbeiten, sollen sie nicht voneinander blockiert werden."
"Wenn ein Kunde mit DSGVO-Anforderungen kommt soll ein On-Premises-Betrieb innerhalb von 2 Monaten möglich sein"
-
Monolith
-
Layered Monolith
-
MiniServices
-
MicroServices
-
Cloud Native
-
NoCode
Architektur
Architectural Katas
-
Preparation: Team und Aufgabe
- Discussion Phase: Freie Diskussion & Konzept
- Peer Review Phase: Präsentation und Diskussion
- Voting: Feedback und Abstimmung zu jeder Variante
Product Owner für Fragen &
Knowhowtransfer
Voting durch Tech
TradeOffs und Defizite abwägen durch den
Product Owner.
Ok, das ist der Plan.
Aber eben nur der Plan.
Evolutionäre / Emergente Architektur braucht Training.
Könnten wir jetzt auch 5x so viele Nutzer?
Sind die Services wirklich unabhängig?
Können wir wirklich Fehler schnell fixen?
Architectural
Fitness Functions
Architectural
Fitness Functions
- Atomar oder Holistisch - Unit Tests & Load Tests
- Triggered oder Kontinuierlich - Nutzertests & Security-Scans
- Statisch oder Dynamisch: Failed & 5% schlechter
- Automatisiert oder Manuell: Code Inspection & Technisches Audit
Der Product Owner ist der auch der Owner der Fitness Functions.
Der Product Owner ist der auch der Owner der Fitness Functions.
Dashboards!
Dashboards und Fitness Functions sind Enabler des Product Owners.
Architectural Enablers
"Architekturaufgaben, die man nicht so eben einer User-Story untermogeln kann."
Epics für Architektur
https://www.scaledagileframework.com/program-and-solution-backlogs/
https://www.scaledagileframework.com/program-and-solution-backlogs/
Opportunitische Integration
wird hier genutzt
Und wenn wir später entscheiden?
ADRs!
Architectural Decision Records
Der Product Owner ist als Stakeholder beteiligt und muss die Konsequenzen sehen.
Architectural Decision Records
Leben im Code
Als Changelog der Architektur
tl;dl
- Business-Driver sichtbar machen
- Architekturentscheidungen auf Basis der Businesstreiber fällen
- Fitness Functions zur Nachhaltigkeit
- Spätere Entscheidungen über ADRs
- PO ist Lieferant & Kunde der Entwickler & Architekten
- Fitness Functions und Dashboards sind Deliverable von Team an den PO & Business, nicht interner Zweck
Softwarearchitektur für Product Owner
By Johann-Peter Hartmann
