Jeder kann Architekt sein!

TL;DR

• Rolle: Ein:e Architekt:in ist nicht „Chef:in der Technik“, sondern begleitet das Team und hilft, Entscheidungen bewusst zu treffen.
• Annahmen: Viele Zweifel kommen aus alten Bildern von Hierarchie („oben entscheidet, unten macht“). Diese Grundannahmen zu hinterfragen erweitert den Handlungsspielraum.
• Beteiligung: Entscheidungen werden eher verstanden und umgesetzt, wenn Betroffene mitreden können und die Ziele klar sind.
• Prozess: Gute Architekturentscheidungen brauchen einen einfachen Ablauf: relevante Personen benennen, Problem und Ziele klären, Optionen sammeln, Optionen prüfen (bei Bedarf mit kleinem Test), dann entscheiden.
• ADRs: Architecture Decision Records halten fest, was entschieden wurde und warum. Das verhindert Wissensverlust und hilft besonders, wenn Teams wechseln oder mehrere Teams beteiligt sind.

Als man mich erstmals fragte, ob ich die Rolle des Architekten in einem Projekt übernehmen wolle, hatte ich viele Zweifel. Nicht wegen fehlenden Architekturwissens, sondern wegen einiger offenen Fragen:

Wie stehe ich als Architekt zum Team? Bin ich übergeordnet? Treffe ich alle wichtigen Entscheidungen selbst? Wie kommuniziere ich Entscheidungen ins Team? Wie bekomme ich Akzeptanz für diese Entscheidungen?

Eine Weiterbildung in Facilitation half mir, Antworten zu finden – und die Rolle auf Augenhöhe zu gestalten. Ich möchte hier meine persönliche Lernreise teilen – mit all jenen, die sich heute ähnliche Fragen stellen wie ich mir damals.

Meine hier geschilderten Gedanken und Erfahrungen verstehen sich als Denkanstoß, nicht als allgemeingültiges Modell. Entscheidet selbst, welche Ideen für euch in eurem organisatorischen Kontext umsetzbar sind.

Traditionelles, hierarchisches Verständnis von Führung

Als ich erstmals mit der Architektenrolle konfrontiert war, weckte sie in mir traditionelle Vorstellungen von Führung. Ich dachte an Hierarchie und klare Machtverhältnisse. Unser Verständnis von Führung hat sich über Jahrhunderte entwickelt. Es bildet eine eigene umfangreiche Fachdisziplin, die den Rahmen dieses Artikels sprengen würde. Deshalb betrachte ich nicht einzelne Strömungen im Detail. Stattdessen skizziere ich eine historische Linie, die viele Menschen geprägt hat. Auch mich selbst, bis mir das bewusst wurde. Gerade weil diese Prägungen oft unbewusst bleiben, wirken sie stark und entziehen sich der Kritik.

Militär, Schule, Bürokratie und Frühindustrialisierung formten lange ein autoritäres Führungsbild. Führung bedeutete: oben entscheiden, unten ausführen. Die Führungskraft gibt vor, was zu tun ist. Das Team folgt. Kommunikation verläuft von oben nach unten. Mitarbeitende erhalten nur die Informationen, die sie für ihre Aufgabe brauchen. Der strategische Kontext fehlt. Auch die Begründung für Entscheidungen bleibt oft aus. Diese Informationsknappheit ist kein Zufall. Sie stabilisiert die hierarchische Macht. Wer wenig weiß, stellt weniger Fragen.

Ein weiteres Merkmal dieses Führungsstils ist strenge Kontrolle. Prozesse und Ergebnisse stehen unter dauernder Beobachtung. Bei der Verantwortung entsteht ein Paradox. Die autoritäre Führungskraft beansprucht Verantwortung für Entscheidungen und Ergebnisse. Scheitert das Vorhaben, verschiebt sich die Deutung. Plötzlich gilt nicht die Entscheidung als falsch, sondern ihre Umsetzung durch das Team. Diese Dynamik erzeugt Angst und fördert Risikovermeidung. „Dienst nach Vorschrift“ wird so zu einem rationalen Selbstschutz der Mitarbeitenden.

