Patrick Loka 30. April 2024

Software-Architektur in agilen Projekten

Ist das Kunst oder kann das weg?

Selbstbestimmte Teams sorgen für selbstbestimmte Software-Architektur! Unter diesem Motto wird agilen Teams oft die Verantwortung für die jeweilige Software-Architektur übertragen. Und diese Herangehensweise wird allgemein auch als modern und richtig wahrgenommen, obwohl der Ansatz eine ganze Reihe offener Fragen hinterlässt. Was bedeutet es für das Team, verantwortlich für die Software-Architektur zu sein? Wie kann Architekturarbeit in agile Prozesse integriert werden? Und wie gelingt Software-Architektur in einem Umfeld mit mehreren agilen Teams? Oder ist eine gute Software-Architektur etwa ein Nebenprodukt von agilem Projektvorgehen und entsteht quasi von selbst? Software-Architektur im agilen Projektumfeld – Ist das Kunst oder kann das weg?

Sinn und Unsinn von Software-Architektur

In meinen zahlreichen Projekten habe ich verschiedene Architekturstile gesehen. Dabei fallen wiederkehrende Muster auf. Insbesondere in Gesprächen über die Motivationen von Architekturentscheidungen trifft man hier auf bemerkenswerte Aussagen:

Das ist so gewachsen ("Random-Architektur")
Wir haben das aus dem letzten erfolgreichen Projekt übernommen ("One-Size-fits-all-Architektur").
Wir sollten (oder wollten) unbedingt diese oder jene Technologie verwenden ("Technologie-Driven-Architektur").
Das wurde nach der Unternehmensstruktur entworfen ("Conway's-Law-Architektur").
Wir wollten ein modernes Framework wählen ("Hype-Driven-Architektur").
Wir haben uns an Google orientiert ("It-worked-for-Google-Architektur").

Dies alles sind häufige Antworten auf die Frage, wie und warum die vorliegende Software-Architektur so entstanden ist.

Hinter all diesen Architekturstilen verbirgt sich ein gemeinsamer Wunsch: Es soll eine funktionierende Software-Architektur als Muster genommen werden und dann passt das schon. Dieser Ansatz, bei dem Arbeit und Kosten eingespart werden sollen, ist durchaus verständlich – scheint aber oftmals nicht zum gewünschten Ziel zu führen. Anders formuliert kann man auch die Frage stellen: Software-Architektur – warum machen wir das überhaupt und was soll sie eigentlich leisten?

Zentrale Fragen der Software-Architektur

Um diese Frage beantworten zu können, sollten wir uns einmal generell fragen: Was wollen wir eigentlich mit dem Entwickeln von Software erreichen? Machen wir uns nichts vor – auch wenn viele von uns einen großen Spaß dabei haben, Software zu bauen, ist dies natürlich kein Selbstzweck. Software zu entwickeln kostet eine Menge Geld und stellt somit ein Investment dar. Von einem solchen Investment erwartet sich der Auftraggeber natürlich ein Return on Invest. Heißt, die Software soll einen Mehrwert haben, der dabei hilft, ein Geschäftsziel zu erreichen, indem er eine Fachlichkeit digitalisiert. Damit ist sie nichts anderes als ein Business Value. Diese Wertigkeit herzustellen und die damit verbundenen Geschäftsziele zu erreichen, ist daher bei der Software-Entwicklung entscheidend.

Darüber hinaus stellt sich die zweite Frage: In welchem Kontext wird die Software entwickelt und später laufen? Dieser Kontext setzt die Rahmenbedingungen, welche den Entwicklungsspielraum einschränken. Diese können viele Formen annehmen, etwa die Qualifikationen der verfügbaren Entwickler, die hausinternen technischen Gegebenheiten im Betrieb, juristische Auflagen oder natürlich die Managementklassiker Zeit und Geld.

Zuletzt stellt sich die Frage: Was soll die Software leisten? Zunächst sind wir hier natürlich wieder beim ersten Punkt. Es soll ein Business Value durch die Digitalisierung einer Fachlichkeit erzeugt werden. Abseits davon muss eine Software auch über andere Qualitäten verfügen, um eben genau diesen Business Value herzustellen und auch langfristig zu erhalten.

Was ist eine hohe Software-Qualität?

In der ISO 25010 werden die Hauptgruppen von möglichen Qualitätsmerkmalen aufgeführt: Funktionalität, Effizienz, Kompatibilität, Benutzbarkeit, Zuverlässigkeit, Sicherheit, Wartbarkeit und Portabilität. Wenn man bei einer spezifischen Software über die notwendige Qualität spricht, die den Business Value sicherstellen soll, spielen einige grundlegende Überlegungen eine wichtige Rolle. Die zentrale Feststellung ist zunächst, dass die Erhöhung der Qualität einer Software, egal in welchem Bereich, immer Geld und Zeit kostet. Das im Management bekannte "Magische Dreieck", das den Zusammenhang zwischen diesen drei Punkten herstellt, gilt auch in der Software-Entwicklung. Es ist also gar nicht zielführend, aus Selbstzweck eine Software zu bauen, die in allen Bereichen eine hohe Qualität aufweist.

Die Software-Architektur stellt am Ende sicher, dass der Business Value durch das Erreichen der nötigen Qualitäten unter den gegebenen Rahmenbedingungen erzielt wird.

Folglich ist es unter den gegebenen Rahmenbedingungen wichtig zu erkennen, in welchen Bereichen man eine hohe Qualität benötigt, um den gewünschten Business Value nicht zu gefährden – und in welchen nicht. Daraus ergeben sich zwei wichtige Punkte:

Wie gut die Qualität einer Software ist und welches die wichtigen Merkmale sind, ist für jede Anwendung sehr individuell. Bei einem Migrationsbatch, der nur einmal laufen wird, kann die Qualität, um die Anwendung gut warten oder anpassen zu können, beispielsweise nebensächlich sein. Das sieht für eine Software, die über ein Jahrzehnt laufen und sich dem Markt oder ändernden Rahmenbedingungen anpassen soll, komplett anders aus.
Eine gewünschte Qualität zu quantifizieren ist entscheidend. So kann zum Beispiel eine Ausfallzeit über eine Woche anwendungsabhängig kaum einen finanziellen Schaden hinterlassen oder schon ab der ersten Sekunde große Konsequenzen haben.

