Stefan Rogge 14. Januar 2020

Der agile Architekt

Ein agiler Architekturansatz klingt sehr attraktiv, lässt er doch Spielraum für Innovationen und Verbesserungen im laufenden Projekt. © Adobe: goodluz / stock.adobe.com / 111087123 — © Adobe: goodluz

Die Art, wie Softwareprojekte aufgebaut sind und durchgeführt werden, hat starken Einfluss auf die Zusammenarbeit der einzelnen Projektrollen und verändert die Motivation und das Verständnis für die Gesamtlösung. Häufig wird das agile Vorgehen bei Entwicklern als Freiheit, aber auch als Möglichkeit eigenverantwortlich zu arbeiten angesehen. Nun funktioniert ein Softwareprojekt aber nicht ganz ohne Vorgaben und Rahmenbedingungen, was die Frage nach den Rollen des klassischen Projektmodells aufwirft. Welche Rolle kommt im agilen Kontext dem Softwarearchitekten zu? Gibt es diese Rolle noch oder werden Architekturentscheidungen vollständig in den Teams getroffen?

Der Artikel greift die einzelnen Fragestellungen auf und gibt Tipps, wie die Architekturarbeit in einem agilen Kontext angesiedelt werden kann und wie der Architekt in einem modern organisierten Projekt gesehen werden sollte.

Was bedeutet agil im Kontext von Softwarearchitektur?

Wie bereits in der Einleitung angesprochen, haben unterschiedliche Parteien ganz unterschiedliche Vorstellungen von Agilität im Rahmen eines Softwareentwicklungsprojekts. Für viele Entwickler bedeutet ein agiles Projekt vor allem die Zusammenarbeit im Team und die damit verbundene Freiheit mit dem Team, die Arbeitspakete selbst zu bestimmen. Viele erfahrene Softwareentwickler entwickeln allerdings mit zunehmender Projekterfahrung den Anspruch, den Aufbau und das Design eines Gesamtsystems zu unterstützen beziehungsweise aktiv beteiligt zu sein. Diese Art der Entwicklung wird in vielen Unternehmen durch ein entsprechendes Karrieremodell gefördert und gefordert. Steht nun die zunehmende Durchführung agiler Projekte der Chance für Entwickler, sich architekturell einzubringen, im Wege? Die Antwort darauf lautet Nein.

Die Architekturarbeit sollte sich an das agile Vorgehen im Projekt anpassen, also ebenfalls agil sein.

Natürlich funktioniert auch ein agiles Projekt nicht ohne Vorgaben und Rahmenbedingungen. Die Entwicklung eines tragfähigen Gesamtsystems setzt voraus, dass ein Überblick über die Anforderung an das System bewahrt und Entscheidungen dokumentiert werden, um zu vermeiden, dass sich Teams verkünsteln und es zu Wildwuchs im System kommt.

Aber wie wirken sich nun die Rahmenbedingungen eines agilen Projekts auf die Architekturarbeit aus? Grundsätzlich sollte sich die Architekturarbeit an das agile Vorgehen im Projekt anpassen, also ebenfalls agil sein. Dies bedeutet, dass sie durch Anforderungen getrieben fortentwickelt wird, ohne im Vorfeld des Projekts ein vollständiges Bild des Gesamtsystems zu erarbeiten. Dabei gilt der Leitsatz, dass der Aufwand dem Problem angemessen sein soll und sich die Architektur des Systems im Verlauf des Projekts weiterentwickeln kann.

Stefan Toth führt in seinem Buch "Vorgehensmuster für Software-Architektur" [1] den Begriff des Walking Skeleton ein, welcher zum Ziel hat, Architekturvisionen möglichst bald und schmerzfrei zu widerlegen und damit hohe Aufwände in späteren Projektphasen zu vermeiden. Ein entscheidender Vorteil agiler Entwicklungsmodelle ist, die Fähigkeiten jedes einzelnen Teammitglieds zu fördern und zu fordern, um damit das volle Potential des Teams zu nutzen. Diesen Gedanken gilt es auch in der Architekturarbeit umzusetzen.

Ein agiler Architekturansatz klingt nach dieser Beschreibung sehr attraktiv, lässt er doch Spielraum für Innovationen und Verbesserungen im laufenden Projekt, welche in Projekten nach klassischem Vorgehensmodell so nicht einfach umsetzbar wären. Aber dieser Ansatz bringt neben Vorteilen auch Herausforderungen mit sich, die nachfolgend genauer erläutert werden.