Vor- und Nachteile des autoritären Führungsstils

Hätte der autoritäre Führungsstil nur Nachteile, hätte er sich kaum durchgesetzt. Seine Stärken liegen in Schnelligkeit, Kontrolle und klaren Regeln. In Bereichen wie der Fertigung oder bei Rettungsdiensten sind sie entscheidend. Dort sind Abweichungen von bewährten Abläufen ineffizient oder gefährlich. Diese Aspekte werden jedoch in der Wissensökonomie zum Problem. Hier entsteht Wert durch Innovation, Zusammenarbeit und Anpassungsfähigkeit. Dafür taugt ein autoritärer Führungsstil kaum. Denn er führt dazu, dass Mitarbeiter und Mitarbeiterinnen Verantwortung meiden. Sie halten sich lieber strikt an Vorgaben. Kreativität und Kompetenzen bleiben ungenutzt.

Auf Seiten der Geführten entsteht das Gefühl geringer Wertschätzung. Eigeninitiative wird gebremst. Selbstständigkeit und Eigenverantwortung entwickeln sich kaum. Auf Seiten der Führungskraft wächst der Druck. Alles läuft bei ihr zusammen. Das erzeugt Stress und Überforderung. Hinzu kommt ein strukturelles Problem: Mitarbeiter kennen die Details ihrer täglichen Arbeit meist besser als ihre Vorgesetzten. Wer trotzdem alles vorgeben will, verhindert gute Ergebnisse. Und überfordert sich selbst.

Falsche Grundannahmen über die Architekten-Rolle

Ich glaube, den autoritären Führungsstil haben wir in der Softwareentwicklung weitgehend hinter uns gelassen. Kaum ein Entwickler oder eine Entwicklerin möchte heute unter solchen Bedingungen arbeiten. Alle Versuche ein Entwicklungsteam autoritär und hierarchisch zu führen, die ich miterleben musste, fand ich nicht überzeugend und kontraproduktiv.

Trotzdem prägt dieses Führungsbild noch unsere Erwartungen. Wenn wir spontan an einen Vorgesetzten denken, taucht oft das alte Muster auf. So ging es mir, als ich erstmals ein Entwicklungsteam als Architekt begleiten sollte. Verstärkt wurde dieses Bild durch die Vorstellung des Elfenbeinturm-Architekten: weit oben in der Hierarchie, allein entscheidend.

Dieses Negativbild ist in vielen Köpfen präsent. Es prägt, wie wir die Architektenrolle wahrnehmen. Auch ich fühlte mich anfangs unwohl. Ich glaubte, nun Architekturvorgaben machen zu müssen. In einem Team aus sehr kompetenten Entwickler:innen erzeugt diese Annahme enormen Druck. Ich fragte mich, ob ich mir anmaßen darf, technische Vorgaben zu machen. Und ob ich damit im Team Anerkennung finden würde. Trotzdem habe ich mich auf die Rolle eingelassen. Ich vertraute darauf, im Projekt zu lernen, wann und wobei das Team wirklich einen Architekten braucht.

Die Erkenntnisse aus diesem Lernprozess bilden den Kern dieses Textes.

Über die Bedeutung von Grundannahmen

Meine Annahme, ich müsse als Architekt alles wissen und klare Vorgaben machen, hat mich selbst eingeschränkt. Deshalb möchte ich über die Bedeutung von Grundannahmen für die Rolle des Facilitators sprechen.

Grundannahmen sind Glaubenssätze basierend auf früheren Erfahrungen. Sie prägen unsere Wahrnehmung stark. Oft wirken sie unbewusst – und genau deshalb sind sie mächtig. Hätte ich meine Annahmen nicht hinterfragt, hätte ich die Architektenrolle abgelehnt. Ich hätte sie als Überforderung erlebt. Erst der Gedanke, dass diese Annahme falsch sein könnte, gab mir den Mut, der Rolle eine Chance zu geben.

