Suche
Jenseits der emergenten Architektur

Agiles Architekturmanagement

Stefan von Brauk
©Shutterstock/Sergey Shcherbakoff

Agile Methoden haben sich in vielen Softwareentwicklungsvorhaben als sinnvolle Alternative zu anderen, komplexeren Vorgehensmodellen herausgestellt. Bei der Anwendung agiler, entwicklungszentrischer Modelle [1] stellt sich aber regelmäßig die Frage, wie das Thema „Architektur“ adäquat adressiert werden soll – kennt doch beispielsweise Scrum keine explizite Architektenrolle im Entwicklungsprozess [2].

In Softwareentwicklungsprojekten existiert Architektur zwangsläufig – sei es geplant oder ungeplant. Ein wesentliches Differenzierungskriterium ist dementsprechend, wie mit Architektur im konkreten Projekt umgegangen wird. In einem wasserfallartig geprägten Vorgehen werden beispielsweise Architekturziele, Architekturkonzepte und -strategien usw. in spezifischen Dokumenten erfasst und ausgearbeitet. Diese bilden dann den verbindlichen Rahmen für Softwaredesign, Testkonzepte usw.

Im agilen Kontext hingegen werden solche Dokumente nicht erstellt. Im Gegenteil wird – in Anlehnung an das agile Manifest [3] – die Notwendigkeit eines aktiven Architekturmanagements zum Teil durchaus negiert. (Software-)Architektur wird vielmehr als Ergebnis eines permanenten Refactorings begriffen [4]; dieser Ansatz wird als emergente Architektur bezeichnet.

Um diese beiden konträren Positionen besser zu verstehen, und zu analysieren, welche Schlussfolgerungen für agile Entwicklungsprojekte im Enterprise-Umfeld zu ziehen sind, sollen zunächst nochmals kurz Inhalt und Aufgabe des Architekturmanagements dargestellt werden.

Wozu Architekturmanagement?

Wird die Bedeutung von Architektur auf der Ebene der Softwareentwicklung betrachtet, ist die Schnittmenge zwischen Entwicklung und Architektur relativ groß: Beide Felder bemühen sich um Strukturierung des Entwicklungsgegenstandes, Reduktion von Abhängigkeiten usw. Ein Schwerpunkt dieser Tätigkeit ist somit, die Komplexität der Lösung handhabbar zu machen und typische architektonische Ziele wie Wartbarkeit, Zuverlässigkeit usw. zu erreichen.

Aber schon auf dem Gebiet der Technologie- und Produktentscheidungen ergeben sich zunehmend Differenzen: Sind solche Entscheidungen aus der Entwicklungsperspektive vor allem im Hinblick auf die Umsetzung spezifischer Features motiviert, wird der architektonische Entscheidungsraum durch weitere Parameter begrenzt, die zudem noch für die zu fällenden Entscheidungen determinierend sein können. Beispielsweise fließen Anschaffungs- und Wartungskosten, Performancekriterien, Integrations- und Betriebsführungsaspekte usw. in die Entscheidung eines Architekten ein. Demgegenüber liegen diese Kriterien oftmals nicht im Blickzentrum eines Entwicklers.

Neben der technologischen Architekturebene existieren aber noch weitere Felder, in denen Architektur wirksam ist und die ggf. Rahmenbedingung für die Ausprägung der technischen Architektur definieren können. So stellen Daten- und Applikationsarchitekturen einen nicht-technischen Bezugsrahmen dar [5], in dem ggf. für die Softwareentwicklung essenzielle Entscheidungen getroffen und dokumentiert sind. Diese Architekturen stellen oftmals zusammen mit der Businessarchitektur das vielbeschworene Business-IT-Alignment sicher. Eine weitere Domäne der Architektur ist die Umsetzung von Governance-Vorgaben. Hier muss beispielsweise sichergestellt werden, dass regulative Vorgaben innerhalb der IT adäquat berücksichtigt werden (Compliance).

Wird Architektur gemanagt, bedeutet dies, dass Architekten Planungs-, Einführungs-, Kontroll- und Steuerungsprozesse in den verschiedenen vorgestellten Feldern ausführen. Ferner impliziert dies, dass auf projektinterne oder -externe Veränderungen in der Architektur reagiert wird. Außerdem ist sicherzustellen, dass das Architekturmanagement nicht im Elfenbeinturm stattfindet, sondern Feedback von Seiten Entwicklung, Betrieb und dem Auftraggeber verarbeiten kann.

Wird die Notwendigkeit eines aktiven Architekturmanagements in (agilen oder nicht agilen) Vorgehen in Frage gestellt, kann es nützlich sein, die dargestellten Aufgaben eines Architekten in einem Value Stream Mapping mit der eigentlichen Entwicklungstätigkeit in Verbindung zu bringen, um so den Wertbeitrag der Architektur darzustellen (Abb. 1).