Fehlende Architekturarbeit – In agilen Projektzielen wird die Leistung und der Fortschritt des Projekts oft in Storypoints gemessen. Storypoints werden dabei anhand des Business Values, also der Summe umgesetzter Funktionalität der Software, vergeben. Nun lässt sich nicht jedem Product Owner glaubhaft vermitteln, dass Arbeit an der Architektur einer Softwarelösung mit Projektfortschritt gleichgesetzt werden kann und damit Storypoints gerechtfertigt sind.
Insellösungen – Bleibt die Architekturarbeit über einen längeren Zeitraum aus, schwindet die Akzeptanz bisher gelebter Rahmenbedingungen und Vorgaben. Einzelne Teams suchen bei einer Fragestellung, die architekturelle Aspekte aufgreift, nicht mehr projektübergreifend nach einer Lösung – vielleicht wurde die Fragestellung bereits von einem anderen Team beantwortet –, sondern lösen die Herausforderung auf ihre eigene Art. Diese Lösung wird allerdings durch die Ressourcen und die Skills des Teams stark beeinflusst. Je nach Fähigkeit im Team wird also auch die individuelle Lösung ausfallen. Im Laufe der Zeit entstehen Insellösungen. Ein Wechsel der Projektmitarbeiter zwischen den Teams wird somit deutlich erschwert.
Wildwuchs – Zusätzlich zu der genannten Insellösung wollen einige Softwareentwickler jede Herausforderung mit dem gerade neusten, schnellsten, modernsten, innovativsten Tool oder Framework lösen. Über die Laufzeit des Projekts kommen folglich immer wieder neue Elemente hinzu, die zum einen nicht von anderen Entwicklern übernommen und zum anderen nicht im Unternehmen gewartet und weiterentwickelt werden können.
Dokumentationsschwund – Ein modernes, agiles Softwareentwicklungsprojekt beherbergt viele Herausforderungen, die in unterschiedlichen Teams bearbeitet und gelöst werden. Zeitdruck und der Blick auf eine möglichst effiziente Erarbeitung von Business-Funktionen führt zu der Situation, dass Entscheidungen zur Architektur begleitend, sozusagen nebenher, getroffen werden. Neben der Frage, ob eine nebenher getroffene Entscheidung zu der Gesamtarchitektur des Systems und der Ausrichtung des Unternehmens passt, wird die Dokumentation der Entscheidung beziehungsweise der entstandenen Lösung öfters vergessen. Insbesondere die Dokumentation einer Umsetzung ermöglicht es neuen Entwicklern, in das Gesamtsystem einzutauchen und schnell an der Entwicklung teilzunehmen. Der Wert einer Umsetzung wird nicht allein durch das Artefakt im Sourcecode definiert, sondern aus der Genialität der Idee zur Umsetzung.
Technische "Schulden" – In einem großen Projekt wird immer wieder eine Situation entstehen, die schnelles Handeln erfordert. Häufig ist der Zeitdruck hoch und Entscheidungen müssen schnell getroffen werden. In einer solchen Situation wird der Architekturentscheidung nicht immer die höchste Priorität zugeschrieben und eine Lösung erstellt, die zu einer aktuellen Fragestellung passt, um zum Beispiel ein Release noch "durch die Tür" zu bringen. In solchen Fällen entstehen technische Schulden, welche in einer der nächsten Iterationen erneut betrachtet werden sollten. Auch hier ist die Dokumentation der entstandenen Lösung und der Entscheidungsfindung essentiell, um eine entstandene Schuld im Nachgang noch begleichen zu können.

Wo findet nun die Architekturarbeit statt und von wem?

Zuvor wurde definiert, wie sich eine Architektur in agilen Projekten von klassischen Projekten unterscheidet und welche Herausforderungen damit einhergehen. Wo findet nun eigentlich die Architekturarbeit in einem agilen Projekt statt und wie unterscheidet sich die Arbeit zu einem Projekt mit einem klassischen Upfront-Design?

