Architekturen
zähmen leicht gemacht
Vom Anforderungs-Chaos zu strukturiertem Code
Warum Architektur?
- Unvermeidbare Basis jeder Software
- Frühzeitige Fehlererkennung durch geplante Strukturen
- Vermeidung von unkontrollierbarer Legacy-Software
- kontinuierliche Anpassung
Warum Architektur?
Haus der Geschichte, Darmstadt
Internetfund, toter Vogel
Methoden zur Architekturgestaltung
Wo fängt man an?
Wie startet man?
Was soll dokumentiert werden?
Grundelemente
- Unabhängige Bausteine
- Beziehungen/Relationen über definierte Schnittstellen
- Konzepte und Prinzipien
Kontext
- Anpassung an Geschäftsziele und -umfeld
- rechtliche und technische Rahmenbedingungen
- Balancierung konkurrierender Projektfaktoren
1. Stakeholder-Prio-Matrix
1. Stakeholder-Prio-Matrix
begleitend zur Matrix eine übersichtliche Tabelle
Beispiel:
| Rolle | Beschreibung | Ziel/Intention | Kontakt | Prio | Infobedarf |
|---|
| Auftraggeber | Dagobert Duck | Ertrag erzielen | …@e.mail | Hoch | aktueller Stand |
| Betreiber | Rechenzentrum | SaaS anbieter | …@e.mail | Medium | Betriebshandbuch |
| Besucher | Kunde | Dienst nutzen | | Medium | FAQ |
| … |
2. Architectural Significant Requirements
- Funktionelle Anforderungen
- Randbedinungen
- Nicht-Anforderungen
- Qualitätsanforderungen
2. Architectural Significant Requirements
Hilfestellung ISO25010 und Qualitätsbaum
/>
2. Architectural Significant Requirements
Beispiel
| Funktionell | Randbedingung | Nicht-Anforderungen | Qualitätsanforderungen |
|---|
| Profil Nutzer (F1) | mehrere Nutzer (R1) | Dezentrales System (N1) | Skalierbar auf ca 300-3 Mio. Nutzer, R1 (Q1) |
| Registrierung/Login (F2) | Personenbezogene Daten (R2) | MFA/2FA (N2) | Transportsicherheit, F1, F2, R2 (Q2) |
| Bilder Upload (F3) | Nicht-technik-affine Nutzer (R3) | iOS App (N3) | Bearbeitung vollständig in GUI, R3 (Q3) |
| … | … | … | … |
3. Kohäsionskriterien
Clustern der ASR nach Kriterium
- Funktion
- Eigenschaft
- Inhalt
- Services
- …
keine Kriterien mischen!
3. Kohäsionskriterien
Beispiel
4. Architecture Decision Record
- in Architektur dreht sich alles um Entscheidungen
- Entscheidungen diskutieren und mit Anforderungen abgleichen
- Entscheidungen systematisch festhalten
- Regel: Kill your Darlings
4. Architecture Decision Record
Grundlegender Aufbau:
| ADR | #Nr |
| Warum: | (Um was geht es?) |
| Einflüsse: | (Stakeholder) |
| Kriterien: | (Anforderungen) |
| Alternativen: | (Vergleichen) |
| Konsequenzen: | (Positiv/Negativ) |
4. Architecture Decision Record
Beispiel 1/3:
| ADR | #1 |
| Warum: | Basis Aufbau der Anwendung |
| Einflüsse: | - Developer - bestehendes Wissen
- 3rd Party APIs - DX, Kosten, Support, Doku
- Hacker - Security
- Nutzer - Performance, Usability
|
4. Architecture Decision Record
Beispiel 2/3:
| Kriterien: | - Shared Codebase für App und Web
- Parallele Bearbeitung von X Profilen
- User Management
- DSGVO Konform
|
| Alternativen: | | Alternative | 1 | 2 | 3 | 4 |
|---|
| Client-Server | 0 | + | + | + | | Microservices | + | + | + | - | | Event Driven | + | + | - | + |
=> Wahl fällt auf Client-Server |
4. Architecture Decision Record
Beispiel 3/3:
| Konsequenzen: | - (+) Monolith, nur einmal entwickelt
- (-) ein gesamtes System, abhängige Skalierung
- (+) Governance
- (-) Last Verteilung
|
Agile Architektur
Dokumentation
- Klarheit und Konsistenz
- Anpassung an die Bedürfnisse verschiedener Stakeholder
- Wartung der Dokumentation als Teil des Entwicklungsprozesses
Dokumentation
- Angemessenheit
- Korrektheit
- Wartbarkeit
- Verständlichkeit
Arc42
Cards42
Blickrichtung ändern, neue Wege und Lösungen finden
iSAQB
Viele Fachartikel, Podcast & Fortbildungen
Roadmap.sh
Guter Startpunkt, mehr technische Anforderungen & Verständnis
Zeit für eure Fragen
& Diskussionen
WieErWill.dev/vcard.vcf