Grundannahmen beeinflussen, wie wir Realität deuten und wie wir uns in Gruppen verhalten. Sie können unseren Handlungsspielraum erweitern oder einengen. Ob eine Grundannahme „wahr“ ist, ist dabei zweitrangig bzw. die Diskussion darüber hilft uns nicht. Entscheidend ist eine andere Frage:

Was ermöglicht sie mir?

Wenn ich feststelle, dass ich Grundannahmen habe, die hinderlich für meine Arbeit sind, kann ich mich bewusst damit auseinandersetzen und überlegen, welche Grundannahmen für eine gegebene Situation hilfreicher sind. Durch die Veränderung von Grundannahmen kann sehr viel Bewegung (in mir oder einer Gruppe) entstehen. Sich in einem Team darüber klar zu werden, auf welchen Grundannahmen die gemeinsame Arbeit beruht, kann die Zusammenarbeit erheblich verbessern.

Wer noch mehr über Grundannahmen lesen möchte, kann das hier tun.

Im Folgenden beschreibe ich die Grundannahmen, die sich für mich in der Architektenrolle bewährt haben und mein Handeln leiten:

• Architekturentscheidungen werden gelebt, wenn die Betroffenen an der Entscheidung beteiligt waren und ihre Ziele verstehen. Deshalb werden sie gemeinsam vom Team und möglichst im Konsens getroffen.
• Entwickler und Entwicklerinnen bringen meist eine hohe intrinsische Motivation mit. Sie wollen gute Software bauen und schätzen es, wenn man ihre Kompetenz ernst nimmt.
• Eine falsche Entscheidung ist besser als keine. Bewusste Entscheidungen senken das Risiko schlechter Entscheidungen. In diesem Zusammenhang verweise ich auf Gregors’s Law.
• Unter Zeitdruck fehlt oft der Abstand für grundlegende Architekturfragen. Als Architekt erkenne ich diese Situationen und schaffe Raum für Entscheidungen.
• Langfristige Ergebnisse lassen sich schwer vorhersagen. Die Qualität des Entscheidungsprozesses lässt sich aber bewerten. Dafür braucht es eine klare, verständliche Struktur. Diese Struktur zu etablieren ist meine Aufgabe als Architekt.
• Ich weiß nicht alles besser als mein Team. Deshalb sorge ich dafür, dass die passende Fachexpertise beteiligt ist und gehört wird.
• Softwareentwicklung ist Co-Creation. Alle tragen Verantwortung für die Produktqualität. Jede Perspektive zählt und verdient Beachtung.

Wie ich meine Rolle als Architekt sehe

Aus obigen Grundannahmen leite ich mein Rollenverständnis als Architekt ab:

Ich verstehe mich als Begleiter des Entwicklungsteams, nicht als hierarchisch übergeordnete Person. Meine Aufgabe ist es, das Team dabei zu unterstützen, bewusste Architekturentscheidungen zu treffen. Diese Entscheidungen sollen die funktionalen und qualitativen Ziele des Projekts erreichen helfen. Ich achte darauf, dass fehlende Architekturentscheidungen das Projekt nicht blockieren – auch dann, wenn sie außerhalb meines direkten Verantwortungsbereichs liegen. Ebenso verhindere ich, dass sich eine Architektur unbewusst verfestigt, nur weil Entscheidungen ausbleiben. Als Architekt etabliere ich im Team eine Kultur bewusster Architekturentscheidungen. Das Ziel ist, dass das Team diese Entscheidungen auch ohne meine Anwesenheit treffen kann. Ich trage Verantwortung dafür, dass das Team fokussiert und sinnvoll arbeiten kann – und so die Projektziele erreichen kann.

Wie setze ich diese Rolle um?