Ein gutes Mittel, um dies als (Qualitäts-)Anforderung (neben den fachlichen Anforderungen) zu hinterlegen, sind Qualitätsszenarien. Hier wird festgehalten, auf welche Ereignisse eines bestimmten Qualitätsmerkmals die Anwendung (wie und mit welcher Quantifizierung) reagieren soll. Beispielsweise kann man festhalten, dass ein Bug im Rechenkern einer Versicherung innerhalb von einem Tag von den Entwicklern behoben und in Produktion eingespielt werden muss. Dabei ist es wichtig zu erkennen, dass Anforderungen, die eine bestimmte Qualität sicherstellen sollen, meistens auch negative Auswirkungen auf andere Qualitäten haben. So wird eine Zweifaktor-Authentifizierung die Sicherheit einer Anwendung erhöhen – die Benutzbarkeit aber reduzieren. Das ist gut, wenn Sie eine Anwendung für Onlinebanking bauen, aber vermutlich eher schlecht, wenn Sie auf einen schnellen und unkomplizierten Workflow angewiesen sind, damit Ihre User die Anwendung überhaupt nutzen. Es ist also entscheidend, welche Qualitäten wichtiger sind als andere und wie eine Qualität quantifiziert ist.

Einflussfaktoren als Basis für Software-Architektur

Die Software-Architektur stellt am Ende sicher, dass der Business Value durch das Erreichen der nötigen Qualitäten unter den gegebenen Rahmenbedingungen erzielt wird. Jede architektonische Entscheidung, egal ob Technologie-Auswahl, gewählte Architekturmuster oder auch formulierte Prinzipien, soll dazu beitragen, dieses Ziel zu erreichen. Da jede Software unterschiedliche Qualitäten und Rahmenbedingungen bedienen muss, gibt es also keine grundsätzlich richtigen Architekturen oder Technologien, die man einsetzen sollte. Um eine passende Software-Architektur zu entwickeln, muss man Business Value, Rahmenbedingungen und Qualitätsanforderungen analysieren, damit die entsprechenden Architekturmaßnahmen und -entscheidungen festgelegt werden können. Sie bilden die Einflussfaktoren auf die Architektur.

Naheliegenderweise ist es aus architektonischer Sicht also am einfachsten, als Erstes alle Einflussfaktoren zu sammeln, diese zu analysieren und anhand von Architekturarbeit einen Lösungsentwurf zu erarbeiten, der den Einflussfaktoren gerecht wird. Dieser Plan kann dann umgesetzt werden. Und da hätten wir ihn: Den Wasserfall!

Agilität ist die Lösung… – Wofür nochmal?

Software-Architektur ist also wichtig, um den angestrebten Business Value sicherzustellen. Darüber hinaus erscheint der Wasserfall für die Ausarbeitung einer optimalen Software-Architektur erstrebenswert, um allen Einflussfaktoren gerecht zu werden. Ich würde sogar noch einen Schritt weiter gehen und behaupten, ein Wasserfall oder V-Modell setzt die am Anfang berücksichtigten Anforderungen günstiger und schneller um, da man in diesen Modellen weniger organisatorischen Overhead hat und mehr Ressourcen in die eigentliche Entwicklung stecken kann. Da stellt sich natürlich die Frage: Warum sollte man dann in der Software-Entwicklung überhaupt agil vorgehen?

Ungewissheiten

Diese Frage kann man am besten beantworten, wenn man die Probleme betrachtet, die bei einem nicht-agilen Vorgehen erfahrungsgemäß auftreten. Da wären zunächst die drei Arten der Ungewissheit.

Dinge, die man hätte wissen können, aber vergessen hat. Eigentlich sollte das nicht passieren, je größer aber das Projekt und damit die Liste der Anforderungen ist, desto schneller kommt es vor, dass man etwas übersieht oder etwas in der Masse verloren geht.
Dinge, die man hätte wissen können, wenn man alle Informationen gehabt hätte. Der Klassiker hier ist, dass man schlicht nicht das richtige Dokument gelesen oder mit der richtigen Person gesprochen hat, die einem den entscheidenden Hinweis hätte geben können.
Dinge, die man nicht hätte wissen können. Wie reagiert der Kunde eigentlich auf das Produkt? Wie entwickelt sich der Markt? Was macht die Konkurrenz?

Während man die ersten beiden Ungewissheiten durch gute Arbeit in den Griff bekommen kann, ist man der dritten hilflos ausgeliefert. Wenn man bedenkt, dass so ein Projekt auch mal mehrere Jahre dauern kann, bringt dies die Gefahr mit sich, zu Beginn etwas festzulegen, was später nicht mehr passt, weil wichtige, aber unbekannte Einflussfaktoren nicht mit eingeplant wurden. Je später dies auffällt, desto teurer (sowohl Geld als auch Zeit) wird die Korrektur – und zwar schnell um ein Vielfaches mehr, als wir durch die Wahl eines Wasserfall- oder V-Vorgehens gegenüber einem agilen Vorgehen eingespart haben.

Time to Market

Das zweite große Problem von wasserfallartigen Modellen ist die schlechte Time to Market. Wenn man erst alle Einflussfaktoren zusammensucht, dann die Software-Architektur entwirft, danach entwickelt und abschließend alles testet, bevor es in Produktion geht, ist das Produkt erst ganz am Schluss erstmalig auf dem Markt. Das bedeutet auch, dass man erst nach (meistens) mehreren Jahren erstmals mit seiner Investition Einnahmen bzw. einen Mehrwert generieren kann. Man muss über einen großen Zeitraum Geld investieren, ohne die Möglichkeit zu haben, Feedback aus dem Markt einzusammeln und kann die zu Beginn vielleicht noch freien Märkte nicht erschließen, während die Konkurrenz sich dort schon etabliert. Oftmals braucht man aber zu Beginn überhaupt nicht die komplette Software mit allen komplexen Möglichkeiten, stattdessen reicht schon ein Minimal Valuable Product (MVP).