Abb. 1: Beispiel für eine Value Stream Map (Ausschnitt)

Architekturanforderungen in agilen Projekten

In agilen Vorgehensmodellen ist es gängige Praxis, Anforderungen als Stories zu formulieren. Es ist folglich naheliegend, zu versuchen, architektonische Anforderungen so zu formulieren, sodass sie im Product und später im Sprint Backlog verwaltet werden können. Allerdings müssen bei der Ausarbeitung von Architekturanforderungen einige Hürden berücksichtigt werden:

  1. Zwar stehen mit Epic und User Story durchaus Formate zu Verfügung, Anforderungen in unterschiedlicher Detailtiefe zu beschreiben. Allerdings stellt sich hierbei die Herausforderung, eine grobgranulare Beschreibung wie ein Epic in viele kleine Stories herunter zu brechen. Erfolgt eine solche Verfeinerung, ergibt sich im Kontext eines agilen Vorgehens aber die Herausforderung, dass diese Stories beispielweise jeweils auch testbar sein sollten (Kasten: „INVEST“). Dies ist für viele als Story formulierten, architektonischen Anforderungen nicht immer sinnvoll durchführbar. Umgekehrt sind Architekturanforderungen, die als Epic verfasst sind, nur schwer schätzbar.
  2. Ebenso existieren nichtfunktionale Anforderungen, die überhaupt nicht im Sinne einer Story operationalisiert werden können (Beispiel: Wartbarkeit einer Lösung).
  3. Stories werden im agilen Vorgehen eigentlich erst dann ausgearbeitet, wenn diese zur konkreten Implementierung anstehen (Just-in-time-Elaboration). Aber wann ist dieser konkrete Zeitpunkt beispielsweise im Hinblick auf Performanceziele erreicht?

INVEST

Werden Anforderungen als Story definiert, sollten diese nach dem INVEST-Schema entwickelt werden. Demnach ist eine Story dann gut formuliert, wenn folgende Bedingungen erfüllt sind:

  • Independent: Stories sind idealerweise unabhängig voneinander.
  • Negotiable: Stories sind vom Umfang her verhandelbar.
  • Valuable: Die Umsetzung von Stories schafft Geschäftswert für den Kunden.
  • Estimable: Stories müssen schätzbar sein.
  • Size: Stories sollen eine angemessene (kleine) Granularität aufweisen.
  • Testable: Die Implementierung von Stories soll testbar sein.

Zur Unterstützung der Testbarkeit werden Stories oftmals vom Anforderungsinhaber mit Akzeptanzbedingungen ausgestattet.

Eine weitere gängige Möglichkeit, Anforderungen und Entscheidungen im agilen Anforderungsprozess zu adressieren, ist es, diese als Constraints zu formulieren, die dann Teil des Product Backlogs werden. (Weitere Artefakte, die als Constraint definiert werden können, sind beispielsweise Wireframes, UI-Guidelines, Qualitätsanforderungen usw.) Diese Constraints werden dann für die Umsetzung aller Stories als verpflichtend für die Teammitglieder angesehen. Um die adäquate Umsetzung der Constraints regelmäßig zu prüfen, werden die Constraints in die Definition of Done (DoD) aufgenommen. Jedes Mal, wenn ein Arbeitspaket „fertig“ gemeldet wird, ist somit im Rahmen der DoD-Prüfung sicherzustellen, dass die architektonischen Rahmenbedingungen eingehalten werden. Auch dieses Vorgehen macht also eine (idealerweise automatisierbare) Testbarkeit der entsprechenden Anforderungen notwendig.

Eine weitere Möglichkeit, architektonische Anforderungen zu verwalten, ist ein explizites technisches Backlog [6]. Dieses Backlog soll Anforderungen verwalten, die weder als Story noch als Constraint abgebildet werden können. Beispielsweise kann der Aufbau eines technischen Backlogs auf die Erfassung von „bad smells“ und die Beseitigung von technischen Schulden abzielen. Bei dem Konzept des technischen Backlogs ist aber zu fragen, ob einer konkreten technischen Schuld nicht ein tatsächlicher Wert entgegensteht, der es ermöglicht, eine „echte“ User Story zu formulieren. In solchen Fällen sollte geprüft werden, ob das Führen eines technischen Backlogs, das keinen konkreten Wert repräsentiert, als einer der „seven wastes“ der Softwareentwicklung [7] angesehen werden muss.