In der Facilitation hat der Gastgeber bzw. die Gastgeberin eine Schlüsselrolle. Kurz gesagt: Als Facilitator schaffe ich den Rahmen für einen Kommunikationsprozess – und halte ihn. Ich halte das auch als Architekt für meine Aufgabe. Als Gastgeber übernehme ich Verantwortung für gute Architekturentscheidungen. Ich sorge dafür, dass Verantwortliche, Betroffene und Experten und Expertinnen miteinander sprechen und gemeinsam entscheiden können. Dafür gestalte ich den Rahmen. Ich kläre zuerst: Wer muss mit wem worüber sprechen? Dann lade ich diese Personen ein. Ich formuliere ein klares Ziel und setze eine Agenda. So bringe ich Entscheidungen voran – ohne Druck. Schon die Einladung, das Ziel und der Rahmen erzeugen Bewegung. Ich ebne allen Beteiligten den Weg zur Entscheidung. Diese Gastgeberrolle übernehme ich nicht nur für mein eigenes Team. Ich tue es immer dann, wenn mein Team eine Entscheidung braucht. Manchmal heißt das auch: Ich bringe mehrere Teams zusammen, etwa bei systemübergreifenden Architekturentscheidungen. Den inhaltlichen Rahmen richte ich an der Anatomie einer guten Architekturentscheidung aus. Sie beschreibt die Bausteine einer Entscheidung und ihre sinnvolle Reihenfolge. Im Folgenden erläutere ich diese Bestandteile.

Die Anatomie einer guten Architekturentscheidung

1. Stakeholder benennen

Bevor ich mich mit Technik befasse, kläre ich folgende Fragen:

• Wen betrifft die Architekturentscheidung?
• Welche technischen oder fachlichen Experten und Expertinnen brauche ich für eine fundierte Beratung?

Diese Personen benenne ich ausdrücklich als Stakeholder der anstehenden Entscheidung. Dazu zählen oft auch Personen in der Organisation, die hierarchisch über mir stehen. Sie sollen die Entscheidung mittragen und im Zweifel Verantwortung übernehmen. Wie stark ich einzelne Stakeholder einbeziehe, hängt von Organisation und Auftrag ab. Doch eines gilt immer: Für jede benannte Person überlege ich bewusst, wie und wann ich sie in den Entscheidungsprozess einbinde.

2. Problem definieren und Kontext beschreiben

Erst wenn ich die Stakeholder kenne, befasse ich mich mit dem Inhalt der Entscheidung. Zunächst kläre ich gemeinsam mit allen Beteiligten, welches Problem wir lösen wollen. Präzision ist hier entscheidend. Sie deckt Missverständnisse früh auf. Die Problemdefinition beschreibt den technischen und organisatorischen Kontext der Architekturentscheidung. Sie macht Rahmenbedingungen und Herausforderungen sichtbar. Alle Beteiligten sollen verstehen, welche funktionalen und Qualitätsziele die Entscheidung erfüllen muss. Aus den Zielen leite ich die Kriterien ab, die eine gute Lösungsoption erfüllen muss. Die Kriterien benenne ich explizit. Die können mir später bei der Bewertung der Lösungsoptionen als Checkliste dienen. Über diese Problemdefinition erzielen wir einen Konsens. Sie bildet die Grundlage für den weiteren Entscheidungsprozess.

3. Erforschung des Lösungsraums

In dieser Phase erkunde ich den Lösungsraum zusammen mit den Stakeholdern in voller Breite. Wir sammeln konkrete Lösungsoptionen, benennen sie und beschreiben sie so weit, dass klar wird: Wie kann diese Option die Ziele erreichen? Dabei lernen wir viel über die Sichtweisen der Beteiligten auf das Problem. Das hilft doppelt: Stakeholder können ihre Perspektive früh einbringen – und sie spüren, dass sie ernst genommen werden. Wichtig ist: Wir legen uns nicht zu früh auf eine Idee fest. Wir gehen auch nicht sofort ins Detail. Sonst verlieren wir leicht Alternativen aus dem Blick, die eine bessere Lösung wären. Erst wenn keine neuen Optionen mehr auftauchen, wechseln wir die Ebene: Dann gehen wir in die Tiefe und bewerten die Optionen.

4. Untersuchung und Bewertung der Lösungsoptionen