In vielen Fällen schafft die deutlich abgespeckte Form des Produktes bereits einen deutlichen Mehrwert und erreicht unter Umständen schon Geschäftsziele, die man später auch mit einem hochwertigen Produkt nur noch schwer erreichen kann. Ein agiles Vorgehen kann schon ein solches MVP schnell als erste Iteration auf den Markt bringen, sich Feedback einholen und auch schon die dadurch gewonnenen Erkenntnisse in die Weiterentwicklung einfließen lassen.

Dynamische Qualitätsanforderungen

Im Ergebnis der ersten beiden Punkte steht der dritte Punkt: Durch die Aufdeckung von vorherigen Ungewissheiten und das Feedback auf dem Markt können sich Qualitätsanforderungen ändern. Beispielsweise könnte man feststellen, dass viel höhere Anforderungen an Skalierbarkeit erforderlich sind und sich eine hohe Benutzbarkeit gar nicht so auszahlt wie zuvor angenommen. Solche dynamischen Einflussfaktoren können in einem Wasserfallmodell nur sehr schwer bedient werden, wohingegen frühzeitige Anpassungen in einem agilen Vorgehen leichter möglich sind.Somit kann die Software-Qualität frühzeitig und individuell für die zu entwickelnde Anwendung an die realen Gegebenheiten angepasst werden.

Agilität bietet also strategische Möglichkeiten, die genauso wie eine passende Software-Architektur helfen, den gewünschten Business Value sicherzustellen und Risiken zu vermeiden. Auf der anderen Seite sind die Kosten eines solchen Vorgehens höher. Man sollte also abwägen, bevor man pauschal die Entscheidung für ein agiles Vorgehen trifft. Das auf sechs Monate angelegte Migrationsprojekt, das komplett fertig sein muss, bevor es ausgeführt werden kann und bei dem die Informationslage sehr gut ist, wird sicherlich besser und effizienter ohne agiles Vorgehen umgesetzt. Erwartet man ein langes Projekt, in dem man sich immer wieder neuen Gegebenheiten anpassen will und bei dem es wichtig ist, schnell auf dem Markt zu sein, hat ein agiles Vorgehen hingegen große Vorteile.

Agilität bietet strategische Möglichkeiten, den gewünschten Business Value sicherzustellen und Risiken zu vermeiden.

Wenn aber erste Anforderungen schon in einer laufenden Software umgesetzt sind, bevor man alle Anforderungen kennt und man sich bereits die komplette Software-Architektur überlegt hat, wie kann dann sichergestellt werden, dass sie den benötigten Qualitätsansprüchen genügt? Und wie kann man Architekturarbeit in einen agilen Prozess einflechten, in dem man auf Anforderungsänderungen reagieren muss?

Die Agile Software-Architektur

Um Architekturarbeit in einen agilen Prozess einzubinden, muss man sich zunächst damit beschäftigen, wie dieser strukturell funktioniert. Nehmen wir einfach mal das bekannteste und relevanteste agile Verfahren Scrum, ohne jetzt bis ins letzte Detail auf das Agile Manifest oder den Scrum-Guide einzugehen. Ein Scrum-Team besteht aus einem Scrum Master, einem Product Owner und dem selbstbestimmten Team.

Von außen betrachtet ist ein solches selbstbestimmtes Team eine Blackbox.

Das selbstbestimmte Team ist in erster Linie dafür da, Anforderungen umzusetzen. In Zyklen werden dafür aus einem Backlog die wichtigsten Anforderungen herausgesucht und zu einem Inkrement umgesetzt. Dabei obliegt es dem Team selbst, wie es die Anforderungen umsetzt. Es bestimmt selbst über Mittel und Wege, organisiert sich selbst und kümmert sich darum, dass durch die Umsetzung der Anforderungen der gewünschte Mehrwert entsteht. Zudem stellt es sicher, dass bereits realisierte Anforderungen künftig erhalten bleiben und auch Teil der kommenden Inkremente sind. Von außen betrachtet ist ein solches selbstbestimmtes Team eine Blackbox. Man schiebt Anforderungen rein, weiß nicht, was dann passiert, aber es kommt der gewünschte Mehrwert als Ergebnis raus.

Äußere Einflussfaktoren auf die Architekturarbeit agiler Teams

Der Product Owner ist verantwortlich für das Produkt als Ganzes. Er stellt die Anforderungen in einem Backlog zusammen und sortiert sie nach Wichtigkeit. Das ist aus architektonischer Sicht erst einmal eine bemerkenswerte Rollenbeschreibung, da sie die Qualität des Produktes mit einschließt. Daraus ergibt sich, dass es insbesondere am Product Owner liegt zu entscheiden, welche Qualitäten die zu entwickelnde Software haben soll und wie wichtig ihm das im Vergleich zu fachlichen Anforderungen ist. Er kann sie beispielsweise als Qualitätsszenarien ins Backlog einfließen lassen und die Wichtigkeit im Verhältnis zu den anderen (fachlichen) Anforderungen abbilden. Auf diese Weise ist das Team aktiv aufgefordert, eine passende Software-Architektur zu entwickeln, welche die geforderten Qualitäten sicherstellt. Fordert er Qualitäten nicht ein, priorisiert er sie nach unten oder meint er, diese Qualitäten abseits des agilen Prozesses als selbstverständlich voraussetzen zu können, treten oftmals drei Effekte auf:

Die Qualität wird wahrscheinlich niedrig werden, weil niemand daran arbeitet.
Die Qualitätsausprägung wird willkürlich sein, weil niemand dem Team sagt, was eigentlich wichtige Qualitäten sind und wie die Qualität quantifiziert ist.
Die Qualität wird mit zunehmender Dauer abnehmen. Nur wenn Qualität angefordert und umgesetzt wurde, ist das Team wie beschrieben dafür verantwortlich, darauf zu achten, dass auch die folgenden Inkremente der Qualitätsanforderung umsetzen werden – als natürlicher Teil des agilen Prozesses.

Man kann das Team also auf diese Weise in die Verantwortung nehmen, dass die angeforderte Qualität ungesetzt wird und auch mit zunehmendem Projektalter erhalten bleibt.

