Benötigt ein Scrum-Team eine Software-Architekten-Rolle?

In agilen Projekten stellt sich immer wieder die Frage: Benötigt ein Scrum-Team eine*n Software-Architekt*in – oder reicht die kollektive Verantwortung der Entwickler*innen?
Scrum reduziert klassische Rollen bewusst auf ein Minimum. Dennoch bleibt Architekturarbeit ein zentraler Erfolgsfaktor: Systemstruktur, Qualität und technologische Konsistenz entscheiden, ob Software langfristig skalierbar, wartbar und stabil bleibt.
Doch wer trägt diese Verantwortung im agilen Umfeld?

Rollen mit Architekturverantwortung in Scrum-Teams

Je nach Organisation unterscheiden sich Gestaltungsspielräume bei technischen Entscheidungen stark. Manche Teams genießen hohe technische Autonomie, andere arbeiten nach strikten Standards. Typischerweise übernehmen folgende Rollen Architekturaufgaben:

  • Software-Architekt*in

  • Tech Lead

  • Lead Developer

  • Senior Developer

Auch Scrum Master oder Agile Coaches übernehmen in agilen Organisationen oft moderierende Architekturaufgaben.

Aufgaben und Verantwortlichkeiten eines Software-Architekten

Eine Visualisierung aus „Effektive Softwarearchitekturen – Ein praktischer Leitfaden“ von Gernot Starke zeigt anschaulich, welche Tätigkeiten zur Architekturarbeit gehören.

Je nach Organisation verschiebt sich der Schwerpunkt von „Entscheiden“ zu „Entscheidungen herbeiführen“ – abhängig von den Freiheitsgraden der Teams.
Selbst bei einer dedizierten Architekt*innenrolle können Aufgaben wie Strukturarbeit oder Querschnittskonzepte an erfahrene Entwickler*innen delegiert werden.

Oft übernehmen Scrum Master oder Agile Coaches unterstützende Architekturaufgaben, indem sie Entscheidungsprozesse moderieren und technische Diskussionen begleiten.
Diese Tätigkeiten sind entscheidend für den kurz- und langfristigen Projekterfolg – sie sorgen für Klarheit, Qualität und technische Konsistenz im Team.


1. Anforderungen und Qualitätsattribute klären

Neben den funktionalen Anforderungen („Was soll das System tun?“) sind Qualitätsanforderungen („Wie soll das System sein?“) entscheidend für den langfristigen Erfolg einer Software.
Eine Architekt*in übersetzt diese Anforderungen in konkrete Qualitätsziele – etwa in Bezug auf Skalierbarkeit, Performance, Sicherheit oder Benutzerfreundlichkeit.

Beispiel:
Ein Online-Lernsystem für eine kleine Schulklasse stellt andere Anforderungen an Skalierbarkeit und Verfügbarkeit als eine Plattform, auf der tausende Nutzer:innen gleichzeitig lernen.
Um solche Unterschiede greifbar zu machen, werden Qualitätsszenarien definiert – also messbare Situationen, die beschreiben, wie sich das System unter bestimmten Bedingungen verhalten soll.

Beispiel für ein Qualitätsszenario:

  • Hintergrund: Ein*e Benutzer*in möchte sich einfach und schnell für einen Kurs registrieren.

  • Stimulus: Die Person startet die Registrierung.

  • Reaktion: Der gesamte Prozess (inkl. Dateneingabe und Zahlung) ist innerhalb von 5 Minuten abgeschlossen.

  • Metrik: 90 % aller Registrierungen werden innerhalb dieser Zeit erfolgreich durchgeführt.

Solche Szenarien helfen, Erwartungen zu konkretisieren und messbar zu machen.
Gleichzeitig werden dadurch auch Nicht-Ziele sichtbar – also Bereiche, die bewusst nicht priorisiert werden. Diese Klarheit vermeidet Missverständnisse im Team, reduziert das Risiko von Gold-Plating (unnötiger Übererfüllung) und unterstützt das gemeinsame Verständnis, wann eine Lösung „gut genug“ ist.

2. Technische Konzepte und Architekturentscheidungen treffen

Auf Basis der Anforderungen werden Strukturentscheidungen getroffen:

  • Welche Module bilden das System?

  • Welche Teams sind für welche Komponenten verantwortlich?

  • Welche Teile werden selbst entwickelt oder eingekauft (Make or Buy)?

Solche Entscheidungen beeinflussen, ob ein Monolith, modularer Monolith oder Microservice-Ansatz gewählt wird.
Wichtig: Entscheidungen dokumentieren – etwa über Architectural Decision Records (ADRs, kurze Text-Dokumente, die Entscheidungen festhalten) – um Transparenz und Nachvollziehbarkeit zu sichern.

Eine freigestellt Glühbirne, die Erklärungen zu komplexen Themenstellungen im IT-Bereich gibt
Eine freigestellt Glühbirne, die Erklärungen zu komplexen Themenstellungen im IT-Bereich gibt
Einfach erklärt

Was ist ein modularer Monolith?

Ein modularer Monolith ist eine Gesamtanwendung, die in Module gegliedert ist – für mehr Struktur, Wartbarkeit und Flexibilität in der Entwicklung.

3. Architektur kommunizieren und dokumentieren

Architekturarbeit bedeutet Vermittlung: zwischen Business und IT, zwischen Vision und Realität.
Effektive Kommunikation reduziert Missverständnisse und stärkt die Zusammenarbeit.

Hilfreiche Werkzeuge:

  • Template-basierte Schnittstellendokumentationen
  • Architectural Decision Records (ADRs)
  • C4-Diagramme, ein visuelles Modellierungsframework für Softwarearchitekturen
  • Arc42, ein Template für nachhaltige Architekturdokumentation
Foundation Level (CPSA-F)

Starte deine Ausbildung zum zertifizierten Software-Architekten!

Erlerne die Grundlagen moderner Softwarearchitektur – praxisnah, agil und mit offiziellem iSAQB-Zertifikat.

Zum Training

Fazit: Architekturarbeit ist Teamarbeit

Eine eigene Architekt:innenrolle ist im Scrum-Team nicht zwingend erforderlich.
Wichtig ist, dass Architekturaufgaben bewusst und kontinuierlich wahrgenommen werden – unabhängig davon, wer sie übernimmt.
Oft teilen sich Tech Leads, Senior Developers, Scrum Master oder Agile Coaches diese Verantwortung und sorgen gemeinsam für Struktur, Qualität und technische Konsistenz.

👉 Tipp aus der Praxis:
Legt im Team klar fest, wer welche Architekturverantwortung trägt, und macht Erwartungen transparent.
Das schafft Klarheit, vermeidet Frust und stärkt langfristig die technische Qualität.
Scrum bietet den idealen Rahmen, um Architekturarbeit als gemeinsame Aufgabe zu leben.
So entstehen nachhaltige, skalierbare und wartbare Systeme – egal ob mit oder ohne formale Architekt*innenrolle.