Post on 27-Jul-2020
Skalierung von
Architektur-Reviews in
der Praxis STEFAN TOTH
München
12. Oktober 2017
0
2Skalierung von Architekturreviews in der Praxis embarc.de
Stefan Toth
stefan.toth@embarc.de
xing.to/sto
www.embarc.dewww.swamuster.de
@st_toth
3Skalierung von Architekturreviews in der Praxis embarc.de
Gründe für Architekturreviews
▪ Aktuelle Probleme mit der Lösung
▪ Es gibt Schwierigkeiten bei der Auslieferung
▪ Die Software läuft zu langsam, nicht robust genug
▪ Änderungen an der Software werden immer schwieriger/teurer
▪ Wir habe wenig Einblick (und/oder Vertrauen) in die Entwicklung
▪ Wir haben einen Zulieferer für (Teil-)Lösungen
▪ Wir wollen mehrere Angebote oder Kaufprodukte bewerten
▪ Die Entwicklung hat offensichtliche Schwierigkeiten (Stabilität z.B.)
▪ Uneinigkeit, wie in die technische Lösung investiert werden muss
▪ Wir haben Budget, wollen wissen wie es am besten investiert ist
▪ Entscheidungsträger sollen notwendige Veränderungen sehen
▪ Verteilte Architekturaufwände sind schwer überblickbar
4Skalierung von Architekturreviews in der Praxis embarc.de
Architektur-
ReviewsWas kann man tun?
5Skalierung von Architekturreviews in der Praxis embarc.de
6Skalierung von Architekturreviews in der Praxis embarc.de
7Skalierung von Architekturreviews in der Praxis embarc.de
8Skalierung von Architekturreviews in der Praxis embarc.de
9Skalierung von Architekturreviews in der Praxis embarc.de
Was lässt sich ad-hoc bewerten?
• Konzeptionelle Integrität
• Einhaltung von Best-Practices
Best-Practices passen nicht immer zum Problem:
„Vermeide Verteilungsgrenzen“
Allerdings:
Eigener Erfahrungsschatz und Kontext ist sehr wichtig.
Viele implizite Annahmen!
10Skalierung von Architekturreviews in der Praxis embarc.de
Artefakte von Architektur-Reviews
Dinge gegen die wir evaluieren können:
Dinge die das System ausmachen:
11Skalierung von Architekturreviews in der Praxis embarc.de
Analysemöglichkeiten
12Skalierung von Architekturreviews in der Praxis embarc.de
Analysemöglichkeiten
Metrik/
Struktur-
Tools
13Skalierung von Architekturreviews in der Praxis embarc.de
Analysemöglichkeiten
Dynamische
Analyse
Tools
14Skalierung von Architekturreviews in der Praxis embarc.de
Analysemöglichkeiten
ATAM
(qualitative
Analyse)
15Skalierung von Architekturreviews in der Praxis embarc.de
ATAM gibt einen guten Rahmen
Welche?
Ergänzung
in oder nach
Workshops
16Skalierung von Architekturreviews in der Praxis embarc.de
Das große
Assess-
ment5 - 40 Tage
17Skalierung von Architekturreviews in der Praxis embarc.de
Schritte eines großen Assessments
Kommunikation
Zusammenfassung Report/Präsentation
Ergebniserarbeitung
Verdichtung der Erkenntnisse Ableitung von Maßnahmen
Statische und dynamische Analyse
Statische Analyse Dynamische Prüfung Konformanz
Qualitative Bewertung
Workshops und Durchsprachen
Bewertungsmaßstab
Evaluationskriterien Rahmenbedinungen Architekturüberblick
18Skalierung von Architekturreviews in der Praxis embarc.de
19Skalierung von Architekturreviews in der Praxis embarc.de
Einstieg über die Lösung
20Skalierung von Architekturreviews in der Praxis embarc.de
Wichtige Ziele
21Skalierung von Architekturreviews in der Praxis embarc.de
Management Ziele für die
Architektur
Skalierbarkeit in der Entwicklung
1
Unabhängige Umsetzungsteams
2
Anbindungs-möglichkeit /
Offenheit
4
Mandanten-fähigkeit
5
Einheitliche Auftragslogik
6
Anpassbarkeit der Prozesslogik *
7
Durchgängige Messbarkeit für
Prozesse *
8
Auskunftsfähigkeit zu Aufträgen *
12
Omnichannel-Fähigkeit
10
Automatisierung von Fachprozessen
9
Stabilität und Sicherheit
3
Effizienz in Kosten und Aufwand
11
Fachbereich
IT
Quelle des Ziels
Ziele aus dem zentralen Management
Effizienz in der Sachbearbeitung
(IF und VIF)
13
Usability der Anwendungen
14
Parametrisierbarkeit
& Anpassbarkeit
15
Experimentier-fähigkeit &
Time 2 Market
16
Ziele des operativen Managements und der Architekten
22Skalierung von Architekturreviews in der Praxis embarc.de
Der Standard dazu…
23Skalierung von Architekturreviews in der Praxis embarc.de
Grobe Priorisierung der Themen
24Skalierung von Architekturreviews in der Praxis embarc.de
Szenarien
25Skalierung von Architekturreviews in der Praxis embarc.de
Verfeinerung der Ziele: Utility Tree
(Bewertungskriterien)
26Skalierung von Architekturreviews in der Praxis embarc.de
Architekturüberblick
27Skalierung von Architekturreviews in der Praxis embarc.de
Besprechung der Szenarien
28Skalierung von Architekturreviews in der Praxis embarc.de
Realitätscheck
Structure101
29Skalierung von Architekturreviews in der Praxis embarc.de
Statische / Dynamische Code-Analyse
30Skalierung von Architekturreviews in der Praxis embarc.de
Laufzeitanalyse
31Skalierung von Architekturreviews in der Praxis embarc.de
Review-Bericht
32Skalierung von Architekturreviews in der Praxis embarc.de
Architekturansätze
Basis-Frameworks und
Technologien
bilden die technologische
Grundlage der Lösung
Konzepte und Muster beschreiben die darauf
aufbauenden Architekturideen
Entwicklungswerkzeuge beschreiben die Ansätze der
Softwareentwicklung selbst
Architekturansätze zusammenfassend bewertet. Die Ansätze werden drei
Bereichen zugeteilt :
Legende für die Architekturansatz-Tabellen:
Ja / gut Naja / mittel Nein / schlecht
33Skalierung von Architekturreviews in der Praxis embarc.de
Hindernisse (Probleme) gesammelt
34Skalierung von Architekturreviews in der Praxis embarc.de
Hindernisse, die auf viele Ziele wirken
3
4
Prozessänderungen
aufwändig / schwierigz.B. nötige Arbeitsschritte zur
Entwicklung mit der BPE und
dem Vorgang.H5
Keine einheitliche
Prozessgestaltung (im
System und in der
Organisation) H6
Ungünstige / unnötige
Abhängigkeiten in der
Middleware erhöhen
Komplexität. H10
Skalierbarkeit in der Entwicklung
1
Unabhängige Umsetzungsteams
2
Anpassbarkeit der Prozesslogik
7
Automatisierung von
Fachprozessen
9
Effizienz in Kosten und Aufwand
11
Einheitliche Auftragslogik
6
Durchgängige Messbarkeit für
Prozesse
8
Auskunftsfähigkeit zu Aufträgen
12
Effizienz in der Sachbearbeitung
(IF und VIF)
13
Anbindungs-möglichkeit /
Offenheit
4
Mandanten-fähigkeit
5
Hindernisse, mit Bezug auf 4 oder mehr Ziele
Legende
Ziel
Hindernis
35Skalierung von Architekturreviews in der Praxis embarc.de
Hindernisse zum Ziel
Skalierbarkeit in der Entwicklung
3
5
Unabhängige Lieferung von
vertikalen Features nicht
vorgesehen. z.B. „Neuer Self
Service Baustein in XY“.H18
Schnittstellen zu
Umsystemen sind nicht gut
gekapselt.H35
Ungünstige / unnötige
Abhängigkeiten in der
Middleware erhöhen
Komplexität. H10
XY Komplexität erfordert
umfassende Analyse und
Tests bei Erweiterungen.
H32
Fachbereich
IT
Quelle des Ziels
Skalierbarkeit in der Entwicklung
1
H14
Externer Zugriff für entfernte
Entwicklungsteams nicht
möglich.H14
Prozessänderungen
aufwändig / schwierigz.B. nötige Arbeitsschritte zur
Entwicklung mit der BPE und im
VorgangH5
Unabhängige Entwicklungs-
teams kaum möglich.
Umfassendes Wissen von
Domänen notwendig, um diese
zu verwenden. H36
36Skalierung von Architekturreviews in der Praxis embarc.de
Ergebnisverdichtung (für Mgmt)
Zuverlässigkeit
Funktionale Tauglichkeit
(incl. Korrektheit)
Performance
Usability
WartbarkeitUser error protection und
‘hardening’ nicht im Fokus
Teilweise verursacht von
Den gleichen Kapazitäts-
problemen
Tradeoff:
Flexibilität vs. Performance
Flexibilität vs. Testability
37Skalierung von Architekturreviews in der Praxis embarc.de
Erste Empfehlungen verorten…
Usability
Anforderungen müssen klarer/
detaillierter formuliert werden
Kunden müssen in manchen
Bereichen mit ‘OK’ leben
Tests zu dünn, müssen
ausgebaut werden
2-tier Architektur nicht
Ideal für Wiederherstellbarkeit
Wartbarkeitsprobleme
haben Auswirkungen
auf Stabilität und
Korrektheit
Zuverlässigkeit
Funktionale Tauglichkeit
(incl. Korrektheit)
Performance
Wartbarkeit
38Skalierung von Architekturreviews in der Praxis embarc.de
Eine schlanke
Alternative1 - x Tage
39Skalierung von Architekturreviews in der Praxis embarc.de
Qualitätsziele grob zusammenfassen
“Amazon is customer obsessed! If
only one customer complains, we take
the feedback and improve the system”
“Netflix-Members are able to watch tv
series and films – as much as they
want, any time, everywhere, on every
internet-connected device out there.”
“Available everywhere, Great user
experience, More convenient than
piracy, Fast, reliable, always available,
Scalable for many, many users.”
40Skalierung von Architekturreviews in der Praxis embarc.de
Brainstorming von Zielen
41Skalierung von Architekturreviews in der Praxis embarc.de
H/M/L Bewertung
Szenarien mit hoch/mittel/niedrig bewerten in:
▪ Fachliche Wichtigkeit
▪ Technische Schwierigkeit / Risiko
In ATAM:
42Skalierung von Architekturreviews in der Praxis embarc.de
Gesamtlücke schätzen:
Zuverlässigkeit
Portierbarkeit
Performance
Skalierbarkeit
Wartbarkeit Anzahl der technisch “H”
Einschätzungen führt zu
Verfehlung des Zielwerts
43Skalierung von Architekturreviews in der Praxis embarc.de
Fokusthemen analysieren
Beliebig tief und iterativ…
44Skalierung von Architekturreviews in der Praxis embarc.de
Iterative Schärfung des „Ergebnisses“
Zuverlässigkeit
Portierbarkeit
Performance
Skalierbarkeit
Wartbarkeit Durchsprachen / Analysen
Schärfen die Lücken
45Skalierung von Architekturreviews in der Praxis embarc.de
Schritte eines kleineren Reviews
Fokusthemen besprechen
Kompromisse herausstellen Ableitung von Maßnahmen
H/M/L Bewertung und Lücken
Technische Risiken identifizieren Gesamtlücke schätzen
Brainstorming von Zielen
Szenarien in Utiliy Tree Lücken schließen
Top-Qualitätsmerkmale bestimmen
ISO-Norm und Idee Ein Satz zur Qualität
46Skalierung von Architekturreviews in der Praxis embarc.de
Baby-Reviews
(für Anfänger
oder Eilige)30 – 120 min
47Skalierung von Architekturreviews in der Praxis embarc.de
Das Pre-Mortem
48Skalierung von Architekturreviews in der Praxis embarc.de
Pre Mortem Ablauf
Pre-Mortem einführenMethode kurz vorstellen, Modus
erklären
1
Gründe des ScheiternsBrainstorming: Was ist passiert?
Clustern
2
Risiken priorisieren%, € und: Was ist technisch
beeinflussbar?
3
MitigierungsstrategienKonkrete technische/methodische
Verbesserungen
4
10 min 20 min
30 min 60 min
49Skalierung von Architekturreviews in der Praxis embarc.de
Reality Check für Architekturziele
50Skalierung von Architekturreviews in der Praxis embarc.de
Skalierung von
ReviewsWie groß ist groß genug?
51Skalierung von Architekturreviews in der Praxis embarc.de
Skalierungsfaktoren
2h 20d(und mehr)
organisatorische Komplexität
Anzahl der Stakeholder
Grad der Unsicherheit / Uneinigkeit
Kritikalität der Situation
Benötigte Konfidenz
Zustand der Dokumentation /
Wissen in der Organisation
Systemgröße
52Skalierung von Architekturreviews in der Praxis embarc.de
Reviews im Agilen
(iterativ verzahnt)
53Skalierung von Architekturreviews in der Praxis embarc.de
Iterative Architekturarbeit...
6
55Skalierung von Architekturreviews in der Praxis embarc.de
Szenarien als Anforderungen
▪ Der Algorithmus zur Berechnung der Artikelbeliebtheit ist
leicht anpassbar und austauschbar.
▪ Ein Benutzer arbeitet mit der App während der
bearbeitende Server ausfällt. Er merkt von dem Ausfall
nichts, selbst wenn er die auf vorige Seiten
zurückspringen möchte oder weiter navigiert.
▪ Für Wartung und Erweiterung des Systems findet man
am "freien Markt" leicht Unterstützung.
56Skalierung von Architekturreviews in der Praxis embarc.de
Szenarien kategorisieren
57Skalierung von Architekturreviews in der Praxis embarc.de
Szenarien im Backlog
58Skalierung von Architekturreviews in der Praxis embarc.de
Reflexion – 1. Themen finden
Blick auf die Architektur als Ganzes:
▪ Was hat sich in letzter Zeit am Big-Picture verändert?
▪ Wo waren die größten technischen Aufwände?
Blick auf die Anforderungsseite:
▪ Welche Szenarien wurden bearbeitet?
▪ Welche technischen Schulden wurden abgearbeitet?
59Skalierung von Architekturreviews in der Praxis embarc.de
Gesammelte Themen priorisieren
60Skalierung von Architekturreviews in der Praxis embarc.de
2. Durchsprache
▪ Wie wurde das Thema/die Fragestellung bearbeitet?
Relevante Ansätze und Entscheidungen
▪ Gab es Probleme bei der Lösung?
Behindernde Architekturansätze/Organisation, Schulden
▪ Sind vorgestellte Lösungen nachvollziehbar?
Verständlichkeit und Fokus
▪ Sind alle Aspekte der Fragestellung abgedeckt?
weitere Entscheidungen, offene Punkte, Risiken
▪ Negative Auswirkungen vorgestellter Entscheidungen? Kompromisse zu anderen Fragestellungen, Risiken
Fragen an Bearbeiter (Vorstellung)
Fragen für Bewerter (Exploration)
Danke.Jegliche Fragen sind willkommen!
stefan.toth@embarc.de
xing.to/sto
@st_toth
DOWNLOAD FOLIEN:
http://www.embarc.de/blog/
62Skalierung von Architekturreviews in der Praxis embarc.de
Spicken erlaubt!Unsere Architektur-Spicker
beleuchten die konzeptionelle
Seite der Softwareentwicklung.
Spicker #4:
„Architektur-Reviews“
• Was leisten Architektur-
Reviews?
• Welche Methoden und
Werkzeuge helfen?
• Wer sollte wann und wie oft in
Reviews eingebunden sein?
PDF, 4 Seiten
Kostenloser Download.
architektur-spicker.de
63Skalierung von Architekturreviews in der Praxis embarc.de
Klingt interessant?
Sprich uns gerne direkt an oder schicke eine Mail an Tabea.Hentschel@embarc.de
Berater/in gesucht!
für Softwarearchitektur / Agilität / CD & DevOps / Microservices(Standort flexibel in Deutschland oder Wien)
▪ Du brennst für ein Thema und bist motiviert, Dich mit aktuellen Trends
tiefer auseinander zu setzen?
▪ Du hast eher zu viele Ideen als zu wenige?
▪ Du teilst Deine Erkenntnisse und Erfahrungen gerne mit Kollegen
und denkst Themen weiter?
▪ Du stehst auf Pragmatismus, nicht auf Mikro-Management?
embarc.de/karriere
„Wir glauben weniger an ausgefeilte interne Strategien,
als an die Möglichkeiten die entstehen wenn sich leidenschaftliche Leute zusammenschließen.“
Bereit zum Durchstarten?
Da haben wir was...