Softwarearchitektur erschaffen Sie am besten gemeinsam, nicht nur durch einen dedizierten Architekten. Das trägt zur Agilität des gesamten Vorhabens bei. (Sie erinnern sich an das agile Manifest: „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“).

Von Scrum lernen

 width=

Genau so kann man es auch für das Thema Softwarearchitektur machen. Mitglieder der einzelnen Produktentwicklungsteams senden je eine Person in die Architekturrunde (bestehend aus Benutzern, Kunden, Domänenexperten, Businessleuten, Entwicklern). Dort sprechen die Leute über die Aspekte des Entwurfs, die mehr als ein Team auf einmal angehen, insbesondere über diese Dinge:

  • Schnittstellen zwischen den Teams und zwischen Teilen der Software
  • grundsätzliche Entwurfsentscheidungen (z.B. über Querschnittsaspekte, Framework-Einsatz, Komponentenschnitt, …)
  • Entwurfs-Stil und Entwurfs-Regeln (z.B. SRP, OCP, LSP, …)
  • Qualitätsanforderungen, die von allen Teams einzuhalten sind (z.B. Performance, Security, Wartbarkeit, …)

Team-Setup

Die Teamaufstellung sieht so aus wie in der Abbildung oben: Gezeichnet sind zwei Entwicklungsteams, die jeweils ein Teilsystem entwickeln (hier Saturn und Neptun genannt). Die beiden Teams stützen sich dabei auf eine gemeinsame Architektur, die sie z.B. in einem Wikiweb beschreiben (Mitte des Bildes). Die dicken durchgezogenen Pfeile bedeuten Informationsflüsse, die dünnen gestrichelten Pfeile bedeuten konzeptionelle Abhängigkeit der Pakete von der Gesamtarchitektur, die dicken schraffierten Pfeile bedeuten eine Entsendung von Personen.

Jedes Team hat sein eigenes Backlog, in das Qualitätsanforderungen, die in der Architekturrunde entdeckt oder besprochen wurden, eingefügt werden, damit sie in den Entwicklungsprozess einfließen können. Bei der nächsten Kurzfristplanung (z.B. in der Sprintplanung oder im Kanban-Replenishment-Meeting) kommen die Qualitätsanforderungen mit in die Auswahl.

Schlank und trotzdem hinreichend

Mit solch einem Vorgehen bereiten Sie eine Umgebung vor, in der höchstens so viel Architektur erzeugt wird wie die Teams zur Klärung und Beschleunigung ihrer Arbeit benötigen. Sie bereiten aber auch vor, dass mindestens so viel Architektur erzeugt wird wie für eine langfristig tragfähige Lösung nötig ist. Wie Sie diesen Spagat hinbekommen? Darüber schreibe ich mehr in einem weiteren Blog-Eintrag.

Kommen Sie auch zur Jax on Tour, da gebe ich Vorträge dazu.