Sobald wir die Lösungsoptionen überblicken, beginnen wir mit der Bewertung. Wir bewerten, inwieweit eine Lösungsoption unsere Kriterien für eine geeignete Lösung erfüllt. Zusätzlich sammeln wir die positiven und negativen Aspekte dieser Lösungsoption. Bei den negativen Aspekten prüfen wir, ob es Maßnahmen gibt, die sie mindern oder ganz beseitigen können. Daraus entstehen manchmal neue Lösungsoptionen. Manche Lösungsoptionen werfen viele Fragen auf, die auf den ersten Blick nicht leicht zu beantworten sind. Dann lohnt es sich, diese Option genauer zu erforschen und zu prüfen. Ein geeignetes Mittel kann die Implementierung eines Proof of Concept sein. Er testet Annahmen und schafft Klarheit. Der Aufwand muss dabei zur Bedeutung der Entscheidung passen.

5. Entscheidung treffen und dokumentieren

Es gibt keine feste Formel für gute Entscheidungen. Meine Erfahrung zeigt aber: Wer Lösungsoptionen offen und strukturiert prüft, erkennt im Verlauf oft eine geeignete Lösung. Die Gründe dafür werden klar – und damit auch die Basis der Entscheidung. Entscheidend ist die Dokumentation. Wir halten fest, welcher Aspekt der Lösungsoption den Ausschlag gegeben hat. So wird nachvollziehbar, warum wir uns für diese Option entschieden haben. Ebenso wichtig: Wir beschreiben die Konsequenzen der Entscheidung. Dazu gehören die gewünschten Effekte ebenso wie die Nachteile, die wir bewusst in Kauf nehmen. Beides ist Teil der Entscheidung. Eine so getroffene und dokumentierte Entscheidung lässt sich später überprüfen. Mit Abstand kann man sie bewerten – und daraus für künftige Entscheidungen lernen.

Über die Bedeutung von Architecture Decision Records

Architecture Decision Records (ADRs) sind ein zentrales Werkzeug für meine Arbeit als Architekt. In langlebigen Softwareprojekten geht Wissen verloren. Der Code bleibt. Das Warum verschwindet. Mit jedem Teamwechsel erodiert das Verständnis für frühere Architekturentscheidungen – wenn niemand gegensteuert. ADRs setzen genau hier an. Sie dokumentieren nicht den Zustand der Architektur, sondern den Weg dorthin. Sie halten fest, welche Entscheidung getroffen wurde, warum sie getroffen wurde und welche Alternativen es gab.

Michael Nygard stellte das Konzept 2007 in Release It! vor. Breitere Aufmerksamkeit erhielt es 2011 durch seinen Blogbeitrag Documenting Architecture Decisions. Die ursprüngliche Idee war klar: Ein ADR entsteht, nachdem eine Entscheidung gefallen ist – als Gedächtnis für spätere Teams.

Ich setze einen Schritt früher an. Wir verfassen einen ADR gemeinsam als Team im Rahmen einer Teambesprechung. Das Schreiben wird Teil der Sitzung. Der ADR folgt dabei der Anatomie einer guten Architekturentscheidung. So führen wir die Diskussion entlang eines klaren roten Fadens. Ein ADR ersetzt keinen Entscheidungsprozess. Er macht ihn sichtbar, nachvollziehbar und strukturiert.

Wie gehe ich bei Architekturentscheidungen größerer Reichweite vor?

Für alltägliche Architekturentscheidungen mit begrenzter Wirkung reicht ein gemeinsamer ADR im Team. Wir schreiben ihn im Meeting und entscheiden zügig. Anders ist es bei Entscheidungen mit größerer Tragweite. Sie betreffen andere Teams und wichtige Stakeholder. Gibt es dafür einen etablierten Prozess, nutze ich ihn. Gibt es keinen, ergreife ich die Initiative. Erkennt mein Team Klärungsbedarf für ein teamübergreifendes Vorgehen, stoße ich die Klärung an. Ich starte bewusst asynchron.