Qualitäten anzufordern ist aber nicht der einzige Hebel, um dem Team von außen Vorgaben für die Software-Architektur zu machen, ohne die Selbstbestimmtheit der Arbeit zu gefährden. So kann man vorab einen klaren Verantwortungsbereich definieren, in dem das Team operieren und sich auf natürliche Weise selbst verantwortlich fühlen soll. Es muss klar sein, was sich in der Blackbox des selbstbestimmten Teams befindet und das Team muss sich darauf verlassen können, dafür auch die Entscheidungshoheit zu besitzen.

Meistens ist noch viel wichtiger festzulegen, wofür das Team nicht verantwortlich ist und was es nicht machen und entscheiden kann und soll. Dies definiert den Scope eines Teams. Zudem muss auch klar sein, was das Team mit einem Problem macht, welches es zwar an der Umsetzung der Anforderungen hindert, aber außerhalb seines eigenen Wirkungsbereiches liegt. Darüber hinaus kann man Rahmenbedingungen und Ziele des Teams mitteilen, an denen es sich orientieren kann, um möglichst optimale Entscheidungen zu treffen.

So wird ein Team vermutlich bessere Lösungen finden können, wenn es weiß, warum und unter welchen Umständen es arbeitet. Zusätzlich kann man ihm auch schon Entscheidungshilfen in Form von Prinzipien an die Hand geben. Sagt man einem Team, dass im Zweifel Kaufen für das Erreichen der Unternehmensziele prinzipiell besser als Selbstentwickeln ist, kann es eine architektonische Entscheidung danach ausrichten.

Nun bleibt noch das Staffing des Teams. In der Regel soll ein selbstbestimmtes Team eine ganze Reihe an unterschiedlichen Anforderungen erfüllen. Das kann es nur dann tun, wenn es auch mit Mitgliedern besetzt ist, die das entsprechend umsetzen können.

Wenn das Team auch Anforderungsanalyse betreiben und die Software testen soll, dann macht es wenig Sinn, ein Team aus sechs Entwicklern damit zu beauftragen. Wenn mir die Qualität der Sicherheit sehr wichtig ist, sollte ich gegebenenfalls einen Platz im Team mit jemandem besetzen, der sich wirklich gut mit dem Thema Sicherheit auskennt. Das sorgt nicht nur dafür, dass das Team das richtige Know-how hat, um die kommenden Anforderungen in diesem Bereich umzusetzen. Man hat außerdem jemanden im Team, dem das Thema wichtig ist und der dafür sorgen wird, dass die Qualität in diesem Bereich entsprechend hoch bleibt. Die Idee von agilen Teams ist Diversität und die Zusammenarbeit von verschiedenen Leuten mit unterschiedlichen Fähigkeiten. Die Teams nach Aufgaben und Kompetenzen zu gruppieren ist der Wasserfall-Ansatz.

Dies alles sind Inputs und Parameter, die der Blackbox des selbstbestimmten Teams helfen werden. Je besser man dem Team beschreibt, wie das Ergebnis aussehen soll, in welchem Rahmen und Kontext es sich bewegt, desto eher ist es auch dazu in der Lage, den gewünschten Mehrwert zu erzeugen.

Aktive Architekturarbeit in agilen Teams

An diesem Punkt wollen wir aus der Blackbox eine Whitebox machen. Das selbstbestimmte Team bekommt also Ziele und Rahmenbedingungen, Prinzipien und Qualitätsanforderungen, welche es beachten oder erfüllen soll. Um diesen gerecht zu werden, muss es anfangen, Architekturarbeit zu betreiben und in den eigenen agilen Prozess zu integrieren. Dabei ist es mit einigen Problemstellungen konfrontiert.

Eine davon haben wir bereits besprochen. Qualität kann über Qualitätsszenarien angefordert werden und so den kompletten agilen Prozess durchlaufen. Damit ist schon mal geklärt, welche Priorität diese Qualität genießt, was genau umgesetzt werden muss, wann dies passieren muss und dass sicherzustellen ist, dass die Anforderung auch umgesetzt bleibt. Im besten Fall organisiert das Team automatisierte oder zumindest manuelle Tests, um bei jedem neuen Inkrement zu prüfen, ob diese Anforderung auch weiterhin erfüllt wird.

Dynamische Einflussfaktoren mit der Software-Architektur-Vision im Blick behalten

Ein etwas schwierigeres Problem sind sich ändernde Einflussfaktoren. Eine neue Qualitätsanforderung oder eine bisher unbekannte Fachlichkeit können eine Architekturänderung notwendig machen. Zu Beginn kennt man zwar oft Kernziele und Rahmenbedingungen sowie meistens einen Teil der benötigten Qualitäten. Trotzdem ist dies immer nur ein Ausschnitt der gesamten Anforderungen.

Mit wachsender Anzahl können neue Anforderungen die bisherige Software-Architektur weniger passend machen. Oftmals wird dann versucht, die einmal aufgesetzte Software-Architektur beizubehalten und etwas außen hinzuzufügen und Kompromisse zu machen. Das führt in der Regel dazu, dass die benötigte Qualität nicht mehr erreicht wird, weil die Software-Architektur dies nicht mehr sicherstellt.

Das Team sollte also von Beginn an einplanen, dass die aufgesetzte Software-Architektur nicht nach einmaliger Erstellung fest ist. Vielmehr sollte es sich überlegen, wie es mit solchen Anforderungen umgeht, welche eine Architekturänderung erforderlich machen.

Ein gutes Tool, um dies zu erreichen, ist die sogenannte Software-Architektur-Vision. Sie ist ein grober Entwurf dessen, wie die Software-Architektur einmal aussehen soll, wenn alle Anforderungen im Backlog umgesetzt sind. Sie wird damit allen bekannten Einflussfaktoren gerecht und gibt eine grobe Richtung für die tägliche Arbeit des Teams vor. Dem gegenüber steht die Dokumentation des aktuellen Inkrements, welche die Software-Architektur der bisher bereits umgesetzten Anforderungen beschreibt.