Quintessenz des Umgangs mit den architektonischen Anforderungen in agilen Projekten könnte folglich sein:

  • Architekturanforderungen werden soweit möglich in das Product oder ggf. Programm-Backlog (s. u.) aufgenommen.
  • Die Ausarbeitung architektonischer Anforderungen erfolgt in einer anderen zeitlichen Perspektive als die Ausarbeitung von funktionalen Features, d. h. es werden die nichtfunktionalen Anforderungen sowie die funktionalen Anforderungen von zahlreichen Iterationen im Voraus analysiert. Entsprechend kann es notwendig sein, architektonische Entscheidungen zeitlich deutlich vor der Implementierung der zugehörigen Features zu treffen.
  • Die Ausarbeitung architektonischer Anforderungen kann iterativ erfolgen. Diese Iterationen sind i. d. R. nicht mit den Iterationen des Entwicklungsteams synchronisiert.
  • Soweit möglich werden nichtfunktionale Anforderungen als prüfbare Constraints formuliert und die Einhaltung der Constraints in die DoD aufgenommen.

    Aufmacherbild: Kremlin Red Square at sunset von Shutterstock / Urheberrecht: Sergey Shcherbakoff

[ header = Organisatorische Muster agilen Architekturmanagements ]

Organisatorische Muster agilen Architekturmanagements

Nicht nur der oben skizzierte Umgang mit der Erarbeitung und dem Management von Architekturanforderungen wirft die Frage auf, wie Architektur in agilen Projekten organisatorisch adressiert wird. In der Praxis können unterschiedliche Lösungsansätze beobachtet werden, die im Folgenden als idealisierte Muster vorgestellt werden.

Das „klassische“, aus dem eXtreme Programming [4] stammende Vorgehen beruht darauf, zu Beginn eines Vorhabens eine begrenzte Menge Anforderungen zu analysieren und zu implementieren und danach sukzessive weitere Features zu implementieren. Dies erfolgt unter intensivem Einsatz von Refactorings, sodass das interne Design der Software einer beständigen Anpassung und Verbesserung unterliegt (emergente Architektur). Architektur ist in dieser Sichtweise die Menge von Designentscheidungen des Teams. Der Ansatz geht konsequenterweise damit einher, dass es eine explizite Architektenrolle im Entwicklungsprozess nicht gibt.

Der Charme des Ansatzes ist sicherlich in seinem sehr schlanken und teamorientierten Ansatz begründet. Architektonische Ideen können ggf. als Proof of Concept bzw. Spike geprüft werden. Allerdings bringt das Vorgehen im Enterprise-Umfeld einige Nachteile mit sich:

  • Ein Skalieren der Methode über mehrere Entwicklungsteams hinweg ist nicht ohne Weiteres möglich.
  • Der Zeithorizont, auf dem Architekturentscheidungen beruhen, ist auf wenige Iterationszyklen begrenzt.
  • Der Scope von Architekturentscheidungen geht nicht über das Produkt hinaus. Rahmenbedingungen aus den Bereichen Programm- und Portfoliomanagement können i. d. R. prozessual gar nicht berücksichtigt werden.
  • Die Einbettung des Teams in einen größeren IT-Kontext findet mangels geeigneter Schnittstellen nicht statt. Themen aus dem Bereichen IT-Governance usw. werden nicht berücksichtigt. Ein aktives Architekturmanagement findet nicht statt.

Von den skizzierten Nachteilen kann zumindest die Frage der Architekturhomogenisierung mit gebräuchlichen agilen Methoden adressiert werden. Ein Scrum of Scrums (Abb. 2) bietet die Möglichkeit, dass regelmäßig Mitglieder verschiedener Teams sich in Bezug auf spezifische Themen wie beispielsweise Architekturentscheidungen koordinieren.

Abb. 2: Scrum of Scrums

Das Vorgehen besticht durch seinen selbstorganisatorischen Ansatz. Allerdings sind mit ihm auch einige Risiken verbunden, die zusätzlich in Kauf genommen werden müssen:

  • Der Aufwand und Zeitbedarf, eine konsensuale Entscheidung über mehrere Teams hinweg in einem sensiblen Thema wie Softwarearchitektur herzustellen, darf auf keinen Fall unterschätzt werden. Dies gilt umso mehr in cross-funktionalen Teams, in denen verschiedene Technologien genutzt werden.
  • Da die Teams ggf. vor dem Hintergrund unterschiedlicher Backlogs Entscheidungen treffen sollen, fehlt im konkreten Fall oft das Verständnis von architektonischen Bedürfnissen anderer Teams.
  • Die Verbindlichkeit der erreichten Vereinbarungen kann durch die Teams jederzeit wieder infrage gestellt werden, und die gemeinsam getroffenen Entscheidungen sind im Extremfall nicht durchsetzbar.

