Stefan Toth

Befehl von unten: Softwarearchitektur für dynamische Projekte

[…] „Ob man diese Entwickler schließlich Architekten nennt oder nicht, bleibt dem Projekt überlassen und sollte für die tatsächliche Arbeit wenig Auswirkungen haben.“

[…]

„Generell ist die Diskussion um einen Architekten als Rolle aber überbewertet“

Ich, Objektspektrum, 2009

Berater und Trainer bei oose in Hamburg

seit 06/2008

Artikel

Vorträge

Dies und das

Stefan.Toth@oose.de

u.a. in Java Magazin, ObjektSpektrum, BT-Magazin, dotnetpro, iX, HMD u.a. auf Jax, W-Jax, Seacon, OOP, SET@Jazoon, Eclipse.jar iSAQB Board Mitglied TOGAF 9 Certified (Level 2/2) AOGEA Mitglied

st_toth

Stefan Toth

Agenda

Die klassische Architektenrolle Anforderungen an die Person

Problemverschärfung Entwicklungen und Trends, die es schwerer machen

Konkrete Modelle Alternativen zum klassischen Architekten

Ausblick Rollenwahl, Praktiken und Zusammenfassung

definiert werden…

• Eigenschaften von Architekten

• Wissen das Architekten brauchen

• Aufgaben die Architekten wahrnehmen

Softwarearchitekten definiert

Eigenschaften und Wissen

und dann kommen die Aufgaben…

Architekturinformationen und Kontext bei einem Architekten gekapselt andere Entwickler agieren mit Scheuklappen

Es gibt jemanden der explizit für Architekturfragen verantwortlich ist Entwickler können annehmen es ist nicht ihr Problem

Alles was Entwickler machen kann die Architektur beeinflussen Entwickler haben die Macht alles kaputt zu machen

→

→

→

Nicht nur ein praktisches Problem…

Beschränkte Information (Kontext)

Kein Gewissen (jemand Anderes‘ Problem)

Macht alles kaputt zu machen

Immer eine schlechte Kombination…

Agenda

Die klassische Architektenrolle Anforderungen an die Person

Problemverschärfung Entwicklungen und Trends, die es schwerer machen

Konkrete Modelle Alternativen zum klassischen Architekten

Ausblick Rollenwahl, Praktiken und Zusammenfassung

Aufgabenvermischung

Analyst (RE)

Architekt Designer

Entwickler Build Engineer

Betrieb

Problem Lösung

Anforderungen: Stories/Tasks Build: Continuous Integration

Betrieb: Continuous Delivery, DevOps Architektur: ?

Mehrere: • Programmiersprachen • Persistenztechnologien • Plattformen • unterstützte Geräte • UI-Ansätze • …

Polyglotte Programmierung

Breites Technologie-Know-How…

VersionOne „State of Agile 2013“: 4048 Befragte IT-Mitarbeiter weltweit

Dynamik & Agilität

3% wollen agile Methoden künftig

NICHT einsetzen

oose „Projektmanagementstudie“: 2009 – 240 Projekte in Deutschland

Was ändert sich dadurch?

Nach eigener

Einschätzung agil

Eigenschaften: • Teams < 12 • Iterationen • >1x lauffähig • Kundenkontakt

• Erwartungen bezüglich Flexibilität • Weniger starre Projektaufstellung

evtl. Verteilung

• Höhere Transparenz • Verantwortungsstreuung

Was von „agil“ ankommt

neue Interpretation klassicher Rollenbilder… Entwickler bekommen mehr Möglichkeiten… (eigentlich cool)

Agenda

Die klassische Architektenrolle Anforderungen an die Person

Problemverschärfung Entwicklungen und Trends, die es schwerer machen

Konkrete Modelle Alternativen zum klassischen Architekten

Ausblick Rollenwahl, Praktiken und Zusammenfassung

Verteilung von

Aufgaben, (Wissen und Fähigkeiten)

Die Alternativen

Projektbeispiel 1

Größe: 26 Entwickler Teams: 3 Thema: Datenanalyse und -auswertung Art: Produktentwicklung Vorgehen: Scrum, 2-Wochen-Iterationen

Architekten-Ansatz: unterstützender Architekt (Architecture Owner) 2 „Architekten“ wechseln alle 2 Monate das Team (Springer)

Architecture Owner

Architekturentscheidungen

Werden gemeinsam getroffen:

1. Problem/Potential wird erkannt und zu AO getragen