Ein guter Zeitpunkt, sich mit der Architektur-Vision auseinanderzusetzen, ist in Scrum das Backlog Refinement. Hier stellt der Product Owner eine bisher unbekannte Anforderung vor, lässt vom Team den Aufwand schätzen und legt die Anforderung dann im Backlog ab, um diese eines Tages umsetzen zu lassen. Oftmals werden bereits hier die Anforderungen in konkrete Arbeitspakete heruntergebrochen, die zur Umsetzung erledigt werden müssen. Zu diesem Zeitpunkt sollte man sich die Architektur-Vision zur Hand nehmen und überlegen:

Passt diese Anforderung zu der Architektur, die wir uns bisher vorgestellt haben?
Habe ich eine erste konkrete Idee, wie diese dort eingebettet wird?
Oder gibt unsere bisherige Vorstellung der Software-Architektur eine Umsetzung einer solchen Anforderung eigentlich nicht her?

Im letzten Fall wäre die erste Aufgabe, die Architektur-Vision so anzupassen, dass die Anforderung zusammen mit allen anderen in der benötigten Qualität umgesetzt werden kann.

In den meisten Fällen wächst die Software-Architektur mit der Zeit einfach. Manchmal muss man aber auch etwas Grundlegendes ändern und dem Product Owner mitteilen, dass die Umsetzung dieser Anforderung einen gewissen architektonischen Umbauaufwand beinhalten wird. Das klingt erstmal schlimm, ist aber zum einen der früheste Termin, an dem das Team auf diese Anforderung reagieren kann und zum anderen eine Investition in die Zukunft.

Viele kleine Änderungen an der Software-Architektur sind billiger als eine große, weil die gewünschte Qualität nicht erreicht werden kann. Die Erfahrung zeigt, dass Architekturänderungen mit laufendem Projektfortschritt auf diese Weise immer weniger werden und immer mehr Anforderung in die bereits bestehende Architektur-Vision passen. Nichtsdestoweniger bleibt es eine Vision, die niemals fertig ist. Sie entwickelt und detailliert sich sowohl vor als auch bei der Umsetzung. Mit der gemeinsamen Arbeit an dieser Architektur-Vision fließt die Architekturarbeit auch in Form von nötig werdenden Tasks in den agilen Prozess und damit in die tägliche Arbeit mit ein.

Viele kleine Änderungen an der Software-Architektur sind billiger als eine große.

Zudem ist es hilfreich, Rahmenbedingungen und Prinzipien (das können von außen vorgegebene, aber auch basierend auf eigenen Architekturentscheidungen selbst formulierte Entscheidungshilfen sein) zusammen mit der Architektur-Vision zu führen, um diese bei der Architekturarbeit im Blick zu behalten. Darüber hinaus können auch Qualitätsszenarien zusätzlich eingezeichnet werden, etwa um zu markieren, welche Teile der Software-Architektur welche Qualitäten sicherstellen.

Software-Architektur über mehrere Sprints planen – Mit dem Architecture Runway

Ein weiteres Problem stellen die oftmals zu kurzen Sprintlängen dar. Dies ist vor allem in der Frühphase von Projekten schwierig, wenn noch zu wenig umgesetzt ist, um darauf aufzubauen. Insbesondere viele Querschnittsfunktionalitäten oder auch technische Grundlagen sind für viele Anforderungen noch nicht vorhanden. Im Backlog Refinement wird überlegt, wie eine Anforderung umgesetzt werden kann. Dabei entstehen architektonische Aufgaben, welche vor der eigentlichen Anforderung zu erledigen sind. Wenn der Product Owner im ersten Sprint mit der für ihn kleinen Anforderung eines Login-Fensters anfangen möchte, müsste man dafür schon ein Frontend und ein Backend, eine Datenhaltung für Anmeldedaten sowie irgendeine Form von Security aufsetzen. Dabei sind fachliche Dinge wie Registrierung, Bestätigung der Mailadresse oder Passwortrücksetzung noch gar nicht angefordert. Dennoch wird man vermutlich nur sehr schwer Frontend, Backend und Datenhaltung im ersten Sprint aufbauen sowie ein Sicherheitskonzept ausarbeiten und umsetzen.

Es sind also, startend bei der Architektur-Vision, einige architektonische Aufgaben zu erledigen, bevor diese Anforderung ins Auge gefasst werden kann. Diese architektonischen Aufgaben können in einem Architecture Runway der entsprechenden Anforderung beigefügt werden. Die Idee ist die eines startenden Flugzeugs auf der Startbahn. Es braucht eine gewissen Strecke, bevor es abheben kann. Genau so sind vor der Umsetzung einer konkreten Anforderung ggf. architektonische Maßnahmen umzusetzen. Sind alle auf der Startbahn platzierten architektonischen Aufgaben (oder ausreichend viele davon) erledigt, kann der Flieger abheben und die Anforderung umgesetzt werden. Wenn man mehrere Anforderungen durchgeht, stellt man fest, dass auch andere Anforderungen ein Frontend oder Backend brauchen. Darunter ist sicherlich auch eine Anforderung, welche ebenfalls auf ein aufgesetztes Frontend angewiesen ist, jedoch, bereits in einem Sprint umgesetzt werden kann.

Man kann also auf dem Architecture Runway einplanen, in welchem Sprint die Aufgabe "Frontend aufsetzen" im Rahmen einer anderen Anforderung schon umgesetzt wird. Im nächsten Sprint sucht man sich dann eine Anforderung raus, welche das Backend aufsetzt. Und schon sind genügend architektonische Voraussetzungen geschaffen, auch den Login umzusetzen. Der Architecture Runway bietet dabei dem Team, aber auch dem Product Owner gegenüber die Übersicht, was noch zu erledigen ist und wie lange es dauern könnte, eine Anforderung umzusetzen. Dadurch priorisiert der Product Owner vielleicht eine Anforderung hoch, um architektonische Grundlagen zu schaffen, um im Anschluss sein wichtigstes Anliegen zeitnah angehen zu können. Das Architecture Runway hilft dabei, Architekturarbeit und -aufgaben anforderungsgerecht einzuplanen und nahe an den Anforderungsbedürfnissen umzusetzen. Es können durchaus auch Aufgaben auf dem Architekture Runway landen, welche außerhalb des Scopes des selbstbestimmten Teams liegen. In dem Fall wird der Product Owner mit dem zuständigen Team ins Gespräch gehen müssen, um diese benötigte Aufgabe erledigen zu lassen.

