Agile Softwareentwicklung stellt die zwischenmenschliche Kommunikation in den Vordergrund, was dazu führen soll, das Richtige richtig zu implementieren und Software schneller ausliefern zu können. Doch wie dokumentieren agile Teams ihre Softwarearchitektur? Herkömmliche Vorgehensweisen wirken zu schwergewichtig, da sie sich eher für Wasserfall-Projekte eignen. Sollten architekturrelevante Entscheidungen überhaupt dokumentiert werden? Und wie fügt sich eine geeignete Methode in die agile Arbeitsweise ein? In diesem Vortrag wird eine leichtgewichtige Methode zur Dokumentation von Softwarearchitektur vorgestellt. Diese hält Architekturentscheidungen in Architecture Decision Records (ADR) fest. Ein kompaktes Format, angereichert mit Zusatzinformationen, wie Kontext und Randbedingungen. Nicht-funktionale Anforderungen werden als Qualitätsszenarien beschrieben, deren Erfüllung durch die ADRs geprüft werden kann. So wird die Dokumentation ein Instrument zur Kommunikation mit allen Stakeholdern

1. Johannes Dienst (@JohannesDienst)
Leichtgewichtige
Softwarearchitektur
Mit Architecture Decision Records
und Qualitätsszenarien

2. Johannes Dienst (@JohannesDienst)2
Was ist eine Entwurfsentscheidung?
Code-Ebene
Bubble-Sort
statt
Merge-Sort
Solution-Ebene
Circuit Breaker
Applikations-Ebene
Hystrix

3. Architekturentscheidungen
Johannes Dienst (@JohannesDienst)3

4. Akzeptieren oder ändern
Johannes Dienst (@JohannesDienst)4

5. Johannes Dienst (@JohannesDienst)5
Wie entstehen Architektur-
entscheidungen?
Entscheidungen?

6. Johannes Dienst (@JohannesDienst)6 https://arc42.de/

7. Johannes Dienst (@JohannesDienst)7

8. Softwarearchitektur im Agilen Kontext
Johannes Dienst (@JohannesDienst)8

9. Architecture Decision Record (ADR)
Johannes Dienst (@JohannesDienst)9
Titel
Entscheidung
Status
Kontext / Hintergrund
Konsequenz(en)
Alternativen

10. Johannes Dienst (@JohannesDienst)10
ADR-3: Staging-Umgebung für CMS
Entscheidung
Wir verwenden kein Push-Publishing bzw. verschiedene Staging Umgebungen.
Status
BESCHLOSSEN
Kontext
Es wird eine Lösung gesucht um Skalierbarkeit für das gesamte System sicherzustellen.
Konsequenzen
Änderung der System-Architektur notwendig
• Abbau der beiden Public Instanzen
• Dekonfigurieren von Push Publishing
Es wird keine Umgebung zur Verfügung gestellt, auf der Content gepushed wird
Alternativen
Cluster-Lösung
• Betrieb des CMS im Cluster
Push Publishing
• Verwendung für mehrere Stages

11. Johannes Dienst (@JohannesDienst)11
Entscheidungsgrundlage?

12. Qualitätsattribute (ilities) - ISO 25010
Johannes Dienst (@JohannesDienst)12
Functional
Suitability
Software Product
Quality
Usability
Security
Performance
Efficiency
Maintainability
Compatibility Reliability
Portability

13. Qualitätsattribute (Ilities) – Im Detail
Johannes Dienst (@JohannesDienst)13
Usability
• Appropriatness Recognizability
• Learnability
• Operability
• User Error Protection
• User Interface Aesthetics
• Accessibility

14. Qualitätsworkshop
Johannes Dienst (@JohannesDienst)14

15. Johannes Dienst (@JohannesDienst)15

16. Johannes Dienst (@JohannesDienst)16
Und dann?

17. Qualitätsszenarien – Allgemeiner Fall
Johannes Dienst (@JohannesDienst)17
Mess-
kriteriumArtefakt
Umgebung
Stimulus Antwort
Quelle

18. Qualitätsszenarien – Konkreter Fall
Johannes Dienst (@JohannesDienst)18
Keine
DowntimeProzess
Normal-
betrieb
Quelle:
Heartbeat
Stimulus:
Server
unerreichbar
Antwort:
Cockpit
informieren

19. Schriftliche Form
Johannes Dienst (@JohannesDienst)19
Barkeiten Stimulus Systemzustand Messkriterium
Performanz Anfrage aus dem Internet
an den API-Gateway
System ist unter
Normallast (Load < 0.8)
80% der Anfragen werden
unter 100ms beantwortet
Automatisierbarkeit Codeänderung im
Kernsystem einspielen
System ist im
Normalzustand
Keine Downtime /
Auswirkung auf den
Benutzer sichtbar

20. Änderungsszenarien
Johannes Dienst (@JohannesDienst)20
Barkeiten Stimulus Reaktion Zielwert
Canary Releases Eine neue Version der Software
ist verfügbar
Die neue Version kann
schrittweise in den
Produktivbetrieb
übernommen werden
Ein neues Artefakt kann
kontrolliert schrittweise
ausgerollt werden

21. Zusammenbringen mit ADRs
Johannes Dienst (@JohannesDienst)21 Icons made by Freepik and Smashicons from www.flaticon.com
Qualitätsattribute Qualitätsszenarien
ADR

22. Johannes Dienst (@JohannesDienst)22
Risikomanagement
Was ist ein Risiko?
Titel
Beschreibung
Auswirkung
Eintrittswahrscheinlichkeit
Maßnahmen

23. Johannes Dienst (@JohannesDienst)23
Disclaimer:
Genau überlegen, ob der Kunde eine
ungefilterte Risikoliste verkraftet!
Risikomanagement

24. Risikomanagement
Johannes Dienst (@JohannesDienst)24
RISIKOLISTE
Budget Time Qualität

25. Learnings
Johannes Dienst (@JohannesDienst)25
ADRs als probates Mittel Entwurfsentscheidungen zu dokumentieren
Qualitätsszenarien als Kommunikationsmittel für alle Stakeholder
Diese sind anfangs schwer zu formulieren
Management von Qualitätsrisiken möglich

26. Wie geht es weiter?
Johannes Dienst (@JohannesDienst)26
Docs as Code mit AsciiDoc
Lightweight ADRs im Code
Qualitätsszenarien als ausführbare
Dokumentation

27. Welche zwei Fragen sind noch offen?
Johannes.Dienst@DeutscheBahn.com
@JohannesDienst