Architek(ul)tur – wie bekommen wir
Architekturarbeit in den Alltag rein?
Matthias Bohlen
http://mbohlen.de
@mbohlende
+49 ...
Warum Architek(ul)tur einführen?
Eines Tages enden alle ernsthaften
Systeme hier:
Wartungskosten steigen
Produkt hat voll ...
Woraus besteht eigentlich "Kultur"?
3©
Verhaltensweisen "So machen wir das hier".
Darstellungsformen "So beschreiben wir u...
Foto: Casey Hussein Bisson
Grundlagen legen
4
OOPSLA 1992
5
Publikum:

Mr. Beck, was ist

Softwarearchitektur?
Softwarearchitektur?

Das ist das, was Softwarearchitekte...
Extreme Programming Explained (2000)
6
"Softwarearchitektur ist in XP-Projekten genauso
wichtig wie in irgendeinem Softwar...
Coach für effektive ProduktentwicklungMatthias Bohlen
Architektur
ISO 42010: "architecture"
die fundamentalen Konzepte ode...
Die elende Bau-Metapher
8
Der 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 Softwarearchitekten
Anforderungen und Randbedingungen k...
Form versus Struktur
11
Struktur stützt Form
Form ermöglicht Verhalten
Form
"Essenz" der Struktur
wahrnehmbar, interessant
wertliefernd
konstant
12
Foto: Maik Maid
Struktur
notwendig für die Form
wahrnehmbar, doch weniger interessant
Kosten erzeugend
stabil
13
Foto: Ralph Aichinger
Verhalten
das, was in der Form passieren kann
interessant
Nutzen stiftend
variabel, flexibel
14
Foto: Benjamin Thompson
15
Form Struktur Verhalten
Essenz der Struktur Stütze der Form
was in der Form
passiert
wahrnehmbar notwendig interessant
...
16
Was das System ist Was das System tut
Form
Subsysteme
Interfaces, APIs
Domänenobjekte
Use Case
Kontext
Rollen-Interface...
Coach für effektive ProduktentwicklungMatthias Bohlen
17
Das Bild stammt aus dem Buch "Vorgehensmuster für Softwarearchite...
Coach für effektive ProduktentwicklungMatthias Bohlen
Zusammenarbeit
18
Architekturrunde
Saturn-
Team
Neptun-
Team
Archite...
19
Was das System ist Was das System tut
Form
Subsysteme
Interfaces, APIs
Domänenobjekte
Use Case
Kontext
Rollen-Interface...
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 st...
Erwartungen an
Architekten und Teams
3. Welche Erwartungen an die Architektenrolle
gibt es? (Aufgaben und Verantwortung)
4...
Architekturarbeit im
Tagesgeschäft
5. Wie sieht die Architekturarbeit als Items im
Backlog aus?
6. Wenn Architekturarbeit ...
Architecture