Das letzte Problem ist Nachvollziehbarkeit. Wenn man immer wieder neu an der Software-Architektur arbeiten und auch bei wechselndem Personal Änderungen an dieser vornehmen muss, ist es wichtig sich zu erinnern, warum man gewisse Schritte teilweise vor ewiger Zeit so geplant oder gar umgesetzt hat. Wir haben bei den Ungewissheiten besprochen, dass man solche Schritte auch wieder vergessen oder in der Größe des Projektes übersehen kann.

Dann ist es wichtig zu dokumentieren, warum man eine bestimmte Architekturentscheidung getroffen hat. Ideal hierfür sind die Architecture Decision Records (ADR). In dieser Struktur wird nicht nur die einzelne Entscheidung dokumentiert. Es wird eine Problembeschreibung formuliert, welche architektonisch gelöst werden soll. Hinzu kommt der Kontext, in dem dieses Problem aufgetreten ist – etwa eine Anforderung. Anschließend werden verschiedene Lösungsmöglichkeiten skizziert und die Vor- und Nachteile gegenübergestellt. Es wird eine Entscheidung für eine der Möglichkeiten notiert und erläutert, warum man sich gerade für diese und gegen alle anderen Varianten entschieden hat. Abschließend werden daraus abgeleitete Konsequenzen festgehalten. Etwa Maßnahmen zur Umsetzung, Einschränkungen, Bedingungen oder entstehende Möglichkeiten für die Zukunft. Wichtig ist, dass man Konsequenzen nicht ausschließlich negativ sieht. Im Gegenteil ist sogar zu hoffen, dass eine Architekturentscheidung am Ende viele positive Konsequenzen hat!

Wenn jemand später eine architektonische Entscheidung nachvollziehen möchte, kann man dies aus einer zukünftigen Perspektive rekonstruieren und hinterfragen:

Was war der Hintergrund dieser Entscheidung?
Hat man damals auch andere Lösungen in Erwägung gezogen und wenn ja, warum hat man sich dagegen entschieden?
Wissen wir heute mehr oder haben zusätzliche Anforderungen, die eine Korrektur der damalig richtigen Entscheidung notwendig machen?
Hat sich das Projekt vielleicht anders entwickelt als gedacht, sodass die negativen Konsequenzen stärker und die positiven schwächer sind als vermutet?

Wann immer bei einer neuen Anforderung über eine Architekturänderung nachgedacht werden muss, lohnt es sich, diese Fragen zu stellen und die damaligen Erkenntnisse auch in die neue Architektur-Vision einfließen zu lassen. Genau aus diesem Grund ist es auch hilfreich, neben Rahmenbedingungen, Prinzipien und Qualitätsszenarien eben diese ADRs auch an entsprechender Stelle in der Architektur-Vision einzuzeichnen, um sie bei der Architekturarbeit im Blick zu behalten.

Agile Software-Architektur: Makroarchitektur goes wild

Mit Hilfe dieser Tools kann man es gut schaffen, Architekturarbeit in den agilen Prozess einfließen zu lassen. Sie sorgen dafür, dass Software-Architektur ein stets präsentes Thema im Team bleibt. Sie helfen dabei, mit wechselnden Anforderungen und darauffolgenden Architekturänderungen umzugehen und stellen sicher, dass die Qualität auch bei fortlaufendem Projektstatus dem geforderten Standard entspricht. So kann ein Team für sich mit der gegensätzlichen Problematik von Software-Architektur und agilem Vorgehen selbstbestimmt umgehen. Was ist aber mit Architekturentscheidungen, die über die Teamgrenzen hinausgehen? Wir haben festgestellt, dass der Blackbox "Selbstbestimmtes Team" Vorgaben als Input für eine mehrwertorientierte Arbeit von außen mitgegeben werden können. Woher kommen diese Inputs und auf welcher Basis entstehen diese? Dabei hilft der Begriff der Makroarchitektur.

Mikroarchitektur und Makroarchitektur

Kleinere Systeme können von einem einzigen Team gebaut werden. Werden die Systeme aber größer, muss man darüber nachdenken, mehrere Teams einzusetzen. Jedes dieser Teams bearbeitet dann bestimmte Teile oder Komponenten des Gesamtsystems. Während sich Mikroarchitektur mit den Architekturentscheidungen innerhalb einer solchen Komponente befasst und vom Scrum-Team selbständig ausgearbeitet und umgesetzt wird, beschäftigt sich die Makroarchitektur mit den komponentenübergreifenden Themen. Erinnern wir uns zurück an den Sinn von Software-Architektur, ist die Notwendigkeit dazu naheliegend. Eine einzelne Komponente erzeugt zwar einen Mehrwert für das zu bauende System, einen wirklichen Business Value erzeugt das System aber nur in seiner Gesamtbetrachtung.

Da sich aber jedes Team nur mit den Zielen seiner eigenen Komponente befasst, liegt die Sicherung der Qualität sowie die Einhaltung von Rahmenbedingungen, um das Business Value des Gesamtsystems herzustellen, außerhalb des Scopes jedes dieser Teams. Den Business Value des Gesamtsystems sicherzustellen, scheint jedoch eine zentrale Hauptaufgabe von Software-Architektur zu sein. Es ist wichtig, dass sich jemand dafür verantwortlich fühlt. Ansonsten riskiert man eine willkürlich wachsende oder wenig anforderungsorientierte Makroarchitektur.

Aufgaben der Makroarchitektur

Was sind also zentrale Aufgaben von Makroarchitektur? Sie definiert anhand der gegebenen Einflussfaktoren, welche Komponenten zur Herstellung des Business Values notwendig sind. Wichtig dabei ist, dass die kleinste Einheit, mit der sich Makroarchitektur noch befasst, eine Blackbox-Komponente ist, welche gut von einem Scrum-Team entwickelt werden kann. Dieser Komponente kann Makroarchitektur jetzt bestimmte Eigenschaften zuweisen. Zum Beispiel, welche Qualität sie haben muss, um die Qualität des Gesamtsystems sicherzustellen, welche fachliche Funktion sie erfüllen soll und unter welchen Rahmenbedingungen und mit welchen Prinzipien diese entwickelt und betrieben werden muss.

