Wenn alle jetzt Architektur machen, was machen dann die Architekt*innen?

Agilität, ganze Servicelandschaften und technologische Vielfalt machen gute Softwarearchitektur wichtiger denn je. Gleichzeitig kann die heute erforderliche Breite und Tiefe der Themen selbst die beste Architektin leicht an ihre Grenzen bringen.

Silas teilt in diesem Talk seine Erfahrungen, wie sich dieser scheinbare Widerspruch durch eine Trennung der Architektenrolle von ihrer Besetzung lösen lässt: Die vornehmste Aufgabe von Architekten in agilen Projekten besteht in seinen Augen darin, Rahmenbedingungen dahingehend zu gestalten, dass jede(r) im Team Architektur verantworten kann und will und alle am selben Strang ziehen. Um dieses Ziel zu erreichen, ist ein bunter Strauß an Maßnahmen, angefangen bei einem gemeinsamen Zielbild, über eine gesunde Teamkultur, bis hin zu Praktiken der Wissensvermittlung und der Ausgestaltung evolutionärer Architekturen erforderlich.

Transcript

1. Wenn jetzt alle Architektur machen … … was machen dann die Architekt*innen? XP Days 2018, Hamburg @SilasG silas.graffy@maibornwolff.de
2. Über mich Silas Graffy @SilasG silas.graffy@maibornwolff.de Principal IT Architekt bei MaibornWolff
3. Über mich Silas Graffy @SilasG silas.graffy@maibornwolff.de Principal IT Architekt bei MaibornWolff
4. Architektur Was ist das eigentlich?
5. Architektur Was ist das eigentlich? ISO/IEC 42010: “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.“ „Important and hard to change decisions“ Ralph Johnson: Soziales Konstrukt!
6. Rolle der Architektin Ok, aber was mache ich dann statt entscheiden?
7. Rolle der Architektin Ok, aber was mache ich dann statt entscheiden? Hilfe zur Selbsthilfe geben!
8. Teamkultur
9. Teamkultur Intrinsische Motivation
10. Teamkultur Intrinsische Motivation Angstfreie Räume
11. Teamkultur Wertschätz- ung und Feedback- Kultur Intrinsische Motivation Angstfreie Räume
12. Teamkultur Wertschätz- ung und Feedback- Kultur Intrinsische Motivation Vertrauen Angstfreie Räume
13. mir bekannt mir unbekannt anderen bekannt anderen unbekannt öffentlich blinder Fleck Geheimnis Feedback Sich öffnen, etwas preisgeben
14. Gemeinsame Ziele
15. Gemeinsame Ziele
16. Gemeinsame Ziele
17. Collective Code Ownership Code Architektur Projekt- management Tests und QA Support, Schulungen, Endanwender- doku Betrieb, DevOps Wirtschaft- liches wie z. B. Erstellen von Angeboten Projekterfolg not only Requirements Engineering
18. 1-on-1s
19. 1-on-1s !! Erklären?
20. 1-on-1s ?? Nicht dozieren, Fragen!
21. 1-on-1s :-) Nicht dozieren, Fragen! Ermutigen! Entscheidungen Wissens- vermittlung
22. 1-on-1s :-) Nicht dozieren, Fragen! Ermutigen! Entscheidungen Wissens- vermittlung 1. Seid da. 2. Hört zu. 3. Stellt Fragen! Gibt es etwas, das ich für dich tun kann?
23. Praktische Umsetzung Aber wie mache ich das konkret?
24. Praktiken Pair & Mob Programm- ing • Auch cross-funktional • Achtung: Für angstfreie Räume sorgen, wertschätzend feedbacken Tech Sessions • Gemeinsam wichtige (Architektur-) Entscheidungen treffen • Konsens anstreben • Entscheidungen mittragen TDD • Inside out vs. Outside in • Ping Pong • Refactoring stärkt Architekturverständnis • Architektur-Tests
25. Architekturarbeit in agilen Projekten ?? M VP! Principle of Last Responsible Moment KISS YAGNI NFAs und Qualitätsziele als Szenarien beschreiben “As a Developer …” is not a User Story!
26. Software ändert sich unter Umwelt- einflüssen Agiles Architekturverständnis Ziel: - nicht die perfekte Architektur - sondern schaffen eines Rahmens für die Evolution von Teams und Systemen während wir lernen Bei Kontakt mit der Realität/den Usern
27. Fazit Auf einer Seite, bitte!
28. Wenn jetzt alle Architektur machen … … was machen dann die Architekt*innen? Sich selbst ersetzbar! “This leads to the satisfying rule of thumb that an architect’s value is inversely proportional to the number of decisions he or she makes.” “Great software comes from great people.”
29. Vielen Dank für die Aufmerksamkeit! Fragen? Anregungen? Widerspruch? Her damit :-) PS: Kolleg*innen gesucht in München, Augsburg, Berlin und Frankfurt 30 Mio 410 Mitarbeiter*innen 9. Jahr 23 Nationen 300 Wochen München, Augsburg, Berlin, Frankfurt + Hamburg! @SilasG silas.graffy@maibornwolff.de
30. Literatur und Quellen § Brian Fitzpatrick, Ben Collins-Sussman: Debugging Teams (2015, O'Reilly) § Sam Newman: Building Microservices (2015, O'Reilly) § Patrick Lencioni: The Five Disfunctions of a Team (2002, John Wiley & Sons) § Neal Ford, Rebecca Parsons: Microservices as an Evolutionary Architecture (2016, online) § Martin Fowler: Who Needs an Architect? (2003, online) § Ganz viel, was ich hier sicher vergessen habe :-( § Bildquellen: Wikimedia Commons, MaibornWolff