Software Architektur und Design als agiles Team! Teil 1

10.11.2017

Warum Architekten und Designer auch ein agiles Team bilden sollten!   Dieser Beitrag beschäftigt sich mit den Möglichkeiten und Auswirkungen eines Architektur- und Designteams das ebenfalls als Scrum Team implementiert ist. Folgend werde ich einige Argumente beleuchten die dafür sprechen das neben Vollzeitarchitekten und Designer auch Entwickler aus den Entwicklungs-Teams in einem Agile Architecture Team vereint werden sollten.

Ich persönlich habe Erfahrungen in einem Architekturgremium gemacht, in dem auch jeweils ein Entwickler eines jeden Scrum-Teams als sogenannter "Blauhelm" mitwirkte. Das ergab die Möglichkeit erstens die entstehenden Fragen oder Vorschlägen aus den Teams in das Architekturgremium zu bringen und zu behandeln, andererseits konnten so teamübergreifende Architekturmassnahmen zurück in die Teams kommuniziert und adressiert werden.

Wenn so ein Gremium ebenfalls als Scrum Team realisiert wird, könnten Architekten, Designer und Entwickler iterativ auf Änderungen in den Anforderungen an die Architektur reagieren und hätten auch bei jeder Iteration ein Feedback über ihre Entscheidungen und getroffenen Massnahmen. Dies ergebe auch ein schnelleres Feedback über die zu erwartende Aufwände und könnte daher auch der Priorisierung von architektonischen Massnahmen dienen. Ebenfalls würde dies ein Abschätzen von Risiken von Eingriffen in die Softwarearchitektur erleichtern, da die Einschätzung nicht auf Annahmen weniger Architekten, sondern aus dem Feedback aller Scrum-Teams resultieren würde. Das Prinzip das eine Schätzung von allen Teammitgliedern gemacht werden soll, sollte auch für Entscheidungen und Schätzungen bezüglich der Softwarearchitektur gelten.

Ebenfalls gibt diese Variante engagierten Entwicklern (da es eine zusätzliche Aufgabe zur täglichen Arbeit als Entwickler bedeutet) die Möglichkeit sich für die gesamte Architektur mit verantwortlich zu fühlen. Eine "die einen haben es entworfen, die anderen bauen es" Vorgehensweise entspricht nicht mehr dem agilen Vorgehen in der Softwareentwicklung und kann so verhindert werden. Man kann von einer Demokratisierung der Software-Architektur sprechen.

Architecture Team = Agile Team!

Ein weiterer positiver Faktor wäre die Transparenz bezüglich Anforderungen an die Architekten und Designer. Aufgaben würden in Story's erfasst und mit dem gleichen Vorgehen wie in den Entwicklungsteams abgearbeitet werden. Damit würden auch in Bezug auf Architektur und Design alle Scrum-Artefakte wie Planning, Review, Retro, Burn-Down, Velocity etc, dem Projekt zur Verfügung stehen.

Qualitätsindikatoren und Metriken könnten realitätsnah mit Entwicklern zusammen erstellt aber auch laufend hinterfragt werden. Wer kennt nicht die einmalig erstellten Sonar-Kriterien, die sich im Laufe des Projektfortschritts immer weiter von den tatsächlichen qualitativen Anforderungen an die Software entfernen und somit den Entwicklern nicht als wichtige Unterstützung dienen, sondern als lästige Hindernisse bei der täglichen Arbeit wahrgenommen werden?

Immer öfters werden verteilte Architektursysteme gewählt aus denen sich durch den Entwurf bedingt mehrere kleinere Domain Driven Teams ergeben. Dies führt oft zu unkontrollierten Auswüchsen in den Implementierungen, da es schwer bis unmöglich ist hier die Vorgaben der Architektur mit starr dokumentierten Entwicklerrichtlinien oder Seitenlangen Coding-Rules die auf irgendwelchen Wiki-Seiten verloren ihr Dasein fristen zu gewährleisten.