Elevator 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...
Foto: Casey Hussein Bisson
Teambildung
29
2 Teams während der Lernphase
Fachliche Architektur
mit Domain Driven
Design
Technische
Architektur mit
Prototyping
Achtun...
Skillmatrix liefert Ausbildungsbedarf
3 = ich kann das völlig
neu aufbauen
2 = ich kann dazu
beitragen
1 = ich kann es les...
Foto: Casey Hussein Bisson
Kickoff
32
Kickoff der Arbeiten
System aus Bausteinen
aufbauen
Nicht als Monolith,
sondern als Bauwerk
aus vielen Steinen
Vorbild: Le...
Domain Driven Design = fachliche Bausteine
9 Bausteine
um zu beschreiben,
woraus das System
fachlich besteht
Entity Value ...
Abbildung auf die Technik
Technische
Architektur
ebenfalls mit
definierten
Bausteinrollen
Realisierung durch
Prototypen un...
Foto: Casey Hussein Bisson
Ausbildungszeit
36
Schulungen
User Stories & Use
Cases
Tactical Design
Strategic Design
Grundlagen der SW-
Architektur
Agile SW-Architektur
F...
Von der User Story…
Story-Karte
Review submission
Reviewer can review a submission so
that the chairman will know how
good...
… zu den Wireframes für das UI
Foto: baldiri
Use Cases schreiben
die "rechte Seite"
macht's !
BEZEICHNER:
<DK>.<UK>
(DK = Domänenkürzel,
UK = Use Case Kürzel)
TITEL:
<...
Akzeptanztests dazu erstellen
Genial für das
gemeinsame
Verständnis zwischen
Business und IT
GIVEN <Situation>
WHEN <Event...
Abbilden auf Domain Services & Entitäten
Aus den Abläufen der
"rechten Seite"
Service-Funktionen
gewinnen
Aus den
konzepti...
Domänenmodell entwerfen
Bausteine
zusammensetzen
im UML-Tool
durchmodellieren
publizieren
Feedback einholen
Foto: Lego Pho...
Foto: Casey Hussein Bisson
Prototyping
44
Leitfragen helfen, die Gedanken zu lenken
Leitfrage aufstellen
Architekturansatz
dazu wählen
Prototyp dazu
erstellen
Ergeb...
Architekturansätze wählen
JavaEE versus

Spring Boot
Single Page versus
Multi Page UI
Microservices versus
Self Contained
...
Pro und contra für jeden Architekturansatz
Bewertungskriterien
aufstellen
Ansätze bewerten
Ergebnisse publizieren
Feedback...
Foto: Casey Hussein Bisson
Wachstums-
schmerzen
48
Domain Driven Design Technische Architektur
Bounded Context 1 Bounded Context 2
Teams neu "schneiden"
Bisherige Teams:
Fok...
Onboarding: Neue Leute kommen ins Team
Leute, welche die
Historie nicht haben
und die Architektur-
ansätze nicht (sofort)
...
Foto: Casey Hussein Bisson
Pilotieren
51
Bewertete Architekturansätze entscheiden
Entscheidungs-
workshop zum Piloten
Was haben wir schon
entschieden?
Was müssen w...
Unit-Testen, entwickeln, akzeptanztesten
Erste "ernsthafte"
Story
Soll vorzeigbar sein
Soll zeigen, ob
gewählte Architektu...
Continous Integration and Deployment
Build-Server
Images als Ergebnisse
Demoserver, auf dem
alles jederzeit läuft
Foto: Casey Hussein Bisson
Reife erlangen
55
Wenn genügend viele Stories umgesetzt sind
Erfahrungen
dokumentieren
Am besten als How-To
Publizieren
How-Tos pro Team zu
...
Organisation an Soll-Architektur anpassen
Teams: schnell, 

autark releasefähig
Warten nicht auf
einander
Optimal: Jeder
B...
Feedback-Mechanismen fest etablieren
Akzeptanztests für
Business Value und
Service-Verhalten
statische Prüfungen
im Build-...
Zusammenfassung: Architek(ul)tur verankern
Grundlagen legen
Praxistransfer
Teambildung
Ausbildung
Prototyping
Pilotierung
...
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, Vid...
Nächste SlideShare
Wird geladen in …5
×

TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rein? (The architecture gathering 2015)

461 Aufrufe

Veröffentlicht am

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/

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
461
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
81
Aktionen
Geteilt
0
Downloads
13
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