Zunächst einmal ist es wichtig zu verstehen, dass sich die Arbeit an der Architektur an die Arbeit des agilen Projekts anpassen muss und umgekehrt. So ist es in der Regel nicht möglich oder sinnvoll, eine Architekturentscheidung früh im Projekt zu treffen, da diese gegebenenfalls in fortlaufenden Sprints wieder revidiert werden muss. Es sollten Entscheidungen daher eher schlank ausgeprägt und bei Bedarf weiter verfeinert werden, als direkt vollständig detailliert zu werden. Eine Detaillierung sollte risikoorientiert dort vorgenommen werden, wo sie notwendig und sinnvoll ist. Damit ist die eingangs gestellte Frage nicht eindeutig zu beantworten, die Antwort hängt vielmehr von vielen Einflussfaktoren ab.

Umfeld und Unternehmen – Dieser Einflussfaktor sieht vielleicht im ersten Moment ungewöhnlich aus und hängt nicht direkt mit dem eigentlichen Projekt zusammen, aber es ist unerlässlich, das Umfeld und insbesondere auch das Unternehmen zu verstehen, in dem das Projekt umgesetzt werden soll. Will sich die IT in Zukunft agil organisieren und ist sie bereit, eine neue Struktur im Unternehmen zu etablieren, so ist eine Aufteilung der Verantwortlichkeiten auf Domänen sinnvoll. Die Frage, wie bisher im Unternehmen Projekte umgesetzt wurden und die Rolle des Architekten gelebt wurde, hat ebenfalls starken Einfluss auf aktuelle Projektsituationen. Ein angepasster Umgang mit Architektur im Projekt geht häufig mit angepassten Verantwortlichkeiten einher. Dies wird in einem klassisch organisierten Unternehmen als Machtverlust wahrgenommen. Die Aufteilung der Verantwortung im Projekt muss folglich zur Unternehmensstruktur passen. Gleiches gilt auch auf umgekehrtem Wege. Hat in einem Unternehmen bisher eine klassische Verteilung der Verantwortlichkeiten vorgeherrscht, so werden nicht alle Mitarbeiter sofort bereit sein, mehr Verantwortung für Architekturentscheidungen zu übernehmen. Ebenfalls wichtig für Architekturarbeit in agilen Projekten ist die Frage nach den Standards, welche im Unternehmen bisher erarbeitet und befolgt wurden. Gelten diese in gleichem Maße auch für das agile Entwicklungsprojekt, so kann dies zu einer starken Einschränkung in den Architekturentscheidungen führen.
Organisatorische Einflüsse – Neben dem Umfeld haben auch der Projektaufbau und Kontext einen starken Einfluss auf die Architektur im Projekt. Ganz banale Rahmenparameter wie die Projektgröße und die damit verbundene Laufzeit sind wichtig für die Organisation des Projekts und damit für die Architekturverantwortung. Je größer das Projekt wird, desto höher ist die Verteilung der Aufgaben auf einzelne Teams. Eventuell kommen zusätzliche Herausforderungen aufgrund räumlicher Verteilungen auf das Projekt zu. Der wichtigste Faktor ist aber der Faktor Mensch. Vor allem die Menschen, mit denen das Projekt umgesetzt werden soll, sind entscheidend für die Erarbeitung der Architektur. So ist die Erfahrung der Mitarbeiter in Projekten wie auch mit dem Themenkomplex des Projekts von Interesse. Unerfahrene Entwickler sind mit hoher Wahrscheinlichkeit noch nicht bereit, Architekturverantwortung zu übernehmen und müssen von erfahrenen Mitarbeitern begleitet werden.

Abb. 1: Einflüsse auf einen agilen Architekten. © Stefan Rogge

Technische und fachliche Einflüsse – Mit der Erfahrung der Projektmitarbeiter steigt sowohl die fachliche als auch die technische Expertise im Projekt. Fühlt sich ein Projektmitglied in der Thematik des Projekts zu hause, so wird es viel eher dazu bereit sein, Verantwortung im Projekt zu übernehmen. Dies schließt auch die Architekturverantwortung mit ein. Erfahrung drückt sich dabei nicht nur in Kenntnissen von Frameworks und Technologien, sondern auch in Kenntnissen der fachlichen Domäne aus. Nicht zuletzt ist entscheidend, welche Projektmitarbeiter bereits in agilen Kontexten gearbeitet haben und damit bereits den Umgang mit der Verantwortung in den Teams kennen.

Aufbauend auf diesen Einflussfaktoren sollte auch die Architekturarbeit für das Projekt ausgestaltet werden. Dabei gilt der Leitsatz: Je weniger der genannten Einflussfaktoren gelten, desto besser lässt sich Architekturarbeit in den Teams erbringen, ohne feste Verantwortlichkeiten zu definieren. In den letzten Jahren hat Stefan Toth vier Stufen der Architekturverantwortung definiert, welche folgend vorgestellt werden [1].

