Architekturverantwortung
Architekturverantwortung verteilt konkrete Aufgaben und Entscheidungsrechte auf Beteiligte. Klare Zuständigkeiten halten Entscheidungen wirksam und überprüfbar.
- Führende RolleEine Rolle trägt die Aufgabe.
- BeitragWas die Rolle konkret liefert.
- NachweisWoran man Erledigung prüft.
Einordnung
Warum das wichtig ist
Ohne klare Zuständigkeit bleiben Architekturfragen liegen oder werden doppelt entschieden. Eine Aufgabe ist erst dann überprüfbar, wenn eine führende Rolle und ein Nachweis feststehen. Den Inhalt einzelner Entscheidungen behandelt ein eigener Baustein.
Dieser Baustein erklärt Verantwortungen rund um Architekturarbeit. Für den Inhalt einer einzelnen Wahl siehe Architekturentscheidung.
Wer trägt was bei der Zahlungsintegration?
Bei der Zahlungsintegration des Shops arbeiten vier Rollen zusammen. Jede führt genau eine Station und arbeitet an anderen zu – wie bei einer Staffel.
So liest du das Bild
- Führende Rolle Das große Symbol über jeder Station, etwa das Plattformteam bei „Anbieter anbinden“.
- Beitrag Der Text unter der Station, etwa „Vertrag und Statusmodell“.
- Nachweis Der Stempel jeder Station, etwa „✓ Integrationstest“.
- FührtProduktverantwortliche
Zahlungsziel klären
fachliche Ergebnisse und Fehlerfälle
akzeptierte Szenarien
Wirkt mitModulverantwortliche Zahlung - FührtModulverantwortliche Zahlung
Schnittstelle entwerfen
Vertrag und Statusmodell
reviewter Entwurf
Wirkt mitProduktverantwortlichePlattformteam - FührtPlattformteam
Anbieter anbinden
Adapter und Zugang
Integrationstest
Wirkt mitModulverantwortliche Zahlung - FührtBetrieb
Betrieb prüfen
Metriken und Wiederanlauf
durchgeführte Übung
Wirkt mitPlattformteam
Nutzen & Grenzen
Hilft, wenn
- Mehrere Teams bleiben bei einer Entscheidung über Zuständigkeiten oder Folgen uneinig.
- Fachbereich, Entwicklung und Betrieb müssen gemeinsam an einer prägenden Entwurfsfrage arbeiten.
Grenzen
- Führen heißt nicht allein arbeiten; betroffene Teams und Fachexperten wirken mit, und Architekturentscheidungen halten ihre Beiträge nachvollziehbar fest.
- Eine Freigabe für jede Änderung wird zum Engpass; tragfähiger sind lokale Entscheidungsräume und Eskalation nur bei Wirkung über Teamgrenzen.
- Eine Rolle klärt die Zuständigkeit, ersetzt aber nicht den Grund; dafür dienen Architecture Decision Records.
In der Praxis
- Betroffene und ihre Perspektiven benennen. Bestimme, wer Regeln kennt, Entscheidungen trägt und Folgen umsetzt. Das Ergebnis klärt, welche Beiträge vor einer Wahl erforderlich sind.
- Befugnis und Eskalation klären. Benenne, wer innerhalb des Teamspielraums entscheidet, welche Fragen mehrere Verantwortliche gemeinsam klären und wohin ungelöste Konflikte eskalieren. Für eine langfristig prägende Wahl kann ein Architecture Decision Record die Gründe ergänzend festhalten.
- Umsetzung und Rückmeldung sichern. Ordne jede Vereinbarung einem verantwortlichen Team zu und lege fest, wie Abweichungen oder neue Erkenntnisse zurückgemeldet werden. So bleibt die Verantwortlichkeit in der Umsetzung wirksam; Architekturentscheidungen beschreiben die getroffene Wahl.
- Prüfe Teamübergaben am Shop. Verfolge eine neue Lieferoption von der fachlichen Idee bis zum Betrieb. Benenne notwendige Abstimmungen, Entscheidungsbefugnisse und fehlendes Wissen; nutze Team Topologies, um die Zusammenarbeit des verantwortlichen Teams gezielt zu prüfen.
Ausführliche Erklärung lesen
Architekturfragen können Fachregeln, technische Umsetzung, Sicherheit und Betrieb zugleich berühren. Eine verantwortliche Rolle führt diese Perspektiven zusammen, macht Konflikte entscheidbar und verfolgt relevante Folgen. Beratung liefert Wissen; Entscheidungsbefugnis bestimmt, wer den Beschluss herbeiführt. Architekturentscheidungen halten die eigentliche Wahl fest; Architecture Decision Records machen Kontext und Folgen später nachvollziehbar.
Verantwortung muss nicht in einer einzelnen zentralen Person liegen. Teams können lokale Entscheidungen selbst treffen, während übergreifende Rollen Leitplanken und Eskalationswege sichern. Der Umfang folgt der Tragweite: Gemeinsame Schnittstellen und Qualitätsziele brauchen Abstimmung; interne Detailentscheidungen gehören zu den Teams, die sie umsetzen und betreiben.
Conway’s Law beschreibt einen Zusammenhang zwischen Kommunikationswegen einer Organisation und den von ihr entworfenen Systemstrukturen. Teamzuschnitt und Bausteingrenzen sollten deshalb gemeinsam betrachtet werden.
Der Architect Elevator von Gregor Hohpe verbindet Geschäftsziele mit technischen Entscheidungen. Im Shop erklärt das Team etwa, wie eigenständige Änderungen am Versand kürzere Lieferoptionen ermöglichen und welchen Betriebsaufwand sie verursachen. Team Topologies ergänzt die Perspektive auf Teamverantwortung, Zusammenarbeit und kognitive Last: Wie viel Systemwissen muss ein Team für seine Aufgabe gleichzeitig beherrschen?
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wer führt die Station „Betrieb prüfen“, und welcher Nachweis gehört dazu?
Lösung mit Begründung ansehen
Der Betrieb, mit Metriken und Wiederanlauf als Beitrag. Der Nachweis ist die durchgeführte Übung; das Plattformteam wirkt mit.
AnwendenAuf eine neue Lage übertragen
Beim Zahlungsanbieter fehlt ein Zugang für den Integrationstest. An wen wendest du dich?
Lösung mit Begründung ansehen
An das Plattformteam. Es führt „Anbieter anbinden“ und liefert Adapter und Zugang; sein Nachweis ist der Integrationstest.
BewertenEine Alternative abwägen
Soll das Plattformteam auch das Statusmodell der Zahlung entwerfen, damit alles aus einer Hand kommt?
Lösung mit Begründung ansehen
Das spart Abstimmung. Es nimmt aber den Modulverantwortlichen Zahlung die Aufgabe, die Vertrag und Statusmodell führen; das Plattformteam wirkt dort bereits mit. Die Trennung hält den Review des Entwurfs unabhängig von der Anbieteranbindung.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Martin Fowler · Who Needs an Architect? (öffnet in neuem Tab)Diskutiert wesentliche Entscheidungen und die unterstützende Rolle von Architekten.
- Martin Fowler · The Architect Elevator (öffnet in neuem Tab)Verbindet technische Architekturentscheidungen mit organisatorischen Zielen.
- arc42 · Einführung und Ziele (öffnet in neuem Tab)Geschäftsziele, Stakeholder und priorisierte Qualitätsziele als Ausgangspunkt.
- Gregor Hohpe · The Software Architect Elevator (öffnet in neuem Tab)Verbindet Geschäftsstrategie, organisatorische Perspektiven und technische Entscheidungen.
- Team Topologies · Key Concepts (öffnet in neuem Tab)Wertstromorientierte Teams, Zusammenarbeit und kognitive Last als Perspektiven auf Teamzuschnitt.