Zuerst erstelle ich – allein oder mit dem Team – einen ADR-Entwurf. Ich veröffentliche ihn im internen Wiki. Danach spreche ich gezielt Stakeholder und Experten und Expertinnen aus anderen Teams an, von denen ich fundiertes Feedback erwarte. Sie lesen den Entwurf, kommentieren ihn oder überarbeiten ihn direkt.

Nach der Diskussionsphase lade ich alle Beteiligten zu einer Abschlussbesprechung ein. Dort präsentiere ich den überarbeiteten ADR und zeige, wie das Feedback eingeflossen ist. Idealerweise erreichen wir einen Konsens und dokumentieren die Entscheidung. Kommt kein Konsens zustande, vereinbaren wir klare nächste Schritte. Das kann etwa ein Proof of Concept für eine konkrete Option sein. Er reduziert Unsicherheit und schafft Klarheit. Hier geht es mir um meine Rolle als Host der Architekturentscheidung. Deshalb beschreibe ich nicht alle denkbaren Szenarien. Entscheidend ist: Ich bleibe verantwortlich, bis eine Entscheidung steht. Meine Aufgabe ist es, den Entscheidungsprozess zu führen und voranzubringen.

Konkret übernehme ich Verantwortung dafür:

• den Prozess bei Bedarf zu starten
• einen sauberen und vollständigen Ablauf sicherzustellen
• alle relevanten Stakeholder einzubinden
• Blockaden früh zu erkennen und aufzulösen
• nächste Schritte klar zu definieren und verbindlich zu verantworten – notfalls selbst
• Transparenz zu schaffen, wo wir im Prozess stehen, damit jede:r weiß, was gerade erwartet wird
• aktiv zu prüfen, ob alle wesentlichen Aspekte betrachtet sind, und fehlende Perspektiven gezielt einzubringen
• Entscheidungen klar zu dokumentieren und die daraus entstehenden Aufgaben als Tickets im Backlog zu verankern

Übernehme ich Verantwortung über die Grenzen meines Teams hinweg, achte ich auf den organisatorischen Kontext. Trete ich jemandem auf die Füße, ist das kontraproduktiv. Meine Erfahrung zeigt jedoch: Initiative und sichtbarer Fortschritt kommen meist gut an. Gemeinsame Entscheidungen schaffen erprobte Verfahren. Wer einen konkreten Entscheidungsprozess gemeinsam durchläuft, legt die Basis für künftige Entscheidungen ähnlicher Größenordnung. Der Prozess funktioniert, weil er sich bewährt hat. Er stammt nicht vom Reißbrett, sondern aus der Praxis.

Wer Architekturentscheidungen in einer Organisation wirksam verankern will, sollte das Buch Facilitating Software Architecture von Andrew Harmel-Law lesen. In diesem Artikel schaue ich auf das Thema aus meiner Rolle als Architekt und auf die Spielräume, die ich dort habe. Das Buch wählt eine andere Perspektive: Es zeigt, wie Organisationen Architektur systematisch verankern können.

Ein Artikel aus dem Jahr 2026 – und kein Wort über KI?

Natürlich frage auch ich mich, wie Agentic Software Engineering die Architekturarbeit verändert. Diese Fragen kläre ich nicht nebenbei. Sie verdienen einen eigenen, gründlichen Blick. Ich werde sie in kommenden Artikeln aufgreifen. Eines bleibt für mich zentral: Bewusste Entscheidungen. Daran halte ich fest. Auch im Zeitalter von Agentic Software Engineering – vielleicht dort mehr denn je.

Weitere Literatur-Empfehlungen für alle, die tiefer einsteigen wollen

• Gregor Hohpe diskutiert unterschiedliche Modelle, Architektur-Entscheidungen in der Organisation zu verankern, in diesem Artikel hier.
• Ein sehr gutes Buch über Facilitation allgemein, das vieles enthält, das ich in meiner Weiterbildung gelernt habe, ist dieses hier
• Gerade schon erwähnt, gehört aber trotzdem in die Übersicht:Facilitating Software Architecture beleuchtet das Thema Software-Architektur-Facilitation aus organisatorischer Perspektive.