Stellen Sie sich vor, Sie haben fähige Entwicklungsteams, Product Owner, Projektleiter und diverse Kunden für ein existierendes, lauffähiges System. Es könnte alles so schön sein. Doch das System ist „wie Kraut und Rüben“. Die Entwicklung folgt keinen klaren Strukturen. Die Software ist viel zu schwer änderbar. Wie kriegen Sie nun diesen „Flohzirkus“ dazu, eine Kultur zu entwickeln, in der konsequent Architekturarbeit gemacht wird? Eine Kultur, in der es nicht egal ist, wie eine Komponente heißt, von welchen anderen sie abhängt und wie schnell und wie unabhängig man sie in Betrieb nehmen kann? Eben eine Kultur, in der Architektur etwas gilt und Velocity bzw. Durchsatz der Teams nicht das alleinige Ziel sind. Matthias Bohlen zeigt eine Mischung aus Bildern, Philosophien, Methoden und Tools, mit der Sie solch eine ArchiteKultur anziehen können – destilliert aus seiner Erfahrung in realen Projekten. http://the-architecture-gathering.de/

1. 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

2. 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©

3. Woraus besteht eigentlich "Kultur"?
3©
Verhaltensweisen "So machen wir das hier".
Darstellungsformen "So beschreiben wir unsere Welt."
Wertvorstellungen "Diese Dinge sind uns wichtig."

4. Foto: Casey Hussein Bisson
Grundlagen legen
4

5. OOPSLA 1992
5
Publikum:
Mr. Beck, was ist
Softwarearchitektur?
Softwarearchitektur?
Das ist das, was Softwarearchitekten machen.
Publikum (kichert):
Also dann, was ist ein
Softwarearchitekt?
Hmm, Softwarearchitekt ist ein neuer pompöser
Titel, den Programmierer auf ihrer Visitenkarte
haben wollen, um ihre üppigen Bezüge zu
rechtfertigen.

6. 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."

7. 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

8. Die elende Bau-Metapher
8
Der Architekt erklärt
Der Entwickler baut
Foto: Anna Oakley

9. Wenn überhaupt Bau, dann...
9
Architekten
und Entwickler
entwerfen
Der Compiler baut

10. Coach für effektive ProduktentwicklungMatthias Bohlen
Aufgaben von Softwarearchitekten
Anforderungen 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

11. Form versus Struktur
11
Struktur stützt Form
Form ermöglicht Verhalten

12. Form
"Essenz" der Struktur
wahrnehmbar, interessant
wertliefernd
konstant
12
Foto: Maik Maid

13. Struktur
notwendig für die Form
wahrnehmbar, doch weniger interessant
Kosten erzeugend
stabil
13
Foto: Ralph Aichinger

14. Verhalten
das, was in der Form passieren kann
interessant
Nutzen stiftend
variabel, flexibel
14
Foto: Benjamin Thompson

15. 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 variabel
lean
agil

16. 16
Was das System ist Was das System tut
Form
Subsysteme
Interfaces, APIs
Domänenobjekte
Use Case
Kontext
Rollen-Interfaces
Struktur
Pakete
Klassen
Rollen-Implementierungen
Algorithmen
"Form? Struktur?
Wovon redest Du eigentlich?"

17. Coach für effektive ProduktentwicklungMatthias Bohlen
17
Das Bild stammt aus dem Buch "Vorgehensmuster für Softwarearchitektur" von Stefan Toth

18. Coach für effektive ProduktentwicklungMatthias Bohlen
Zusammenarbeit
18
Architekturrunde
Saturn-
Team
Neptun-
Team
Architektur
Saturn-Backlog Neptun-Backlog
Saturn Neptun
Delegation
Delegation

19. 19
Was das System ist Was das System tut
Form
Subsysteme
Interfaces, APIs
Domänenobjekte
Use Case
Kontext
Rollen-Interfaces
Struktur
Pakete
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!

20. Foto: Casey Hussein Bisson
Transfer in die
Praxis
20

