Post on 21-Mar-2017
Architek(ul)tur – wie bekommen wir Architekturarbeit in den Alltag rein?
Matthias Bohlen http://mbohlen.de @mbohlende +49 170 772 8545
Hacking — Foto: Johan Viirok
Warum Architek(ul)tur einführen?
Eines Tages enden alle ernsthaften Systeme hier:
Wartungskosten steigen Produkt hat voll vernetzte Abhängigkeiten Komplexität nicht mehr zu bewältigen Company muss Produkt "aufräumen"
2©
Woraus besteht eigentlich "Kultur"?
3©
Verhaltensweisen "So machen wir das hier".
Darstellungsformen "So beschreiben wir unsere Welt."
Wertvorstellungen "Diese Dinge sind uns wichtig."
OOPSLA 1992
5
Publikum:Mr. Beck, was istSoftwarearchitektur?
Softwarearchitektur? Das ist das, was Softwarearchitekten machen.
Publikum (kichert):Also dann, was ist einSoftwarearchitekt?
Hmm, Softwarearchitekt ist ein neuer pompöser Titel, den Programmierer auf ihrer Visitenkarte haben wollen, um ihre üppigen Bezüge zu rechtfertigen.
Extreme Programming Explained (2000)
6
"Softwarearchitektur ist in XP-Projekten genauso wichtig wie in irgendeinem Softwareprojekt.
... Nimm Dir für die erste Iteration einen Satz von Stories, der Dich zwingt, die ganze Architektur zu erschaffen. Am Ende dieser Übung wirst Du Deine Architektur haben. Es könnte sein, dass es nicht die ist, die Du erwartet hast, aber Du wirst etwas gelernt haben.
... Ich setze die Architektur rein, die ich jetzt brauche und vertraue auf meine Fähigkeit, sie später zu ändern."
Coach für effektive ProduktentwicklungMatthias Bohlen
Architektur
ISO 42010: "architecture"
die fundamentalen Konzepte oder Eigenschaften eines Systems in seiner Umgebung, verkörpert in seinen Elementen, Beziehungen und den Prinzipien für sein Design und seine Evolution
7
Die elende Bau-Metapher
8Der Architekt erklärt
Der Entwickler baut
Foto: Anna Oakley
Wenn überhaupt Bau, dann...
9
Architekten und Entwickler
entwerfen
Der Compiler baut
Coach für effektive ProduktentwicklungMatthias Bohlen
Aufgaben von SoftwarearchitektenAnforderungen und Randbedingungen klären, hinterfragen, verfeinern
insbesondere geforderte Qualitätsmerkmale
Strukturentscheidungen treffen Bausteine und Schnittstellen festlegen
Übergreifende technische Konzepte entscheiden Persistenz, Kommunikation, GUI, etc.
Software-Architektur kommunizieren und dokumentieren Umsetzung und Implementierung der Architektur überwachen
Rückmeldungen der beteiligten Stakeholder einarbeiten
Konsistenz von Quellcode und Softwarearchitektur sicherstellen Software-Architektur bewerten
hinsichtlich Risiken bezüglich der geforderten Qualitätsmerkmale
10
Form versus Struktur
11
Struktur stützt Form Form ermöglicht Verhalten
Form
"Essenz" der Struktur wahrnehmbar, interessant wertliefernd konstant
12Foto: Maik Maid
Struktur
notwendig für die Form wahrnehmbar, doch weniger interessant Kosten erzeugend stabil
13Foto: Ralph Aichinger
Verhalten
das, was in der Form passieren kann interessant Nutzen stiftend variabel, flexibel
14Foto: Benjamin Thompson
15
Form Struktur Verhalten
Essenz der Struktur Stütze der Form was in der Form passiert
wahrnehmbar notwendig interessant
Wert liefernd Kosten erzeugend Nutzen stiftend
konstant stabil variabellean agil
16
Was das System ist Was das System tut
FormSubsysteme
Interfaces, APIs Domänenobjekte
Use Case Kontext
Rollen-Interfaces
StrukturPakete Klassen
Rollen-Implementierungen Algorithmen
"Form? Struktur? Wovon redest Du eigentlich?"
Coach für effektive ProduktentwicklungMatthias Bohlen
17Das Bild stammt aus dem Buch "Vorgehensmuster für Softwarearchitektur" von Stefan Toth
Coach für effektive ProduktentwicklungMatthias Bohlen
Zusammenarbeit
18
Architekturrunde
Saturn-
Team
Neptun-
Team
Architektur
Saturn-BacklogNeptun-Backlog
Saturn Neptun Delegation
Delegation
19
Was das System ist Was das System tut
FormSubsysteme
Interfaces, APIs Domänenobjekte
Use Case Kontext
Rollen-Interfaces
StrukturPakete Klassen
Rollen-Implementierungen Algorithmen
Form geht alle an! Form ändert sich seltener als Struktur!
Daher: Im Architekturteam die Form aufbauen, in den anderen Teams die Struktur schaffen!
Foto: Casey Hussein Bisson
Transfer in die Praxis
20
Einstimmung – 10’
Gruppenarbeit – 30’
Ergebnis-Präsentation – 40’
Wie geht’s weiter? – 10’
Ausklang.
Transfer-Workshop
Organisation & Zusammenarbeit
1. Wie organisieren wir uns als Architektur-Team,-Runde, -Gilde, oder was sonst?
2. Wie starke Vorgaben macht dieses Architektur-"Etwas"? Sind wir Agenten, unterstützende oder gar klassische Architekten (siehe Bild aus dem Buch von Stefan Toth)?
Erwartungen an Architekten und Teams
3. Welche Erwartungen an die Architektenrolle gibt es? (Aufgaben und Verantwortung)
4. Welche Erwartungen gibt es zukünftig an die Teams? (Gibt es eine Abgrenzung: was macht das Team, was machen die Architekten?)
Architekturarbeit im Tagesgeschäft
5. Wie sieht die Architekturarbeit als Items im Backlog aus?
6. Wenn Architekturarbeit im Backlog auftaucht, welche Erwartungen gibt es dann zukünftig an die POs?
ArchitectureElevator Pitch
• Wie erklären wir Architektur unseren Kunden oder Auftraggebern?
Eure Ergebnisse bitte…
.
Wie es weitergeht…1-2 Workshops
pro Themenpaar, je 4-7 Leute
Demnächst wissen wir, wie wir Architekturarbeit tun!
Jetzt registrieren!
Wer kann und will zu welchem Thema
beitragen?
Organisation & Zusammenarbeit
Erwartungen an Architekten
und Teams
Architektur-arbeit im
Tagesgeschäft.
2 Teams während der Lernphase
Fachliche Architektur mit Domain Driven Design
Technische Architektur mit Prototyping
Achtung: Diese Struktur nur kurzzeitig behalten!
Domain Driven Design Technische Architektur
Skillmatrix liefert Ausbildungsbedarf
3 = ich kann das völlig neu aufbauen
2 = ich kann dazu beitragen
1 = ich kann es lesen
0 = ich weiß nichts
ModellierungswissenABC DEF GHI JKL MNO PQR STU VWX YZA BCD EFG HIJ KLM 3er
Objektorientiertes Modellieren
3 1 2 3 3 0 1 2 3 1 1 3 1 5
Methodik DDD 2 0 1 2 1 0 2 1 2 0 1 1 1 0
UML reduziert 2 1 2 2 2 1 2 3 3 2 2 3 2 3
Architektur-Basics
2 1 2 2 2 1 1 3 3 1 1 2 1 2
UML-Tool 2 0 1 0 1 0 1 2 2 0 2 2 1 0
Englisch 3 3 3 3 3 3 3 3 3 3 3 3 2 12
Kickoff der Arbeiten
System aus Bausteinen aufbauen
Nicht als Monolith, sondern als Bauwerk aus vielen Steinen
Vorbild: Lego-Künstler Nathan Sawaya
Nathan Sawaya: siehe http://www.brickartist.com
Domain Driven Design = fachliche Bausteine
9 Bausteine
um zu beschreiben, woraus das System fachlich besteht
Entity Value Object
Service AssociationBusiness Event
Module
Factory
Repository
Aggregate
Abbildung auf die TechnikTechnische Architektur
ebenfalls mit definierten Bausteinrollen
Realisierung durch Prototypen und Bewertung
Schulungen
User Stories & Use Cases
Tactical Design
Strategic Design
Grundlagen der SW-Architektur
Agile SW-ArchitekturFoto: tapetenpics
Von der User Story…
Story-Karte
Review submissionReviewer can review a submission so that the chairman will know how good it is.
How to demo: 1. System lists submissions assigned to this reviewer 2. Reviewer selects submission for download 3. System serves document file 4. Reviewer assigns rating: A (strong) to D (poor)
300
3857
5
Use Cases schreiben
die "rechte Seite" macht's !
BEZEICHNER: <DK>.<UK> (DK = Domänenkürzel, UK = Use Case Kürzel)
TITEL: <irgendetwas mit dem System tun>
NUTZEN IM KONTEXT: <Kurzbeschreibung dessen, was der Benutzer als Ziel bzw. Vorteil hat>
UNTERSTÜTZTE USER-ROLLEN: <Rollenname>
VORBEDINGUNGEN: <Was bereits gelten muss, damit der Use Case überhaupt starten kann>
BENUTZERINTENTION SYSTEMVERANTWORTLICHKEIT
NACHBEDINGUNGEN: <Was auf jeden Fall gilt, sobald der Use Case gelaufen ist>
Akzeptanztests dazu erstellen
Genial für das gemeinsame Verständnis zwischen Business und IT
GIVEN <Situation> WHEN <Event> THEN <Result>
Abbilden auf Domain Services & Entitäten
Aus den Abläufen der "rechten Seite" Service-Funktionen gewinnen
Aus den konzeptionellen Begriffen Entitäten gewinnen
Entity
Entity
Service
Domänenmodell entwerfen
Bausteine zusammensetzen
im UML-Tool durchmodellieren
publizieren
Feedback einholenFoto: Lego Photo mureut
Leitfragen helfen, die Gedanken zu lenken
Leitfrage aufstellen
Architekturansatz dazu wählen
Prototyp dazu erstellen
Ergebnisse bewerten und aufschreiben
Bild: Chris Potter
Architekturansätze wählenJavaEE versusSpring Boot
Single Page versus Multi Page UI
Microservices versus Self Contained Systems
etc.Bild: Forgemind Archimedia
Pro und contra für jeden Architekturansatz
Bewertungskriterien aufstellen
Ansätze bewerten
Ergebnisse publizieren
Feedback einholenFoto: Tim Rizzo
Foto: Casey Hussein Bisson
Wachstums-schmerzen
48
Domain Driven Design Technische Architektur
Bounded Context 1 Bounded Context 2
Teams neu "schneiden"
Bisherige Teams: Fokus auf's Prototypen und Lernen
Neue Teams: Fokus auf verwendbare Resultate
Onboarding: Neue Leute kommen ins Team
Leute, welche die Historie nicht haben
und die Architektur-ansätze nicht (sofort) teilen
Aufgabe: Das "Große Warum?" bewältigen
Foto: banoootah_qtr
Bewertete Architekturansätze entscheiden
Entscheidungs-workshop zum Piloten Was haben wir schon entschieden? Was müssen wir jetzt noch entscheiden? Welche Dinge können wir später entscheiden?
Foto: Katie Lips
Unit-Testen, entwickeln, akzeptanztesten
Erste "ernsthafte" Story
Soll vorzeigbar sein
Soll zeigen, ob gewählte Architektur die Qualitätsziele tatsächlich erfüllt
Continous Integration and Deployment
Build-Server
Images als Ergebnisse
Demoserver, auf dem alles jederzeit läuft
Wenn genügend viele Stories umgesetzt sind
Erfahrungen dokumentieren
Am besten als How-To
Publizieren
How-Tos pro Team zu einem Prozess zusammensetzen
Prozess einübenFoto: Michael Havens
Organisation an Soll-Architektur anpassen
Teams: schnell, autark releasefähig
Warten nicht auf einander
Optimal: Jeder Bounded Context hat genau ein Team als Owner !
Team 1 Team 2
Bounded Context 1a Bounded Context 2Bounded Context 1b
Feedback-Mechanismen fest etablieren
Akzeptanztests für Business Value und Service-Verhalten
statische Prüfungen im Build-Lauf
Reviews durch Peers, Domänenexperten und User
Team Ergebnis
Lieferung
Feedback
Zusammenfassung: Architek(ul)tur verankern
Grundlagen legen Praxistransfer Teambildung Ausbildung Prototyping Pilotierung Reifung
Foto: Thomas Kohler
Die Abkürzung zum Erfolg
Sie tun es selbst
mit mir als "Remote Coach"
Rufen Sie mich an.
Coaching nehmen
Seminar besuchen
Newsletter abonnieren
Beginnen Sie jetzt!
Newsletter, Blog, Artikel, Bücher, Podcast, Videos:http://mbohlen.de
Anrufen: +49 170 772 8545
Fotos: Sarah Brabazon, Friends of Europe, iStockPhoto