TAG2015: ArchiteKultur – wie bekommen wir Architekturarbeit in den Alltag rein? (The architecture gathering 2015)

  1. 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. 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. 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. 4. Foto: Casey Hussein Bisson Grundlagen legen 4
  5. 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. 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. 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. 8. Die elende Bau-Metapher 8 Der Architekt erklärt Der Entwickler baut Foto: Anna Oakley
  9. 9. Wenn überhaupt Bau, dann... 9 Architekten und Entwickler entwerfen Der Compiler baut
  10. 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. 11. Form versus Struktur 11 Struktur stützt Form Form ermöglicht Verhalten
  12. 12. Form "Essenz" der Struktur wahrnehmbar, interessant wertliefernd konstant 12 Foto: Maik Maid
  13. 13. Struktur notwendig für die Form wahrnehmbar, doch weniger interessant Kosten erzeugend stabil 13 Foto: Ralph Aichinger
  14. 14. Verhalten das, was in der Form passieren kann interessant Nutzen stiftend variabel, flexibel 14 Foto: Benjamin Thompson
  15. 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. 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. 17. Coach für effektive ProduktentwicklungMatthias Bohlen 17 Das Bild stammt aus dem Buch "Vorgehensmuster für Softwarearchitektur" von Stefan Toth
  18. 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. 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. 20. Foto: Casey Hussein Bisson Transfer in die Praxis 20
  21. 21. Einstimmung – 10’ Gruppenarbeit – 30’ Ergebnis-Präsentation – 40’ Wie geht’s weiter? – 10’ Ausklang . Transfer-Workshop
  22. 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. 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. 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. 25. Architecture
 Elevator Pitch • Wie erklären wir Architektur unseren Kunden oder Auftraggebern?
  26. 26. Eure Ergebnisse bitte… .
  27. 27. Wie es weitergeht… 1-2 Workshops
 pro Themenpaar, je 4-7 Leute Demnächst wissen wir,
 wie wir Architekturarbeit tun!
  28. 28. Jetzt registrieren! Wer kann und will zu welchem Thema beitragen? Organisation & Zusammenarbeit Erwartungen an Architekten und Teams Architektur- arbeit im Tagesgeschäft .
  29. 29. Foto: Casey Hussein Bisson Teambildung 29
  30. 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. 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. 32. Foto: Casey Hussein Bisson Kickoff 32
  33. 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. 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. 35. Abbildung auf die Technik Technische Architektur ebenfalls mit definierten Bausteinrollen Realisierung durch Prototypen und Bewertung
  36. 36. Foto: Casey Hussein Bisson Ausbildungszeit 36
  37. 37. Schulungen User Stories & Use Cases Tactical Design Strategic Design Grundlagen der SW- Architektur Agile SW-Architektur Foto: tapetenpics
  38. 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. 39. … zu den Wireframes für das UI Foto: baldiri
  40. 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. 41. Akzeptanztests dazu erstellen Genial für das gemeinsame Verständnis zwischen Business und IT GIVEN <Situation> WHEN <Event> THEN <Result>
  42. 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. 43. Domänenmodell entwerfen Bausteine zusammensetzen im UML-Tool durchmodellieren publizieren Feedback einholen Foto: Lego Photo mureut
  44. 44. Foto: Casey Hussein Bisson Prototyping 44
  45. 45. Leitfragen helfen, die Gedanken zu lenken Leitfrage aufstellen Architekturansatz dazu wählen Prototyp dazu erstellen Ergebnisse bewerten und aufschreiben Bild: Chris Potter
  46. 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. 47. Pro und contra für jeden Architekturansatz Bewertungskriterien aufstellen Ansätze bewerten Ergebnisse publizieren Feedback einholen Foto: Tim Rizzo
  48. 48. Foto: Casey Hussein Bisson Wachstums- schmerzen 48
  49. 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. 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. 51. Foto: Casey Hussein Bisson Pilotieren 51
  52. 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. 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. 54. Continous Integration and Deployment Build-Server Images als Ergebnisse Demoserver, auf dem alles jederzeit läuft
  55. 55. Foto: Casey Hussein Bisson Reife erlangen 55
  56. 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. 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. 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. 59. Zusammenfassung: Architek(ul)tur verankern Grundlagen legen Praxistransfer Teambildung Ausbildung Prototyping Pilotierung Reifung Foto: Thomas Kohler
  60. 60. Die Abkürzung zum Erfolg Sie tun es selbst mit mir als "Remote Coach" Rufen Sie mich an.
  61. 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

×