Klassischer Architekt – Sind viele der aufgezählten Einflussfaktoren aktiv, bildet sich schnell die Konstellation mit einem klassischen Architekten im Projekt aus. Dieser ist verantwortlich für die gesamte Architektur der Umsetzung und wird bei Fragestellungen zum Aufbau der Lösung zu Rate gezogen. Gestützt wird diese Rollenausprägung häufig durch die Unternehmensstruktur und die Art, wie dort in der Vergangenheit Projekte umgesetzt wurden. Die Entwickler in den Projektteams sind hier nicht als Sender, sondern allein als Empfänger von Architektur- und Designvorschlägen unterwegs. Selbst bringen sie nur selten eigene Ideen in Form eigener Architekturarbeit mit ein.
Architekturverantwortlicher – Lässt sich ein Unternehmen mit seinen Mitarbeitern auf die agile Softwareentwicklung ein, so entsteht im ersten Schritt häufig das Modell des Architekturverantwortlichen. Ein Architekt agiert auf Augenhöhe mit den Projektmitarbeitern und stimmt sich eng mit diesen ab. Jedes Mitglied des Teams kann auch selbst Vorschläge zur Verbesserung der Architektur mit einbringen und wird in der Entscheidungsfindung unterstützt. Der verantwortliche Architekt muss nun noch stärker als zuvor Autorität aufgrund seiner fachlichen Expertise ausstrahlen und von den anderen Teammitgliedern akzeptiert werden.
Verantwortlicher mit Architekturagenten – Die Größe des Projekts und die begrenzten Kapazitäten des verantwortlichen Architekten machen die Verteilung der Architektur auf weitere Schultern sinnvoll. So werden einzelne Architekturthemen auf Entwickler mit entsprechendem Spezialwissen verteilt und Entscheidungen durch diese getroffen. Diese Konstellation erfordert insbesondere ein heterogenes Team, in welchem Erfahrungen zu den Schwerpunkten des Projekts vorhanden sind. Zur gleichen Zeit muss ein Umdenken klassischer Architekten stattfinden, zu vertrauen und Entscheidungen abzugeben.
Kein verantwortlicher Architekt – Ist das Team ausreichend erfahren und arbeitet schon seit längerem zusammen, kann die Architekturverantwortung vollständig an das Team übergeben werden. In dieser Konstellation stimmen sich Entwickler selbständig zu Architekturentscheidungen ab und kommunizieren diese.

Abb. 2 Verteilung der Architekturverantwortung. © Stefan Rogge

Wie geht man bestenfalls vor?

Der Artikel zeigt, welche Rolle Architekturarbeit auch in agilen Projektsituationen hat. Gerade in einem agilen Kontext besteht schnell die Gefahr, den Überblick über die Entwicklung der einzelnen Projektteams und damit auch den Blick für eine stimmige Architektur des Gesamtsystems zu verlieren. Dies bedeutet nicht, dass unterschiedliche Ansätze mit Herausforderungen umzugehen unterbunden werden sollen, sondern es geht darum, diese passend zu kommunizieren und im Nachgang für weitere Projektmitarbeiter nachvollziehbar zu dokumentieren.

Am Ende steht die Aussage "It depends!".

Die Architekturarbeit wird dazu in Projekten mit mehreren Teams bestenfalls auf mehrere Schultern verteilt. So kann das Spezialwissen Einzelner bestmöglich genutzt und die Ressourcen bestmöglich eingesetzt werden. Dieser Ansatz erfordert, ebenso wie eine konsequente agile Softwareentwicklung generell, ein Umdenken bei den Projektmitgliedern und im gesamten Unternehmen. Denn nichts hemmt die Umsetzung agiler Architekturprinzipien mehr als eine stark hierarchisch geprägte Unternehmensstruktur mit einem Architekten an der Spitze des Entwicklungsprojekts. Am Ende steht die Aussage "It depends!". Jedes Unternehmen und jedes Entwicklungsprojekt haben eigene Herausforderungen und Voraussetzungen. Wichtig ist, frühzeitig auch in agilen Projekten auf die Organisation der Architektur zu achten und diese entsprechend auszurichten. Im besten Fall wächst und entwickelt sich die Architekturarbeit im Projekt mit den Teams und wird zu einem zentralen Bestandteil der Softwareentwicklung.

Quellen