Für den Begriff Softwarearchitektur finden sich eine Vielzahl unterschiedlicher Definitionen. Ich definiere Softwarearchitektur gerne als die Summe an Entscheidungen, die später nur schwer zu ändern sind. (https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf).  Doch um wirklich erfolgreich zu sein, muss die Softwarearchitektur nicht nur technische Anforderungen erfüllen, sondern vor allem die übergeordneten Produktziele unterstützen.

Von der Produkt-Vision zu Architekturentscheidungen

Alles beginnt mit einer klaren Produkt-Vision. Diese Vision legt den Grundstein für die Entwicklung und gibt die Richtung vor, in die sich das Produkt bewegen soll. Aus dieser Vision lassen sich Key-Value-Indicators (KVIs) ableiten, die messbare Erfolge definieren. Diese KVIs werden wiederum in spezifische Qualitätsziele heruntergebrochen, die das Produkt erreichen muss, um den gewünschten Mehrwert zu liefern.

Hier kommt die Softwarearchitektur ins Spiel. Die Architektur muss diese Qualitätsziele aktiv unterstützen. Sie muss sicherstellen, dass das Produkt nicht nur funktional ist, sondern auch robust, skalierbar, wartbar und performant – je nachdem, welche Qualitätsziele priorisiert wurden.

Die Rolle des Product Owners

Der Product Owner spielt in diesem Prozess eine entscheidende Rolle. Er ist verantwortlich für die Definition der Produkt-Vision, die Festlegung der KVIs und spielt eine wichtige Rolle beim Herunterbrechen dieser Indikatoren in klare Qualitätsziele. Damit hat der PO einen erheblichen Einfluss auf die Architekturentscheidungen, denn die Architektur muss so gestaltet sein, dass sie diese Ziele unterstützt und ermöglicht.

Wenn der Product Owner diese Verantwortung nicht wahrnimmt, besteht die Gefahr, dass Architekturentscheidungen auf Basis persönlicher Vorlieben der Entwickler oder aktuellen Technologietrends getroffen werden. Solche Entscheidungen mögen kurzfristig attraktiv erscheinen, führen aber oft dazu, dass die Architektur nicht optimal auf die langfristigen Produktziele ausgerichtet ist.

Architekturarbeit: Eine gemeinsame Verantwortung im Team

Scrum definiert keine explizite Rolle für einen Architekten. Es legt auch nicht fest, wie Architekturarbeit geplant und ausgeführt werden sollte. Stattdessen liegt die Verantwortung für die Architekturarbeit bei den Entwicklern und ist ein integraler Bestandteil der Sprint-Arbeit.

Diese Art der Verantwortung bedeutet, dass Architekturarbeit nicht isoliert von der restlichen Entwicklung stattfindet, sondern in die tägliche Arbeit des Teams integriert ist. Jeder im Team muss sich der Bedeutung der Architektur bewusst sein und verstehen, wie sie die Erreichung der Produktziele unterstützt.

Architekturarbeit, die vernachlässigt wird, zeigt ihre Auswirkungen möglicherweise nicht sofort. Langfristig jedoch kann eine schwache oder unpassende Architektur zu erheblichen Problemen führen: mangelnde Skalierbarkeit, schwierige Wartbarkeit oder Performanceprobleme, die letztlich die Produktziele gefährden.

Langfristige Auswirkungen nicht vernachlässigen

Es ist verlockend, Architekturarbeit als nachrangig zu betrachten, besonders in einem hektischen Entwicklungsumfeld, in dem schnelle Ergebnisse gefragt sind. Doch die Qualität einer Architektur zeigt sich oft erst langfristig. Dabei muss jedoch auch berücksichtigt werden, dass für viele Architekturentscheidungen zu Beginn einer Produktentwicklung noch gar nicht alle wichtigen Informationen vorliegen. Deshalb kann es empfehlenswert sein, Architekturentscheidungen zunächst aufzuschieben und erst zum „Last Responsible Moment“ zu treffen. (http://www.poppendieck.com/pdfs/Predictability_Paradox.pdf - Seite 17)

Entwicklerteams müssen deshalb sicherstellen, dass Architekturarbeit regelmäßig und bewusst in den Entwicklungsprozess integriert wird. Dies kann durch regelmäßige Architektur-Reviews oder gezielte Diskussionen über technologische Entscheidungen und deren Auswirkungen auf die langfristigen Produktziele geschehen.

Fazit: Architektur ist Teamarbeit

Softwarearchitektur ist mehr als nur die Wahl der richtigen Technologien oder das Design eines Systems. Sie ist das Rückgrat, das die Produktziele unterstützt und sicherstellt, dass das Produkt langfristig erfolgreich ist. Architekturentscheidungen müssen über den gesamten Lebenszyklus des Produktes immer wieder getroffen und überprüft werden. Deshalb ist Architekturarbeit eine dauerhafte Aufgabe für das Scrum-Team, vor allem auch deshalb, weil sich die Produktziele über die Zeit verändern können. In agilen Teams, insbesondere in Scrum-Teams, ist Architekturarbeit eine Aufgabe für das gesamte Team und nicht nur für einen einzelnen Architekten.

Der Product Owner spielt eine zentrale Rolle, indem er die Produktziele klar definiert und gemeinsam mit den Entwicklern sicherstellt, dass die Architektur diese Ziele unterstützt. Nur durch enge Zusammenarbeit und ein gemeinsames Verständnis der Bedeutung der Architektur können Teams sicherstellen, dass ihre Produkte nicht nur heute, sondern auch in Zukunft erfolgreich sind.

Wenn auch du mehr darüber erfahren möchtest, wie Softwarearchitektur in einem agilen Kontext funktionieren kann, dann ist vielleicht unser Applying Professional Scrum Training das Richtige für dich. Hier kannst du bei öffentlichen Trainings von den Erfahrungen anderer Teilnehmer profitieren. Oder du buchst für dich und dein Team ein Inhouse-Training, bei dem ihr gemeinsam überlegt, wie ihr Architekturarbeit für euch neu definieren könnt. Mehr Infos unter https://www.agilemax.de/trainings/aps-sd.