Dabei kann man sich schon überlegen, welche Kompetenzen beim Staffing des für die Komponente zuständigen Teams wichtig sind, damit die Anforderungen auch mit dem nötigen Know-how umgesetzt werden können. Dass sich Makroarchitektur darauf verlässt, dass die Anforderungen umgesetzt werden, ist entscheidend. Sie kann die Erfüllung als gegeben einplanen, ohne sich um die konkrete Lösung im Detail zu kümmern. Dies obliegt dann später dem selbstbestimmten Team, dessen Aufgabe darin besteht, den der Komponente zugewiesenen Mehrwert wie angefordert herzustellen. Anders als in der klassischen Architekturarbeit geht es also weniger darum, dem Entwickler vorzuschreiben, wie er zu arbeiten hat, sondern vielmehr darum, ihm präzise mitzuteilen, welches Ergebnis von ihm erwartet wird.

Des Weiteren muss sich Makroarchitektur nun überlegen, wie die einzelnen Komponenten und Scrum-Teams miteinander interagieren:

Welche Komponenten dürfen miteinander Daten austauschen?
Welche Abhängigkeitsverhältnisse gibt es zwischen den einzelnen Komponenten?
Wenn es Schnittstellen gibt, welches der beiden Teams darf diese vorgeben?
Außerdem stellt sich die Frage, welche Querschnittskomponenten es geben soll. Darf sich jede Komponente ein eigenes Logging und Monitoring einrichten oder erstellt man dafür eine systemweite Komponente, an die sich alle anderen anbinden sollen? Will man die Komponenten direkt miteinander sprechen lassen oder stelle ich ein Messaging-System zur Verfügung, über welches Daten ausgetauscht werden können? Was gehört noch in den Scope der Teams und wofür sollen systemweite architektonische Lösungen erstellt und genutzt werden?

Makroarchitektur entscheidet also auch darüber, was innerhalb des Systems zur Makroarchitektur gehört und welche Aufgaben den Teams selbst überlassen werden. Zu guter Letzt muss eine Plattform erstellt werden, in der die einzelnen Komponenten laufen und kommunizieren können. Handelt es sich um ein verteiltes System, indem jede Komponente einzeln deployt werden kann oder wird ein Artefakt deployt? Wie sehen Schnittstellen zwischen Komponenten technisch aus? Auf welcher Infrastruktur läuft das System? Makroarchitektur zeichnet für alles verantwortlich, was die Inkremente der einzelnen Komponenten am Ende zu einem ineinandergreifenden System zusammenarbeiten lässt.

Architekturarbeit auf Ebene der Makroarchitektur

Die entscheidende Frage ist jetzt, wer diese Architekturarbeit auf der Ebene der Makroarchitektur eigentlich leistet und wie man diese Arbeit in den agilen Prozess einfließen lässt. Die gängigsten Lösungen können in zwei verschiedene Gruppen eingeteilt werden.

Makroarchitektur mit Bottom-Up
Zum einen gibt es den Bottom-Up-Ansatz. Dieser besagt, dass die Teams selbst sich zusammensetzen und die Makroarchitektur gestalten sollen. Egal ob es dabei um Community of Practice, Gilden oder Veedel geht. Letztlich treten dabei immer die gleichen Probleme auf. Zum einen haben solche Strukturen stets einen Workshopcharakter. Es wird ein Thema in kürzester Zeit mit allen Teams besprochen und einer Lösung zugeführt. So funktioniert Architekturarbeit einfach nicht. Es muss sich die entsprechende Zeit genommen werden, eine anforderungsgerechte Lösung auszuarbeiten und vor allem im agilen Kontext ist eine kontinuierliche Arbeit und ständiges Hinterfragen entscheidend.

Darüber hinaus hat jeder Teilnehmer zuallererst den Scope des eigenen Teams. Statt der richtigen Lösung für das System wird also ein angenehmer Kompromiss aller Komponenten ausgehandelt. Abschließend wird basierend auf Conway's Law eine von der Struktur der Teams getriebene Makroarchitektur entstehen. Das ist genau, was wir nicht wollen. Die Software-Architektur sollte auf den Anforderungen basieren und die Struktur der Teams sollte sich dementsprechend anpassen – nicht umgekehrt.

Makroarchitektur mit Top-Down
Der andere klassische Ansatz kommt ein wenig aus dem Wasserfall-Vorgehen. Der klassische Architekt gibt hier top-down exakt vor, was entwickelt werden soll. Im Kerngedanken halte ich das für den besseren Weg, jedoch bedient er den agilen Ansatz nicht. Sich zunächst die komplette Makroarchitektur zu überlegen, widerspricht nicht nur der agilen Grundidee, vielmehr verliert man auch alle beschriebenen Vorteile des agilen Vorgehens.

Auch die Makroarchitektur kann auf Feedback oder veränderte Anforderungen reagieren. Insbesondere das Feedback der Entwicklungsteams sowie die ersten Erfahrungen in Produktion können schnell zeigen, welche Aspekte schon gut tragen und an welchen Punkten man vielleicht umdenken muss. Zudem können neue Anforderungen neue Komponenten notwendig machen. Es ist also durchaus zielführend, auch die Makroarchitektur agil zu entwickeln. Und wie zuvor auch passt hier das Konzept des agilen selbstbestimmten Scrum-Teams gut.

Ein agiles Team für eine agile Makroarchitektur

Zunächst einmal ist die Erkenntnis eigentlich naheliegend, dass auch das Gesamtsystem einen Product Owner haben sollte. Dieser ist verantwortlich für den Business Value des Gesamtsystems und gibt Qualität und Anforderungen sowie Rahmenbedingungen vor. Diese können beispielsweise auch von der Enterprise-Architektur des Unternehmens kommen oder dienen schlicht dem Mehrwert des zu entwickelnden Systems.
Das Staffing des Teams ist ebenfalls divers an die Anforderungen und das System anpassbar. Da dieses Team sich in erster Linie nicht mit Implementierung, sondern mit Software-Architekturaufgaben befasst, ist ein Architekt meist ein guter Baustein. Aber auch andere Rollen können sich sinnvoll in die Makroarchitekturarbeit einbringen.