2. Entscheidung wird vorbereitet (AO unterstützt) 3. Im Daily Scrum: Entscheidungsbedarf anmelden 4. Interessierte kommen zusammen: Vorstellung von Problem, vorgeschlagene Lösung und Alternativen. Abstimmung (Veto-Abfrage) 5. Umsetzung (AO unterstützt) 6. Jede zweite Iteration: Workshop mit Reflexion

Projektbeispiel 2

Größe: 52 Entwickler Teams: 6 Thema: Logistikanwendung Art: Projekt, Laufzeit ca. 3 Jahre Vorgehen: Iterativ, 6-Wochen-Iterationen

Architekten-Ansatz: Architekturagenten 9 Architekten mit unterschiedlichen Aufgabengebieten

Einzelne Verwantwortlichkeiten für

Architektur werden verteilt Etwa nach Schichten: UI-, Service-,

Backend-, Integrations-Architekten

Oder nach qualitativen Aspekten: Sicherheits-, Performance-, Skalierbarkeits-, Wartbarkeits-Marshalls

Architekturagenten

Architekturentscheidungen

Werden von Agenten getroffen: Teammitglieder haben ihre Rollenbezeichnungen behalten, können aber alle programmieren

Es gibt 9 „Architekten“ (Tiger-Team) mit Aufgabengebieten:

Die Agenten haben ein Auge auf „ihren“ Themenbereich

Übergreifende Jour-Fixes jede Woche (2 Stunden)

• Backend & Archivierung • Desktop-UI • Mobile

• Sicherheit • 4 Geschäftskomponenten

Projektbeispiel 3

Größe: 25 Entwickler Teams: 2-4 Teams Thema: Online-Community Art: Projekte, Laufzeiten 1-2 Jahre Vorgehen: Scrum,

Architekten-Ansatz: kein benannter Architekt Teams werden aus Entwicklerpool zusammengestellt

Teams können Anforderungen umsetzen und ausliefern (Analyse, Design, Entwicklung, Test, Deployment, …)

Es kann nicht jedes Teammitglied alles

Alle Teammitglieder entwickeln (es gibt keine „falschen“ Entwickler)

Zusätzliche Spezialfähigkeiten sind wünschenswert

Kein benannter Architekt

Architekturentscheidungen

Werden gemeinsam getroffen:

1. Architektonische Fragestellungen werden transparent gemacht: Qualitätsszenarien und technische Schulden 2. Priorisierung (Dringlichkeit) 3. „Pull“ durch Entwickler 4. Bewertungsworkshops jeden Freitag (60 Minuten)

Bei Problemen: Ad-hoc Workshops und interne Hackathons

Vermeidung des „Not-Invented-Here-Syndrom“

Breiteres Kontextwissen, garantierter Praxisbezug

Nutzung der Fähigkeiten / Übersicht der Gruppe

Vermeidung vom „Flaschenhals Architekt“

Unklare Zuständigkeiten

Hoher Kommunikationsdruck (Konsitenz und Integrität)

Kein benannter Architekt +/-

Agenda

Die klassische Architektenrolle Anforderungen an die Person

Problemverschärfung Entwicklungen und Trends, die es schwerer machen

Konkrete Modelle Alternativen zum klassischen Architekten

Ausblick Rollenwahl, Praktiken und Zusammenfassung

Die „richtige“ Rollenwahl

Informativer Arbeitsplatz Gemeinsame Entscheidung Wiederholte Reflexion Architekturcommunities

Architekturarbeit im Backlog Architekturprinzipien Ad-hoc Architekturtreffen Qualitative, automatisierte Tests

Konkrete Praktiken für Zusammenarbeit und Fokussierung

Kombinierbare Praktiken in Zeiten von Agile und Lean Autor: Stefan Toth Umfang: 240 Seiten Verlag: Carl Hanser Verlag Sprache: Deutsch ISBN-10: 3446436154 Datum: erscheint am 07. November 2013

Vorgehensmuster für Softwarearchitektur…

swamuster.de

28

29 Praktiken…

swamuster.de

Wir können (und sollten) uns nicht auf klassische Architekten verlassen

Es braucht Wege rasch zu reagieren und zu entscheiden

Softwarearchitektur wird zum Basisskill für Entwickler

Architekturpraktiken ersetzen die Rolle des

klassischen Architekten

Die Wahl des konkreten Rollenmodells hängt vom Projekt ab (Architektenfaktoren)

26

tl;dr

st@oose.de

st_toth