Wer entscheidet eigentlich über Architektur?
Warum Unternehmen nicht nur Architekturprinzipien, sondern eine Entscheidungsarchitektur brauchen
"Rumour-driven development" – so beschrieb Spotify selbst eine unerwartete Folge seiner Engineering-Kultur. Wer wissen wollte, wie bestimmte technische Dinge im Unternehmen funktionieren, musste im Zweifel einen Kollegen fragen. Denn Spotify hatte seine Entwicklungsorganisation über viele Jahre bewusst auf weitgehend selbstständig arbeitende Teams ausgerichtet.Diese konnten schnell handeln und viele technische Entscheidungen selbst treffen. Teams entwickelten unterschiedliche Werkzeuge, Services und Vorgehensweisen [1]. Auch Entscheidungen, die für ein einzelnes Team sinnvoll erscheinen, können in ihrer Summe unerwünschte Folgen für die Gesamtorganisation haben. Wer sollte also entscheiden, wenn die Auswirkungen einer Architekturentscheidung über das eigene Team hinausreichen?
Warum sollen Teams überhaupt selbst entscheiden?
Architekturentscheidungen sollten möglichst dort getroffen werden, wo das notwendige Wissen vorhanden ist. Das Detailwissen über ein System liegt in der Regel bei dem Team, das täglich daran arbeitet. Es kennt frühere Entscheidungen, technische Schulden und anstehende Veränderungen.
Dieser Kontext lässt sich nur begrenzt an eine zentrale Architekturorganisation übertragen. Kann ein Team innerhalb seines Verantwortungsbereichs selbst entscheiden, entfallen zusätzliche Abstimmungen, Freigaben oder das Warten auf das nächste Architekturboard. Lokale Entscheidungsrechte können somit einen Geschwindigkeitsvorteil schaffen. Je weiter Entscheidungen dagegen vom jeweiligen System entfernt getroffen werden, desto mehr Kontext muss vermittelt werden und desto mehr Koordination wird notwendig.
Das Prinzip klar abgegrenzter Verantwortungsbereiche findet sich auch in Ansätzen wie Bounded Contexts, Self-contained Systems und Microservices. Je unabhängiger ein Team seinen Teil des Systems verändern kann, desto weniger Entscheidungen muss es mit anderen Teams koordinieren.
Auch die Menge an Wissen, die für eine Entscheidung berücksichtigt werden kann, setzt der Zentralisierung Grenzen. Kein zentraler Architekt kann den fachlichen und technischen Kontext beliebig vieler Systeme im Detail kennen. Cognitive Load wird insbesondere im Zusammenhang mit der Gestaltung von Teams als begrenzender Faktor diskutiert [2].
Ähnliche Grenzen gelten auch für eine zentrale Architekturorganisation.
Ein weiterer Vorteil lokaler Architekturentscheidungen liegt in der Verantwortung für ihre Folgen. Ein Team, das ein System über längere Zeit entwickelt und betreibt, muss auch mit den Konsequenzen seiner Entscheidungen umgehen. Entscheidungsfreiheit kann deswegen Ownership stärken. Umgekehrt wäre es widersprüchlich, einem Team die langfristige Verantwortung für ein System zu übertragen, ihm aber die dafür notwendigen Entscheidungsrechte weitgehend zu entziehen.
Wann ist eine Architekturentscheidung nicht mehr lokal?
Vieles spricht dafür, Architekturentscheidungen möglichst im Team zu treffen – oder allgemein dort, wo das relevante Wissen vorhanden ist und die Konsequenzen getragen werden. Diese Regel setzt jedoch voraus, dass die Folgen einer Entscheidung tatsächlich lokal bleiben und sich nicht auf andere Bereiche auswirken.
So könnte ein Team für einen neuen Service selbst ein geeignetes Datenbanksystem auswählen. Treffen viele Teams solche Entscheidungen unabhängig voneinander, kann die wachsende Technologievielfalt jedoch die Betriebs- und Wartungskosten für die gesamte Organisation erhöhen. Unterschiedliche Technologien müssen beherrscht, überwacht und unterstützt werden. Was für ein einzelnes Team eine gute Wahl ist, kann dadurch Kosten verursachen, die dieses Team selbst nicht vollständig trägt.
Ein weiteres Beispiel ist die Entscheidung über ein gemeinsames Design System. Für ein einzelnes Team kann es sinnvoll erscheinen, eigene UI-Komponenten oder ein anderes Framework einzusetzen. Über mehrere Anwendungen hinweg können solche Entscheidungen jedoch zu einer inkonsistenten User Experience führen. Die technische Entscheidung eines Teams hat damit Auswirkungen, die erst auf Ebene des gesamten Produktportfolios sichtbar werden.
Den genannten Beispielen ist gemeinsam, dass die Auswirkungen einer Entscheidung über den Verantwortungsbereich des entscheidenden Teams hinausreichen können. Manche Architekturentscheidungen betreffen tatsächlich nur ein Team. Andere schaffen Abhängigkeiten zu weiteren Teams, gemeinsam genutzten Plattformen oder externen Kunden und Partnern. Technische und organisatorische Grenzen stimmen nicht immer überein. Abhängige Teams können in unterschiedlichen Teilen einer Organisation arbeiten oder sogar zu verschiedenen Unternehmen gehören. Sobald die Auswirkungen einer Architekturentscheidung über den eigenen Verantwortungsbereich hinausreichen, kann ein Team nicht mehr allein aus seiner lokalen Perspektive entscheiden. Andere Interessen und Konsequenzen müssen berücksichtigt werden.
Warum Architekturprinzipien das Entscheidungsproblem nicht lösen
Eine naheliegende Reaktion auf diese Herausforderung sind gemeinsame Architekturprinzipien und Standards. Sie geben Teams Orientierung und setzen Grenzen für autonome Entscheidungen. Ein Technologiestandard kann beispielsweise verhindern, dass für jeden neuen Service ein weiteres Datenbanksystem eingeführt wird.
Das grundsätzliche Entscheidungsproblem lösen solche Vorgaben jedoch nicht, da Architekturprinzipien miteinander in Konflikt geraten oder in einer konkreten Situation unterschiedlich ausgelegt werden können. Auch ein Standard kann nicht jeden Anwendungsfall abdecken.
So kann die Verwendung einer etablierten Technologie aus Sicht des Unternehmens Betriebsaufwand und Komplexität reduzieren. Für einen neuen Anwendungsfall könnte eine andere Technologie jedoch erhebliche Vorteile bieten. Dann reicht der Verweis auf Standardisierung nicht mehr aus. Es muss entschieden werden, welches Ziel in diesem Fall schwerer wiegt und ob eine Abweichung vom Standard gerechtfertigt ist.
Innerhalb klarer Leitplanken können Teams grundsätzlich selbstständig entscheiden. Es muss aber geklärt werden, wer diese Leitplanken festlegt, wer über Ausnahmen entscheidet und wann sie angepasst werden können. Bei Zielkonflikten oder wenn bestehende Vorgaben nicht ausreichen, muss deshalb geklärt sein, wer entscheiden darf. Kurzum: Unternehmen brauchen nicht nur eine gute Architektur und gute Prinzipien, sondern eine Struktur für die Entscheidungen darüber.
Architektur folgt auch der Organisation
Eine technisch überschaubare Entscheidung kann organisatorisch schwierig werden, sobald mehrere Teams betroffen sind. Das Spektrum solcher Entscheidungen ist breit. Es reicht von der Erweiterung einer gemeinsam genutzten Schnittstelle bis zur Auswahl einer SaaS-Lösung, an die sich mehrere Bereiche für Jahre binden. Schon eine zusätzliche API kann Auswirkungen darauf haben, welche Funktionen eine andere Anwendung anbieten kann und wie sich die Rollen der beteiligten Produkte verändern. Bei einer gemeinsam genutzten SaaS-Lösung kommen langfristige Kosten und unterschiedliche Anforderungen mehrerer Bereiche hinzu.
Keines der Teams kann dann allein entscheiden, ohne die anderen zu beeinflussen. Mit solchen Abhängigkeiten wächst der Koordinationsbedarf. Dabei kommt es nicht nur darauf an, wie viele Teams beteiligt sind. Entscheidend ist auch, wie Verantwortung und Entscheidungsrechte zwischen ihnen verteilt sind. Sind diese nicht klar, müssen Entscheidungen ausgehandelt oder an eine übergeordnete Stelle eskaliert werden. Dass Organisationsstrukturen technische Architekturen prägen, ist spätestens seit Conway [3] keine neue Erkenntnis [4]. Die Organisationsstruktur beeinflusst aber auch, wer an Architekturentscheidungen beteiligt ist, wer entscheiden darf und welcher Koordinationsaufwand damit verbunden ist.
Wer sollte entscheiden?
Ein Team kennt sein System und dessen fachlichen Kontext im Detail. Es weiß aber nicht unbedingt, welche strategischen Entscheidungen an anderer Stelle getroffen wurden, welche parallelen Initiativen laufen oder welche Priorität das eigene Vorhaben aus Sicht der Gesamtorganisation hat. Eine zentrale Instanz hat eher die organisationsweite Perspektive, ist dafür aber weiter vom konkreten System entfernt. Pauschal wichtige Architekturentscheidungen möglichst weit oben in der Organisation zu treffen, löst deswegen das Koordinationsproblem nur scheinbar.
Häufig werden für übergreifende Architekturentscheidungen Architecture Boards eingesetzt. Sie bündeln Expertise, können Auswirkungen über einzelne Teams hinaus betrachten und für Konsistenz sorgen. Je mehr Entscheidungen dort zusammenlaufen, desto eher können jedoch neue Probleme entstehen. Die Mitglieder eines Boards arbeiten häufig nicht täglich mit den betroffenen Systemen. Der notwendige Kontext muss erst vermittelt werden, Entscheidungen benötigen zusätzliche Abstimmung und das Board kann selbst zum Engpass werden.
Zudem sind die Mitglieder des Boards in der Regel nicht diejenigen, die das betroffene System anschließend weiterentwickeln und betreiben. Fehlt ein Feedback Loop, erfährt das Board möglicherweise nicht, wie sich eine Entscheidung in der Praxis bewährt hat. Wer über Jahre für ein System und dessen Erfolg verantwortlich ist, bewertet Risiken und Kompromisse unter Umständen anders als ein Gremium, das sich mit einer Entscheidung nur vorübergehend beschäftigt.
Das spricht nicht grundsätzlich gegen Architecture Boards. Bei Entscheidungen mit großer Tragweite kann eine übergreifende Instanz notwendig sein. Aber nicht jede Entscheidung, die mehrere Teams betrifft, muss deshalb auf einer höheren Hierarchieebene getroffen werden. Sind beispielsweise fünf Teams betroffen, müssen diese möglicherweise an der Entscheidung beteiligt werden. Das bedeutet aber noch nicht, dass ein Enterprise Architect oder ein VP entscheiden muss. Anders sieht es etwa bei einer Plattformentscheidung aus, die mehrere Bereiche langfristig bindet und hohe Kosten verursacht. Darüber kann ein einzelnes Team nicht allein entscheiden.
Wer muss an einer Entscheidung beteiligt sein?
Für die Beteiligung an einer Architekturentscheidung sind vier Aspekte relevant:
1. Wissen: Wer über das notwendige fachliche und technische Wissen verfügt, muss in die Entscheidung einbezogen werden.
2. Betroffenheit: Sind andere Systeme oder Verantwortungsbereiche wesentlich betroffen, müssen deren Interessen berücksichtigt werden.
3. Entscheidungsbefugnis: Strategische Vorgaben, Standards oder die Verteilung von Ressourcen können die Entscheidungsfreiheit eines Teams begrenzen. Überschreitet eine Entscheidung dessen Befugnisse, muss die zuständige Stelle einbezogen werden.
4. Verantwortung: Wer eine Lösung langfristig entwickelt und betreibt, trägt auch die Folgen der Entscheidung und sollte deshalb daran beteiligt sein.
Bei lokalen Architekturentscheidungen liegen diese vier Aspekte häufig beim selben Team. Bei übergreifenden Entscheidungen verteilen sie sich dagegen oft auf mehrere Stellen. Ein Team kann beispielsweise das größte technische Wissen besitzen und das System langfristig verantworten. Andere Teams sind von der Entscheidung betroffen, während über eine Abweichung von einem unternehmensweiten Standard an anderer Stelle entschieden wird. In solchen Fällen muss geklärt sein, wer beteiligt wird und wer am Ende entscheidet.
Tabelle 1: Typische Formen der Abstimmung bei Architekturentscheidungen
| Situation | Typische Konstellation | Abstimmung |
|---|---|---|
| lokal entscheiden | Wissen, Auswirkungen, Befugnis und Verantwortung liegen weitgehend im Team. | Das Team entscheidet selbst. |
| konsultieren | Andere verfügen über relevantes Wissen oder sind von der Entscheidung betroffen. | Das Team bezieht sie vor der Entscheidung ein. |
| gemeinsam abstimmen | Mehrere Verantwortungsbereiche sind wesentlich betroffen. | Die Beteiligten stimmen die Entscheidung gemeinsam ab. |
| übergreifend entscheiden | Die Entscheidung überschreitet die Befugnisse der Beteiligten oder berührt übergeordnete Vorgaben. | Die zuständige übergreifende Stelle entscheidet oder bestätigt die Entscheidung. |
Ein Beispiel für einen solchen dezentralen Umgang mit Architekturentscheidungen ist der von Andrew Harmel-Law beschriebene "Advice Process". Entscheidungen können dort dezentral getroffen werden. Vor einer Entscheidung werden jedoch diejenigen konsultiert, die wesentlich davon betroffen sind oder über relevantes Wissen verfügen [5].
Beim Konsultieren ist nicht nur wichtig, wer beteiligt wird, sondern auch wann diese Beteiligung stattfindet. In der Praxis werden betroffene Teams mitunter erst einbezogen, wenn eine Entscheidung bereits weitgehend getroffen oder ihre Umsetzung fortgeschritten ist. Das kann Abstimmungen verkürzen und langwierige Diskussionen vermeiden, schränkt aber zugleich die Möglichkeit ein, die Entscheidung noch wesentlich zu beeinflussen. Je weiter eine Entscheidung bereits vorbereitet oder umgesetzt ist, desto höher werden zudem die Kosten einer Änderung. Eine Beteiligung erfüllt ihren Zweck deshalb nur, wenn sie früh genug erfolgt, um das Ergebnis tatsächlich noch beeinflussen zu können.
Gute Architektur beginnt mit guten Entscheidungen
Die zu Beginn erwähnten Herausforderungen bei Spotify sprechen nicht per se gegen autonome Teams. Viele Architekturentscheidungen sind bei den Teams, die die jeweiligen Systeme entwickeln und betreiben, gut aufgehoben. Sobald eine Entscheidung jedoch andere Verantwortungsbereiche betrifft, kann sie möglicherweise nicht mehr allein im Team getroffen werden. Unternehmen sollten deshalb klar regeln, was Teams selbst entscheiden können, wann andere beteiligt werden müssen und wann eine übergreifende Entscheidung notwendig ist. Gemeinsame Leitplanken geben dabei Orientierung, ohne jede Entscheidung zentral vorzugeben. Muss eine Entscheidung eskaliert werden, ist das kein Scheitern. Manche Entscheidungen können schlicht nicht von einem Team allein getroffen werden.
Wer entscheidet also über Architektur? Darauf gibt es keine allgemeine Antwort. Manche Entscheidungen kann ein Team selbst treffen, andere müssen mit mehreren Teams abgestimmt oder übergreifend getroffen werden. Dabei kommt es darauf an, wer das notwendige Wissen hat, wer betroffen ist, wer entscheiden darf und wer die Folgen trägt.
- Spotify Engineering. (2021). A product story: The lessons of Backstage and Spotify's autonomous culture. Spotify Engineering Blog. Abgerufen am 28. September 2026 von https://engineering.atspotify.com/2021/04/a-product-story-the-lessons-of-backstage-and-spotifys-autonomous-culture/
- Skelton, M. & Pais, M. (2019). Team Topologies: Organizing business and technology teams for fast flow. IT Revolution Press.
- Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31. Abgerufen am 28. September 2026 von https://www.melconway.com/Home/Committees_Paper.html
- Fowler, M. (2022). Conway's law. martinfowler.com. Abgerufen am 28. September 2026 von https://martinfowler.com/bliki/ConwaysLaw.html
- Harmel-Law, A. (2021). Scaling the practice of architecture, conversationally. martinfowler.com. Abgerufen am 28. September 2026 von https://martinfowler.com/articles/scaling-architecture-conversationally.html