Gemeinsam könnten agile Entwicklungs- Prinzipien und Methoden gewählt und täglich reflektiert werden um so die Codearchitektur innerhalb von notwendigen Leitplanken lebendig zu gestalten. Die Illusion ein einmalig erstellter Entwurf müsse oder könne gar 1:1 umgesetzt und erhalten bleiben sollte der Vergangenheit angehören, jedoch muss eine agile Architektur soweit gezähmt werden, dass sie den verschiedenen Kriterien eines Projekts entsprechen kann. Dies benötigt wie auch schon von der Entwicklung bekannt ist eine iterative Prüfung des erreichten Zustands sowie die Möglichkeit die Ziele der Realität anpassen zu können.

Jedes CheckIn, jede geänderte Konfiguration und jede Anpassung eines Datenmodells sollte einer Architekturvision Folge leisten und daher sollte sich jeder Entwickler bei der täglichen Arbeit der Architektur gegenüber genauso verantwortlich fühlen wie es der Architekt schon in der Entwurfsphase tut. Dies kann aber nur realisiert werden, wenn diese auf unterschiedliche Weise wahrgenommenen Disziplinen in Teams vereint werden die ein Rollendenken diesbezüglich hinter sich lassen und das Produkt und die dazu notwendigen Aufgaben in den Vordergrund stellen.

Dieser Schritt wäre notwendig um die Architekten und Designer genauso in das "agile Boot" zu holen, wie es auch schon von BA's und QA's, ja mittlerweile auch von Operations gefordert wird.

Architekt = Entwickler = Architekt?

Softwarearchitekten und Designer sollten die Nähe zur iterativen Entwicklung einer Software bewahren und nicht als abstrahierte Leader-Guilde wahrgenommen werden. Sie sollten sich jederzeit über den aktuellen Stand der Architektur aber auch der Implementierung im Klaren sein und jede gewollte oder auch ungewollte Abweichung einer Architekturvision unmittelbar wahrnehmen können.

Oft ist es so das sich Architekten sehr weit von der täglichen Arbeit des Entwicklers entfernen und so kaum Einfluss mehr auf die Ausgestaltung der Architektur haben. Natürlich können wir hier nicht von "dem" Architekt generell sprechen. Dies ist natürlich davon abhängig auf welcher Ebene der Architektur sich der Architekt bewegt. Es kann von einem Solution Architekt nicht erwartet werden sich täglich mit Enwicklungsmethoden und deren Anwendung zu beschäftigen. Aber es sollte trotzdem auch auf dieser Ebene ein Mittel zur Kommunikation und Interaktion vorhanden sein.  Auch fehlen bei Entscheidungen das Verständnis für die Anliegen der Entwickler. Viel zu oft wird dem Entwicklerhandwerk und der richtigen Wahl der Entwicklungsprinzipien nicht genügend Beachtung geschenkt. Wichtige Prinzipien wie SRP: The Single-Responsibility Principle, OCP: The Open-Closed Principle, LSP: The Liskov Substitution Principle, DIP: The Dependency-Inversion Principle, ISP: The Interface-Segregation Principle usw. werden kaum in den agilen Entwicklungsteams angewandt, obwohl sie die Grundlage einer agilen Software-Architektur bilden. Die Auswahl der richtigen Entwicklungsmethoden passend zu gewählten Architektur ist aber ein wichtiger Aspekt und sollte von Softwarearchitekten aktiv unterstützt werden. Einige Architekten würden sich am liebsten nur noch auf der Solution-Ebene verwirklichen ohne jedoch zu berücksichtigen das die tatsächliche Implementierung das erforderliche Fundament für eine erfolgreiche Enterprise-Architektur darstellt. Daher wäre ein Agile Architecture Team der richtige Ort um auch mit der Entwicklung in Kontakt zu bleiben. Indem man in Agile Architecture Teams die Belange aller Architekturebenen vereint wäre man in der Lage auch auf allen Ebenen die erforderlichen Schritte zu unternehmen. Durch das Einbeziehen von Entwickler in das Team wären alle Ebenen der Software-Entwicklung in einem Team vorhanden. Leider ist durch die Trennung von Architekten und Entwickler eine Verständnislücke vorhanden. Entwickler stehen oft nicht hinter Entscheidungen der Architekten und so bildet sich eine stille Ablehnung gegen die Architektur der Software.

