Das Dokument diskutiert die Rolle des Softwarearchitekten in modernen Entwicklungsorganisationen und plädiert für ein systemisches Denken, das die Selbstorganisation der Teams fördert. Es zeigt auf, wie wichtig es ist, die Zusammenarbeit und Kommunikation zwischen den verschiedenen Stakeholdern zu verbessern, um Anforderungen des Kunden effektiv umzusetzen. Zudem wird betont, dass der Architekt nicht mehr als Kontrolleur, sondern als Coach fungieren sollte, um das Team bei der Entwicklung von Software zu unterstützen.

1. Matthias Bohlen
Softwarearchitekten – die
machtlosen Anführer
Emergieren lassen statt schwitzen!

2. Neulich im Projekt
Starring:
Leiter der Abteilung ….... Ludwig Angerer
Use Case Analyst .......... Udo Carsten Ammann
Software-Architekt …...... Stefan Anders
Coach …………………… Matthias Bohlen
und viele Entwickler.

3. Ludwig Angerer: Leiter der Abteilung

4. Udo Carsten Ammann: Use Case Analyst

5. viele Entwickler…

6. Stefan Anders: Software-Architekt

7. Seinszustände eines Architekten
Phase buddhistisch
agnostisch
pragmatisch
resignierend
dogmatisch ignorant
absorbierend
nach Dr. Jürgen Lind
naiv und Alexander Knecht
Zeit

8. Der ursprüngliche Wertstrom
Use Case
Abkürzung
analysieren
SW-Architektur Komponenten SW integrieren
normaler Weg entwerfen entwickeln und testen
Architekt Komponententeams QS-
Teams
1 Wo 1 Wo 3 Wo 2 Wo
Arbeitszeit
Wartezeit
1 Wo 3 Wo 1 Wo 1 Wo 1 Wo

9. Der optimierte Wertstrom
Erstes Zweites Drittes
Feature Feature Feature
auswählen. auswählen. auswählen.
Problem Problem Problem
untersuchen. untersuchen. untersuchen.
Featurepaket
Entwerfen, Entwerfen, Entwerfen,
grob
codieren, codieren, codieren,
analysieren und
testen. testen. testen.
planen
Review Review Review
durch durch durch
Kunde. In Kunde. In Kunde. In
Use Case Analyst, Betrieb Betrieb Betrieb
Architekt nehmen. nehmen. nehmen.
Feature- Feature- Feature-
Teams Teams Teams
1 Wo 4 Wo 4 Wo 4 Wo
Arbeitszeit
Wartezeit
1 Tag 1 Tag 1 Tag 1 Tag

10. Systemisches Denken
Ein Beispiel

11. Das Bier-Spiel
Kunde Händler Großhändler
Brauerei
NACHFRAGE ERFÜLLUNG
Fahrer kommt wöchentlich
Kunden bestellen 4 Kisten pro Woche
Händler bestellt 4 Kisten pro Woche und hält 12 Kisten am Lager
Großhändler liefert Bestellung nach 4 Wochen aus
Jeder achtet nur auf sich selbst!
“The Fifth Discipline”, Peter M. Senge, Century Business, 1990

12. Bier-Spiel, die 2.
Der Spielleiter lässt die Nachfrage steigen
Jetzt sind es acht Kisten pro Woche
Was passiert jetzt?
Hinweis: Die Spieler wissen nicht, dass die
Nachfrage bei acht Kisten stabil bleiben wird!

13. Das Bier-Spiel eskaliert
Händler sehen Lager schwinden und bestellen
panisch nach
Brauerei kommt auf Touren
Großhandel kommt endlich auch auf Touren
In Woche 24 hat Händler 90 Kisten am Lager
Alle Händler hören auf zu bestellen
Die Brauerei muss Kurzarbeit anmelden.
Das Spiel endet hier. Keine Gewinner.

14. Bier, isoliert betrachtet
Zwei Möglichkeiten:
1) Die "Keine Strategie"-Strategie
Tue nichts besonderes, bestelle einfach so viel
wie Du verkaufen kannst
2) Die "Folge den Richtlinien"-Strategie
Richtlinie 1: Merke Dir, wieviel Du bestellt hast und
wieviel davon noch nicht eingetroffen ist
Richtlinie 2: Keine Panik! Das Schlimmste, was Du
tun kannst, ist zuviel zu bestellen.
Peter M. Senge behauptet, dass 1) funktioniert, 2) aber besser sei.

15. Bier, systemisch betrachtet
Neue Möglichkeiten, wenn man das Problem als
ein Problem des Systems, nicht als Problem
der einzelnen Elemente betrachtet:
1) Alle Beteiligten teilen einander wöchentlich
Daten über die Kundennachfrage mit.
2) Alle arbeiten daran, ihre Reaktionszeiten zu
verkürzen.
Alle gewinnen dabei.
"Understanding your organization as a system", Vanguard Consulting Ltd., 2001

16. Systemisches Denken
Ein System besteht aus
voneinander abhängigen
und interagierenden Teilen,
verbunden durch einen
System
Zweck.
Ein System entwickelt u.U. Eigenschaften, die
keines seiner Elemente selbst besitzt.
Emergenz.

17. Beispiele für Emergenz
• Menschenmassen bewegen sich wie Flüssigkeiten
• Menschen bilden Sprachen aus Symbolen
• Vogelschwärme weichen einem Feind aus
• Internet: Netzkunst, Smart Mobs, Online-Spiele
• Soldatentrupp bringt eine Brücke zum Einsturz
• Windhose / Tornado
• Conways Spiel des Lebens
• Langtons Ameise