Um die bisher vorgestellten Fragestellungen und Probleme zu adressieren, ist eine naheliegende Modifikation des Vorgehens, eine explizite Architektenrolle innerhalb des Teams vorzusehen. Dem Vorteil, eine eindeutige Zuständigkeit herzustellen, stehen aber viele Nachteile gegenüber. So führt die eingeführte Arbeitsteilung innerhalb des Teams zwangsläufig zu Spannungen. Auch sind der analytische, der fachliche und der zeitliche Horizont des Architekten weiterhin begrenzt und sein zeitlicher Handlungsraum ist der jeweilige Sprint.

Demgegenüber kann eine Positionierung einer expliziten Architektenrolle außerhalb des Teams – z. B. in Analogie zum Product Owner – zu folgenden Vorteilen führen (Abb. 3):

  • Der Architekt arbeitet nicht im Kontext des Sprint Backlogs, sondern auf dem Product Backlog, entkoppelt vom Team-Sprint. Der Architekt kann damit seine Perspektive wesentlich weiter fassen.
  • Architekturvorgaben können als Stories oder Constraints in das Product Backlog übergeben und gemäß ihrer Priorisierung in das Sprint Backlog überführt werden.
  • Eine Rückkopplung zwischen dem Team und dem Architekten kann durch Reviews, z. B. im Rahmen der Sprint Reviews (fachliches Feedback) oder der Retrospektive (prozedurales Feedback) erfolgen.
  • Innerhalb des Sprints steht der Architekt dem Team für solche Rückfragen zu Verfügung, die die technischen und nichtfunktionalen Anforderungen betreffen.

Abb. 3: Architekt als explizite Rolle außerhalb des Teams

In dieser Perspektive würde der Product Owner (soweit er nicht die Rolle des Architekten selbst einnehmen kann) die fachlichen Anforderungen repräsentieren, wohingegen der Architekt die technischen und nichtfunktionalen Anforderungen vertritt. Natürlich ist auch dieser Ansatz mit Nachteilen bzw. Risiken verbunden:

  • Ein Konflikt zwischen dem Team und dem Architekten ist zumindest auf der Ebene der Softwarearchitektur weiterhin möglich.
  • Eine teamübergreifende Synchronisierung ist nur dann gegeben, wenn die Architektenrolle jeweils von der gleichen Person eingenommen wird.

Zumindest der letzte Punkt lässt sich im Kontext mehrerer Teams und ggf. mehrerer Produkte adäquat adressieren, indem teamübergreifende Koordinierungsbedürfnisse wie beispielsweise teamübergreifende Qualitätsstandards, einheitliche User Experience, Architektur usw. in einem Produkt-Management-Team zusammengefasst werden (Abb. 4). Die von diesen Rollen ausgearbeiteten Anforderungen werden als Stories und Constraints in ein Programm-Backlog aufgenommen und dann im Rahmen der Sprint Plannings in die Sprint Backlogs der verschiedenen Teams überführt [8].

Abb. 4: Verankerung des Architekten im Programmmanagement

In sehr großen Softwareentwicklungsvorhaben kann dieser Ansatz nochmals vorangetrieben werden, indem explizite Teams gebildet werden, die dann iterativ ein „architectural runway“ erarbeiten und die Tragfähigkeit des architektonischen Ansatzes anhand ausgewählter Epics nachweisen [9].

Fazit

Nur selten ist die konkrete Situation, in der Software entwickelt wird, von so geringer Komplexität, dass der Traum von der emergenten Architektur tatsächlich umgesetzt werden kann – beispielsweise ist ein solches Vorgehen in Open-Source-Projekten durchaus zielführend. Demgegenüber sind in kommerziellen Entwicklungsprojekten eine große Anzahl von nichtfunktionalen Anforderungen, technischen und kaufmännischen Rahmenbedingungen zu berücksichtigen, die ein aktives Architekturmanagement fast zwingend erforderlich machen.

Wie gezeigt existiert auch in der Problemdomäne „Architekturmanagement“ kein Silver Bullet, das die skizzierten Herausforderungen grundsätzlich löst. Im Gegenteil ist als Vorteil der agilen Vorgehensmodelle festzuhalten, dass ein Architekturmanagement implementiert werden kann, das optimal auf den jeweiligen konkreten Kontext abgestimmt ist, skalierbar ist und gleichzeitig ermöglicht, wesentliche Vorteile agiler Methoden zu erhalten. Auch lassen sich Feedback-Schleifen wesentlich besser in agilen Vorgehensweisen als in Wasserfallmodellen implementieren. Zudem bieten agile Vorgehen die Möglichkeit, den eigenen Architekturmanagementprozess zu entschlacken und nicht-wertschöpfende Tätigkeiten zu eliminieren.

Geschrieben von
Stefan von Brauk
Stefan von Brauk
Dr. Stefan von Brauk ist Management Consultant und Team Manager bei Cassini Consulting und berät u. a. Blue Chips in den Bereichen IT- und Architekturmanagement sowie Methoden der Softwareentwicklung.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.