BLOG
In agilen Projekten taucht immer wieder die Frage auf: Braucht ein Scrum-Team einen Software-Architekten – oder reicht die kollektive Verantwortung der Entwickler:innen? Während Scrum die klassischen Rollen bewusst reduziert, bleibt die Architekturarbeit ein zentraler Erfolgsfaktor für jede Softwareentwicklung. Entscheidungen zu Systemstrukturen, Qualitätsanforderungen und technischer Konsistenz beeinflussen unmittelbar, ob ein Produkt langfristig stabil, skalierbar und wartbar bleibt. Doch wer übernimmt diese Verantwortung im Scrum-Team? In diesem Artikel beleuchten wir die Rolle des Software-Architekten in Scrum, klären typische Aufgabenfelder und zeigen, wie Architekturarbeit auch ohne dedizierte Architektenrolle gelingen kann.
Bei TechTalk sehen wir Software als Werkzeug, das in den Händen von Menschen und Teams das Potenzial hat, wahre Veränderungen zu bewirken.
Wir bringen nicht nur mehr als drei Jahrzehnte praktische Erfahrung in der Softwareentwicklung mit, sondern zeichnen uns auch durch unsere tiefe Verwurzelung in agilen Methoden und unsere ganzheitliche Projektumsetzung aus. Dabei verstehen wir uns nicht nur als Berater, sondern als Partner auf Augenhöhe für unsere Kund:innen, mit denen wir echte Wirkung in der Zusammenarbeit erzielen. Auf dieser Grundlage haben wir unsere Tipps zusammengestellt.
Die Anatomie und Entscheidungsräume von Scrum-Teams unterscheiden sich in jeder Organisation sehr stark. Beispielsweise können Teams eine hohe Autonomie bei der Auswahl ihrer technischen Bausteine haben oder sehr standardisiert sein. Sie unterscheiden sich jedoch auch stark in den Rollen im Team.
Üblicherweise findet man in jedem Scrum-Team eine der folgenden Rollen:
Gernot Starke liefert uns in seinem Buch „Effektive Softwarearchitekturen – Ein praktischer Leitfaden“ eine sehr gute Visualisierung zu den Aufgaben und Tätigkeiten eines Software-Architekten:
Je nach Setup innerhalb der Organisation dreht sich oft der Aspekt „Entscheiden“ hin zu „Entscheidung herbeiführen“. Dies hängt davon ab wieviel Kompetenz und Freiheitsgrade die Teams haben. Auch bei einem dezidierten Software Architekten kann die Erarbeitung von Strukturen oder Querschnittlichen Konzepten an erfahrene Teammitglieder weitergegeben werden. Um die Entscheidungen herbeizuführen, nimmt man als Architekt oft die Rolle eines Facilitators an. In dieser Art und weise verrichten oft Agile Coaches oder Scrum Masters auch Architekturarbeit.
Die Aufgaben sind essenziell für den kurzfristigen sowie langfristigen Erfolg eines Projekts. Was versteckt sich hinter diesen Tätigkeiten in der Praxis?
Oft werden diese Aufgaben und Tätigkeiten der Rolle des Product Owners und Business Analysts zugeschrieben. Weshalb ist hier der Blickwinkel eines Architekten notwendig? Neben den rein fachlichen Anforderungen – „Was soll das System können?“ – gibt es noch Qualitätsanforderungen – „Wie soll das System sein?“. Diese sind für die Auswahl der technischen Strukturen relevanter als die reinen fachlichen Anforderungen.
Beispielsweise unterscheiden sich Plattformen, auf denen Benutzer Lernvideos bereitstellen können, sehr stark. Sind die Zielgruppe nur wenige Schüler, ein ganzer Universitätsjahrgang oder Online-On-Demand-Kurse? Je nach Antwort sind die Nutzungsarten, die Ansprüche an Verfügbarkeit, Skalierbarkeit und Accessibility verschieden stark ausgeprägt. Diese Antworten beeinflussen das System mehr als die Anforderung, dass Videos On-Demand für einen Benutzerkreis zur Verfügung stehen.
Für diese Art der Anforderungen arbeiten Architekten üblicherweise mit Qualitätsszenarien, die anhand eines Qualitätsmodells wie der ISO/IEC 25010 oder der Q42 mit den Stakeholdern erarbeitet werden.
Aufbauend auf den Anforderungen ist es die Aufgabe des Architekten, das technische System zu entwerfen. Meistens sind Techniker zu wenig in den Anforderungen involviert und wählen daher trendbasiert einen Lösungsansatz und versteifen sich auf „gute Technik“. Leider sind das oft nicht die besten Entscheidungen für die gegebene Aufgabenstellung. Dies führt mittelfristig häufig zu Frust und Gräben zwischen Business und IT.
Stattdessen geht es jedoch darum, den fachlichen Anforderungen, den Qualitätskriterien und den organisatorischen Gegebenheiten entsprechende Strukturen zu entwerfen, um das System zu bauen.
Hierunter fällt üblicherweise das Aufteilen des zu bauenden Systems in seine Bausteine und die Zuweisung an Teams oder externe Partner für den Bau dieser. Übliche Fragen für den Strukturentwurf sind:
Diese Entscheidungen beeinflussen beispielsweise, ob man Monolithen, modulare Monolithen, Microservices oder andere Architekturstile wählt. Schnittstellen in den Systemen ergeben sich auch implizit aus diesen Entscheidungen.
Ein weiterer wichtiger Aspekt ist die konsistente Lösung von querschnittlichen Konzepten wie Logging, Accessibility und Security über mehrere Bausteine und Teams hinweg. Dies erfordert eine enge Abstimmung mit dem Umsetzungsteam und üblicherweise eine gute Dokumentation.
Make-or-Buy-Entscheidungen sind ebenfalls oft ein kritisches Thema. Möchte man sich von einem Vendor abhängig machen und dessen Lizenzkosten zahlen? Setzt man auf ein Open-Source-Framework, das jedoch nur von zwei Personen gewartet wird, oder schreibt man diesen Teil selbst? Entscheidet man sich für den Zukauf, ist auch noch offen, welchen Anbieter man wählt. Hier spielen oft viele Faktoren mit, die sehr schnell in Vergessenheit geraten. Zwei Jahre später erinnert man sich in einem geänderten Marktumfeld selten daran, weshalb man auf Technologie A statt B gesetzt hat.
In vielen Situationen ist es auch notwendig, erste Erfahrungen mit den Technologien zu machen mit Spikes oder Proof of Concepts. Diese können auch fehlschlagen und sind, so wie verworfene Lösungsansätze, oft wertvoll. Sie helfen uns dabei zu lernen, zu entscheiden, und die Grenzen der Architektur zu definieren.
Ein oft unterschätzter Aspekt der Architekturarbeit ist das Definieren von Out-of-Scope-Bereichen und Nicht-Zielen. Gerade aus technischen Constraints oder der Auswahl bestimmter Lösungsansätze ergeben sich klare Grenzen, was das System leisten oder nicht leisten kann. Hier schließt sich wieder der Kreis zu den zuvor definierten Qualitätskriterien.
Da diese Technischen Konzepte nicht nur im stillen Kämmerlein entworfen werden, sondern auch an Stakeholder und Entwicklugnsteams kommuniziert gehören, werfen wir nun eine Blick auf den Bereich wie man Architektur kommuniziert.
Übernimmt man Architekturaufgaben, findet man sich oft in der Rolle des Vermittlers. Die fachlichen Aufgaben und Rahmenbedingungen prägen den technischen Lösungsraum. Ebenso haben die technischen Gegebenheiten und die Vision, wohin sich das Softwaresystem entwickeln soll, Einfluss auf die Lösung fachlicher Aufgabenstellungen. Hier kann es auf Seiten der Umsetzungsteams oder des Businesses oft zu Missverständnissen kommen. Es ist essenziell, jemanden zu haben, der hier gut vermitteln kann und die Trade-offs für beide Seiten transparent darstellt.
Architekturentscheidungen betreffen oft mehrere Entwickler in der Umsetzung und andere Entwickler in der Wartung. Sie begleiten einen über den ganzen Lebenszyklus der Software. Kurzfristig möchte man hier sein Wissen multiplizieren und den Entwicklern die Ressourcen zur selbstständigen Arbeit geben. Hierfür benötigt es eine gute Kombination aus schriftlicher und mündlicher Kommunikation. Langfristig möchte man die wichtigsten Elemente der Architektur in einer guten Dokumentation schnell zur Verfügung haben. Einerseits, um neuen Personen den Einstieg zu erleichtern, andererseits, um die wachsende Komplexität der Systeme beherrschbar zu machen. Ohne langfristige schriftliche und visuelle Dokumentation sind Systeme oft zu groß für unsere Köpfe, und die Entscheidungsfähigkeit sowie die Qualität der Entscheidungen nimmt ab.
Übliche Werkzeuge des Architekten:
Die oben beschriebenen Tätigkeiten sind für den kurz- sowie langfristigen Projekterfolg entscheidend. Doch wer übernimmt diese Aufgaben im Team?
In der Praxis werden diese Tätigkeiten häufig von Lead Developern, Tech Leads oder Senior Developern übernommen. Aber auch Scrum Master, Agile Coaches oder Engineering Manager unterstützen aktiv bei der Klärung von Anforderungen, dem Entwurf technischer Konzepte, der Kommunikation der Architektur und der Begleitung der Umsetzung.
Braucht es dafür zwingend eine explizite Rolle des Software-Architekten? Nicht unbedingt – entscheidend ist, dass die genannten Aufgaben und Verantwortlichkeiten tatsächlich wahrgenommen werden. Ein Scrum-Team, das diese Kompetenzen integriert und lebt, kann flexibel und nachhaltig arbeiten, ohne dabei die langfristigen technischen und fachlichen Ziele aus den Augen zu verlieren.
Oft werden diese Erwartungen jedoch nicht explizit formuliert und stattdessen implizit dem erfahrensten Teammitglied übertragen. Es ist daher hilfreich, die Erwartungshaltungen und die damit verbundenen Tätigkeiten sowie benötigten Kompetenzen transparent zu machen. Das schafft Klarheit in der Zusammenarbeit, reduziert Frustpotenzial und bietet auch berufliche Perspektiven. Für die Organisation kann die Rolle des Software-Architekten hilfreich sein, sie ist aber nicht zwingend notwendig. Für einen guten Projekterfolg ist die Verantwortung für die genannten Aufgaben jedoch unerlässlich.
Für alle, die sich in Richtung Architekturarbeit entwickeln möchten – egal ob Senior Developer, Scrum Master, Agile Coach oder bestehende Software-Architekten – ist es wichtig die Fähigkeiten und Kompetenzen in diesem Bereich auf ein solides Fundament zu stellen.
Eine gute Möglichkeit, diese Fähigkeiten zu entwickeln, ist die Zertifizierung im iSAQB Foundation Level. Darüber hinaus können Bücher wie Effektive Softwarearchitekturen von Gernot Starke oder Building Evolutionary Architectures von Neal Ford wertvolle Einblicke bieten.
Ob ein Scrum-Team eine explizite Rolle „Software-Architekt“ benötigt, hängt stark von der Organisation und den vorhandenen Kompetenzen ab. Unverzichtbar sind jedoch die beschriebenen Aufgaben der Architekturarbeit – von der Klärung von Qualitätsanforderungen über die Entwicklung technischer Konzepte bis hin zur Dokumentation und Kommunikation.
Teams, die diese Aufgaben aktiv übernehmen – egal ob durch einen dedizierten Architekten oder verteilt auf mehrere Rollen – legen die Grundlage für nachhaltige, skalierbare und wartbare Software. Scrum bietet den Rahmen, in dem diese Verantwortung gemeinsam getragen werden kann. Die Kernbotschaft: Nicht die Rolle ist entscheidend, sondern dass Architekturarbeit sichtbar, bewusst und kontinuierlich geschieht.
Im Software Architecture Foundation Training den Grundstein legen.
„*“ zeigt erforderliche Felder an