Eine mögliche Aufgabenstellung für ein Agile Architecture Team könnte so aussehen:

  • die Methoden und Werkzeuge agiler Software-Architektur anzuwenden
  • Software-Architektur gemeinsam im Team zu erarbeiten und kontinuierlich weiterzuentwickeln
  • Architekturaufgaben in agile Prozesse zu integrieren und mit deren Artefakten zu verknüpfen
  • Nicht-funktionale Anforderungen definieren & prüfen
  • Entscheidungen vorbereiten & zusammen mit den Entwicklungsteams treffen
  • Ein beständiges Monitoring der aktuellen Architektur und den Fortschritt der Teams durchzuführen.
  • Strukturen & Konzepte dokumentieren (Liquid Documentation)
  • Technische Schulden identifizieren & verwalten
  • Den Teams das Wissen über agiles Softwaredesign zu vermitteln und dessen Anwendung einzuleiten und die Ergebnisse iterativ reflektieren.

Wie man sieht sind es hier einige Aufgaben die auch bei der Iteration von Entwicklungsteams anfallen. Hier sind sie aber auf einer Meta-Ebene anzuwenden die das gesamte System betreffen. Dies soll auch nicht bedeuten das diese Aufgaben von dem Architektur Team selbst ausgeführt werden müssen. Vielmehr sollten durch Prototypen und Schulungen sichergestellt werden, dass diese Aufgaben in den Entwicklungsteams gelöst werden können und sich die Teams gemeinsam in eine Richtung bewegen.

Agile Architecture Coaching:

Insgesamt entsteht das Bild einer neuen Architekturdisziplin. Einer Disziplin, die sich nicht um den einen Architekten und dessen Entwürfen dreht, sondern um agile Teams die iterativ eine gemeinsam erarbeitete Architekturvision umsetzen. Einer Disziplin die eine neue Architekten-Rolle als aktiven Coach sieht der seine Erfahrung und sein Know-How den Entwicklungs-Teams als Entscheidungshilfe zur Verfügung stellt. Er baut daher die Brücke zwischen dem Big Picture einer Anwendung auf Produkt-Ebene und den Anforderungen der täglichen Entwicklungsarbeit und sollte sich daher beiden Seiten gegenüber gleichermassen verantwortlich fühlen. Um dies zu unterstützen sollten auch Design und Architektur als agiles Team umgesetzt werden, um auch hier auf die Vorteile der agilen Methode zurückgreifen zu können.

Leider wird die Trennung der verschiedenen Architekturebenen und der Entwicklung in agilen Enterprise-Frameworks wie zum Beispiel SAFe weiterhin beibehalten. Dieses Vorgehen verhindert eine echte agile Entwicklung innerhalb eines scheinbar agilen Frameworks und sollte daher ernsthaft hinterfragt werden. Einige Dienstleistungsfirmen in der Softwarebranche bieten daher bei einer agilen Transformation auch die Möglichkeit eines Agile Architecture Coachings an. Dies ist eine nützliche Begleitmassnahme um sicherzustellen das neben dem agilen Framework und seinen prozessbezogenen Artefakten auch eine echte agile Entwicklung eingeleitet wird. Der klassische Scrum Master kann hier nur schwer diese Aufgabe übernehmen da es ihm oft an den notwendigen technischen Know-How fehlt. Dies würde auch nicht seinem klassischen Aufgabengebiet entsprechen. Der Architecture Coach hingegen kann hier aktuelle Entwicklungsmethoden in die Teams transportieren und dabei helfen diese in der täglichen Arbeit anzuwenden. Dies wird immer in Abstimmung mit den im Architectur Team ausgearbeiteten Konzepten vollzogen. Dadurch kann bewirkt werden das es sich bei der agilen Transformation nicht nur um eine organisatorische Scheintransformation handelt, bei der eine leere agile Hülle über ein starres, schwerfälliges Entwicklungsverhalten gestülpt wird bei der die Software schon nach kurzer Zeit dieselben Symptome wie in der klassischen Vorgehensweise aufweist:

  • Stark ansteigende Aufwandskurve.
  • Keine stabilen Schätzungen möglich.
  • Fehleranfällige und schwer wartbare Codebase.
  • Keine Lesbarkeit
  • Fragile Abhängigkeiten zwischen den einzelnen Modulen und Komponenten.
  • Implementierung spiegelt nicht den Entwurf.