Bei hohen Sicherheitsanforderungen ist ein Experte im Team genauso sinnvoll wie bei der Erstellung eines systemeinheitlichen Look-and-feels. Wenn man die Qualität sicherstellen will, sind zudem Leute gefragt, die Ahnung vom Testen haben. Die Anforderungen werden auch hier im Backlog Refinement besprochen und mit der Makroarchitektur-Vision verglichen. Im Sprint werden unter Umständen Anpassungen an der Software-Architektur oder den Anforderungen an die Komponenten erarbeitet. Darauf aufbauend wird festgelegt, welche Komponenten und Teams einzelne Teile der Anforderungen umsetzen sollen und dies weitergereicht.

Ziel des Sprints ist hier dann nicht die Implementierung einer Anforderung, sondern zunächst die Lösung und Einordnung auf Makroarchitekturebene. Das kann bei vielen Anforderungen sehr schnell gehen, wenn die dafür notwendigen Komponenten bereits vorhanden sind. Bei anderen müssen neue Lösungen ausgearbeitet werden. Umgekehrt bekommt man von den Teams Feedback und Anforderungen zur Makroarchitektur. Sie können schnell mitteilen, dass sie jetzt endlich ein systemweites Logging brauchen oder der fachliche Schnitt sich als unpraktikabel herausstellt hat und angepasst werden muss.

Zudem bekommt der Product Owner des Systems über die Architecture Runways der Teams einen Gesamtüberblick, wann auch bei teamübergreifenden Anforderungen mit einem Durchbruch zu rechnen ist. Das mit der Makroarchitektur beauftragte Team arbeitet mit den gleichen Vorgehensweisen und Tools an den anstehenden Anforderungen, wie es zuvor für jedes agile Team beschrieben ist – mit dem Unterschied, dass der Scope ein anderer ist und dieser mehr Architekturarbeit und weniger Implementierung beinhaltet. Auch sollte man das Verhältnis zwischen diesem Team und den anderen Teams keinesfalls hierarchisch leben. Es ist ein gleichberechtigtes Team mit seiner ganz eigenen Aufgabe und ohne Weisungsbefugnis. Es definiert Komponenten sowie deren Eigenschaften, Ziele und Beziehungen untereinander. Es hält sich bei der Umsetzung dieser Komponenten aber komplett raus.

Die Teams sollen sich bei der Erfüllung ihrer jeweiligen Aufgaben unterstützen und auf Augenhöhe zusammenarbeiten. Top-down gilt hier nur für die technische Sicht, nicht für die Zusammenarbeit! Architektonisch gesprochen, operiert das Team in einer anderen Flughöhe und bekommt damit einen anderen Scope. Die Zusammenarbeit muss aber auf Augenhöhe stattfinden. Die Makroarchitektur natürlich in den agilen Prozess zu integrieren und sie nach den gleichen Prinzipien inkrementell zu entwickeln und anzupassen, ist entscheidend. Je mehr Architekturarbeit neben oder über dem agilen Prozess steht, desto weniger wird eine erfolgreiche Software-Architektur entstehen.

Wo ist Mr. A? Der Software-Architekt in agilen Projekten?

Eine letzte Frage, die häufig gestellt wird, lässt sich nun abschließend auch beantworten. Wo ist im agilen Vorgehen eigentlich der klassische Architekt?

Dazu ist zunächst einmal festzuhalten, dass jeder, der aktiv Architekturarbeit betreibt, auch Software-Architekt ist. In einem agilen Team kann das ein Einzelner machen, es kann aber auch vom Team gemeinsam geleistet werden. Wenn die Qualitätsansprüche an die Aufgabe des Teams hoch sind, ist es vermutlich sinnvoll, jemanden im Team zu haben, der das architektonische Handwerkszeug mitbringt.

Selbstbestimmt heißt eben auch, selbst zu bestimmen, wann man Hilfe annehmen möchte.

Ist dies nicht der Fall, dann braucht das Team so jemanden nicht. Für ein Team, das sich ausschließlich mit Makroarchitektur auseinandersetzt, trifft das vermutlich eher zu als für eines, in dem hauptsächlich Fachlogik implementiert wird. Darüber hinaus gibt es auch weitere Möglichkeiten, ein Team zu Architekturarbeit zu befähigen. Oft reicht es, das Team zu schulen und es mit den hier vorgestellten Tools zur agilen Architekturarbeit vertraut zu machen. Wenn ein Software-Architekt aus der Makroarchitektur heraus das selbstbestimmte Team mit einer Anforderung architektonisch überfordert, ist es auch immer eine gute Lösung, den Architekten zu einem Backlog Refinement mit einzuladen und sich bei der Lösungsfindung helfen zu lassen. Auch ein Review kann oftmals sehr zielführend sein. Entscheidend dabei ist, dass der Eingeladene zwar Vorschläge macht und berät, die Selbstbestimmtheit des Teams aber unangetastet bleibt.

Selbstbestimmt heißt eben auch, selbst zu bestimmen, wann man Hilfe annehmen möchte und wann nicht. Das Team bleibt komplett selbst für das Ergebnis verantwortlich! Wie schon angesprochen kann es sogar zielführender sein, bei speziellen Qualitätsanforderungen gar keinen Software-Architekten im Team zu haben, sondern einen Experten genau für eine bestimmte Qualität. Diese sind oftmals viel geeigneter für die anstehenden Aufgaben und bringen für diese eine spezielle Qualität eigene Tools und Methoden mit, um beispielsweise Sicherheit oder Benutzbarkeit in den agilen Prozess mit einzubinden.

Software-Architektur in agilen Projekten: Fazit

Dieser Artikel ging der Frage nach, ob und wie Architekturarbeit in einen agilen Prozess integriert werden kann. Dabei wurden die Probleme und Widersprüche zwischen sinnvollem architektonischem Vorgehen und einem agilen Prozess beleuchtet. Anhand einiger Tools und Arbeitsweisen wurde dargestellt, wie die Integration der Architekturarbeit in einem agilen Umfeld trotzdem gelingen und so durch die gegenseitige Ergänzung der beiden Ansätze der angestrebte Business Value erzielt werden kann.