18. Systemisches Denken
Was bedeutet das für eine
Entwicklungsorganisation?

19. Einstellung: Wir sind ein System!
Unser Kunde gibt uns Anforderungen / Arbeit
Wir vernetzen uns als System und arbeiten so,
dass die Anforderungen des Kunden gut und
vorhersagbar umgesetzt werden können
Wir benutzen Regeln und Feedback, um uns
weiterzuentwickeln
Wir maximieren gemeinsam den Fluss, der
Anforderungen in ausführbare Software
verwandelt.

20. Das Projekt als System
Das Projekt ist ein hoch vernetztes, wissensverarbeitendes
System mit mehreren Feedbackschleifen
Es zeigt selbstorganisierendes, intelligentes Schwarmverhalten,
das über die Intelligenz des Einzelnen hinausgeht.
Grafik: David Anderson, "Kanban"

21. Selbstorganisation
Wie kommen wir dahin?

22. Es beginnt bei der Führung…
Kommandieren / Systemisch denken
Kontrollieren
von oben nach unten Perspektive von außen nach innen
funktionale Arbeitsverteilung Nachfrage, Wert, Fluss
Spezialisierung
getrennt von der Arbeit Entscheidungen integriert in die Arbeit
Kosten, Aktivität, Messgrößen orientiert an Zweck,
Standards, Produktivität Fähigkeit, Variation
extrinsisch Motivation intrinsisch
Budget managen Führungsethik auf das System
Leute managen einwirken
vertragsorientiert Einstellung zum Worauf kommt es an?
Kunden
"Understanding your organization as a system", Vanguard Consulting Ltd., 2001

23. Der Zyklus der Selbstorganisation
Regelverletzung Feedback
Starte hier! Regel Diskurs
Verhaltensänderung

24. Architekt gibt einfache Regeln
Beispiel:
Die S.O.L.I.D. Prinzipen für gutes Design
S ingle Responsibility Principle (SRP)
Open/Closed Principle (OCP)
L iskov Substitution Principle (LSP)
I nterface Segregation Principle (ISP)
D ependency Inversion Principle (DIP)
Robert "Uncle Bob" Martin:
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

25. Teams organisieren sich selbst
Team 1 baut neues Feature ein
Team 2 bemerkt, dass SRP verletzt ist
Team 2 gibt Feedback an Team 1
Team 1 diskutiert mit Team 2 darüber
Team 1 verändert sein Verhalten
Team 2 schärft die Architekturdoku, weil die
Verantwortlichkeit der Komponente nicht klar
genug beschrieben war

26. Architekt publiziert Informationen
Architekt erhebt Daten über
… Komponentenname und -verantwortlichkeit
… Abhängigkeiten
… Testabdeckung
… Komponentengröße und Komplexität
… Zahl der Schnittstellen
… usw.
Er bewertet und veröffentlicht diese Daten regelmäßig.

27. Teams publizieren Architektur
Teams erzeugen oder verändern Komponenten
und dokumentieren das in der SW-Architektur
Teams treffen sich wöchentlich zur
Architekturabstimmung
Der Architektur-Junkie in jedem Team stellt sich
vor eine Webcam und präsentiert die neuesten
Komponenten-Änderungen
Der Architekt filmt diese Präsentationen und stellt
sie ins Wikiweb des Projektes

28. Architekt gibt weitere Regeln
Beispiel: QUASAR als Architekturstil
Es gibt vier Komponenten-Arten:
Repräsentation, Anwendungsfachlichkeit,
Technologie und Neutrale Basiskomponenten
Architekt coacht, wie welche Komponenten-Art zu
verwenden ist und welche Art von welcher
anderen Art abhängig sein darf.
Teams wenden das auf eigene Komponenten an.

29. Architekt verändert seine Rolle
Architekt ist jetzt nicht mehr der…
schwitzende Nachdokumentierer
dogmatische Prinzipienreiter
Polizist, der die Entwickler kontrolliert
Sondern er wird zum…
Coach, der Management und Entwickler berät
"Mann mit dem Ölkännchen", der die Reibung
zwischen den Teams beseitigt
Förderer der ganzen Entwicklungsorganisation

30. Zusammenfassung
Architektur allein zu machen ist mühevoll und
schmerzhaft
Lassen Sie es den Schwarm machen
Denken Sie systemisch
Starten und fördern Sie den Zyklus der
Selbstorganisation
Nehmen Sie sich einen erfahrenen Coach für den
Anfang

31. Fragen?
Gerne jetzt…
…oder später:
Matthias Bohlen
mbohlen@mbohlen.de
http://www.mbohlen.de/
+49 170 772 8545

32. Literatur und Links
Matthias Bohlen: „Emergente Architektur: Der machtlose
Architekt“, OBJEKTspektrum Nr. 3, Mai/Juni 2010
Robert C. Martin: „Principles of object oriented design“
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Wikipedia: „Emergenz“ – http://de.wikipedia.org/wiki/Emergenz
Mike Rother, John Shook: „Learning to See – Value-stream
mapping to create value and eliminate muda“. Lean Enterprise
Institute, 1999.
Mary und Tom Poppendieck: „Lean Software Development“,
Addison Wesley 2003.
Fritz B. Simon: „Einführung in die systemische
Organisationstheorie“. Carl-Auer Compact, 2007.
Fritz B. Simon: „Einführung in Systemtheorie und
Konstruktivismus“, Carl-Auer Compact, 2008.