21. Einstimmung – 10’
Gruppenarbeit – 30’
Ergebnis-Präsentation – 40’
Wie geht’s weiter? – 10’
Ausklang
.
Transfer-Workshop

22. 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)?

23. 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?)

24. 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?

25. Architecture
Elevator Pitch
• Wie erklären wir Architektur unseren Kunden
oder Auftraggebern?

26. Eure Ergebnisse bitte…
.

27. Wie es weitergeht…
1-2 Workshops
pro Themenpaar,
je 4-7 Leute
Demnächst wissen wir,
wie wir Architekturarbeit tun!

28. Jetzt registrieren!
Wer kann und will
zu welchem Thema
beitragen?
Organisation &
Zusammenarbeit
Erwartungen
an Architekten
und Teams
Architektur-
arbeit im
Tagesgeschäft
.

29. Foto: Casey Hussein Bisson
Teambildung
29

30. 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

31. 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
Modellierungswissen
ABC DEF GHI JKL MNO PQR STU VWX YZA BCD EFG HIJ KLM 3er
Objektorientier
tes 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

32. Foto: Casey Hussein Bisson
Kickoff
32

33. 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

34. Domain Driven Design = fachliche Bausteine
9 Bausteine
um zu beschreiben,
woraus das System
fachlich besteht
Entity Value Object
Service Association
Business Event
Module
Factory
Repository
Aggregate

35. Abbildung auf die Technik
Technische
Architektur
ebenfalls mit
definierten
Bausteinrollen
Realisierung durch
Prototypen und
Bewertung

36. Foto: Casey Hussein Bisson
Ausbildungszeit
36

37. Schulungen
User Stories & Use
Cases
Tactical Design
Strategic Design
Grundlagen der SW-
Architektur
Agile SW-Architektur
Foto: tapetenpics

38. Von der User Story…
Story-Karte
Review submission
Reviewer 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

39. … zu den Wireframes für das UI
Foto: baldiri

40. 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>

41. Akzeptanztests dazu erstellen
Genial für das
gemeinsame
Verständnis zwischen
Business und IT
GIVEN <Situation>
WHEN <Event>
THEN <Result>

42. 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

43. Domänenmodell entwerfen
Bausteine
zusammensetzen
im UML-Tool
durchmodellieren
publizieren
Feedback einholen
Foto: Lego Photo mureut

44. Foto: Casey Hussein Bisson
Prototyping
44

45. Leitfragen helfen, die Gedanken zu lenken
Leitfrage aufstellen
Architekturansatz
dazu wählen
Prototyp dazu
erstellen
Ergebnisse bewerten
und aufschreiben
Bild: Chris Potter

46. Architekturansätze wählen
JavaEE versus
Spring Boot
Single Page versus
Multi Page UI
Microservices versus
Self Contained
Systems
etc.
Bild: Forgemind Archimedia

47. Pro und contra für jeden Architekturansatz
Bewertungskriterien
aufstellen
Ansätze bewerten
Ergebnisse publizieren
Feedback einholen
Foto: Tim Rizzo

48. Foto: Casey Hussein Bisson
Wachstums-
schmerzen
48

49. 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

50. 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

51. Foto: Casey Hussein Bisson
Pilotieren
51

52. 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

53. Unit-Testen, entwickeln, akzeptanztesten
Erste "ernsthafte"
Story
Soll vorzeigbar sein
Soll zeigen, ob
gewählte Architektur
die Qualitätsziele
tatsächlich erfüllt

54. Continous Integration and Deployment
Build-Server
Images als Ergebnisse
Demoserver, auf dem
alles jederzeit läuft

55. Foto: Casey Hussein Bisson
Reife erlangen
55

56. 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üben
Foto: Michael Havens

57. 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

58. 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

59. Zusammenfassung: Architek(ul)tur verankern
Grundlagen legen
Praxistransfer
Teambildung
Ausbildung
Prototyping
Pilotierung
Reifung
Foto: Thomas Kohler

60. Die Abkürzung zum Erfolg
Sie tun es selbst
mit mir als
"Remote Coach"
Rufen Sie mich an.

61. 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