Diese Anforderungen sollten aber von einem Agile Architecture Team auf die gleiche Weise iterativ geprüft werden wie es bei den Business-Anforderungen in Scrum Teams der Fall ist. Sollte man diese Symptome feststellen kann durch aktives Architektur und Design Coaching in den betroffenen Teams gegengesteuert werden.

Eine mögliche Konstellation eines Agile Architecture Teams:

  • Solution Architekt  = PO (er stellt die Anforderungen an das Team ohne jedoch alleinig über die Art der Umsetzung entscheiden zu können)
  • System Architekt
  • Software (Applikations) Architekt
  • Business Architekt
  • Quality Manager
  • Architektur Coach -  (Diese Rolle kann ideralerweise von einem der Softwarearchitekten oder aber von einem Entwickler übernommen werden)
  • Scrum Master für das Agile Architecture Team

Wie man sieht handelt es sich um ein echtes Cross Functional Team. Auch wird hier ein anderer Schnitt gemacht als dies zum Beispiel in SAFe der Fall ist. Hier sollen Lösungsvorschläge aufgrund des gesammelten Wissens verschiedener Disziplinen und Entscheidungsebenen ausgearbeitet werden. Die hier vorgestellte Konstellation ist natürlich nicht bindent und stellt nur eine Möglichkeit dar die möglichen Rollen dieses Teams zu erörtern. Sie muss natürlich den jeweiligen betrieblichen Anforderungen und dem Charakter eines Projekts angepasst werden. Abhängig von der Projektstruktur kann und soll auch ein Enterprise Architekt ein Mitglied eines Agile Architecture Teams sein. Da dieser aber meist auf einer Ebene mit sehr hohen Abstraktionsgrad gegenüber der tatsächlichen Produktentwicklung tätig ist, werde ich den Solution-Architekt als Beispiel eines projektverantwortlichen Architekten heranziehen. Auch ist je nach Beschaffenheit des Projekts ein Datenbank-Architekt vorhanden uns sollte daher ebenfalls in das Team integriert werden.

In regelmässigen Iterationen finden Architektur Meetings mit den Delegierten Entwicklern aus den Scrum-Teams statt. Hier findet der direkte Austausch statt, werden Probleme erhoben und bei Bedarf vom Architecture Team als Story in den Backlog genommen. Für die Entwickler sind der aktuelle Stand sowie die geplanten Ziele auf dem Architecture Board transparent ersichtlich. Eine Herrausforderung kann die Anzahl der Teilnehmer dieses Meetings sein, da ideralerweise pro Entwicklungsteam ein Entwickler an diesen Meetings vertreten sein sollte.

Aufgaben die in den Teams umgesetzt werden müssen können vom Solution Architekten in der Rolle als PO mit den PO's der Business-Teams besprochen und dementsprechend an das richtige Team adressiert werden. So werden die technischen Aufwände auch den Business Units transparent offengelegt und können so in zukünftige Schätzungen von Anforderungen miteinbezogen werden. Auch können so zeitliche Aufwände besser abgeschätzt werden um realistischere Aussagen bezüglich Termintreue machen zu können.

Im nächsten Beitrag möchte ich detaillierter auf die Zusammensetzung des Teams und auf die einzelnen Rollen eingehen und einige mögliche Szenarien für ein agiles Architektur Team beschreiben.

Ich darf zum Abschluss dieses Beitrags einen oftmals verwendeten Vergleich bemühen da er mir immer wieder als sehr passend erscheint:

«Die Architekten und Designer eines Gebäudes werden nicht nach ihren Entwürfen beurteilt, sondern nach dem tatsächlichen Gebäude das daraus entsteht.»

Markus Wagner

FollowMe