Entwickler: Ich finde, wir sollten diese Komponente in zwei Teile zerlegen.

Diktator: Nein.

Entwickler: Aber warum denn nicht? Wir könnten besser testen und unsere Strukturen werden auch noch verständlicher!

Diktator: Das bleibt so. Ich will es so. Und jetzt geh’ programmieren.

Architator = Diktator mit (technischer) Entscheidungsgewalt

Wir alle kennen technische Diskussionen, bei denen die Beteiligten über eine konkrete technische oder konzeptionelle Fragestellung ihre jeweiligen Meinungen, Erfahrungen und Vorstellungen austauschen. Solche Argumentationen können sich über lange Zeit erstrecken, aber im guten Fall entscheidet ein kundiger und erfahrener Kopf dann, welchen Weg das Team in dieser Fragestellung einschlagen soll. Als wesentlicher Bestandteil gehört zu einer solchen Entscheidung die Transparenz, d. h. die Begründung, das Warum so und nicht anders?

Gute Softwarearchitekten wissen das und legen daher viel Wert auf solche offenen Argumentationen. Sie beziehen das Entwicklungsteam bei architektonisch wichtigen Fragestellungen ein (Vigenschow, Uwe; Schneider, Björn: "Softskills für Softwareentwickler", dpunkt Verlag 2007). Der Architektendiktator hingegen maximiert seine Unbeliebtheit, indem er grundsätzlich ohne Begründung Architekturentscheidung über die Köpfe des (in der Regel erfahrenen und sachkundigen) Entwicklungsteams hinweg trifft. Eben wie ein typischer Diktator.

Diktatoren brauchen Macht

Architektonische Diktatur in Softwareprojekten benötigt entsprechende Machtstrukturen: Projektleiter und/oder Auftraggeber müssen den Architator mit den Insignien dieser Macht ausgestattet haben, sonst ließen sich so getroffene Entscheidungen niemals durchsetzen. Aber so etwas soll ja in der Praxis schon vorgekommen sein (hoffentlich nicht bei Ihnen!).

Auch Architekten sind Menschen

Wir raten Ihnen, architekturrelevante Entscheidungen grundsätzlich gegenüber den betroffenen Stakeholdern zu begründen. Nehmen Sie die (Gegen-)Argumente Ihres Entwicklungsteams ernst. Überprüfen Sie vorgeschlagene Alternativen praktisch oder durch Prototypen, um Ihre Entscheidungen besser begründen zu können.

Auf der anderen Seite müssen Sie als Architekt nach Einholen von zusätzlichen Meinungen manchmal Entscheidungen treffen, die eher auf Bauchgefühl und Erfahrung beruhen, nicht formal begründbar sind und daher oft nicht von allen mitgetragen werden. Wir raten Ihnen jedoch strikt davon ab, Ihre formale Entscheidungsbefugnis ("Macht") als Softwarearchitekt zu oft gegen Ihr Team einzusetzen. Die Balance zwischen klaren Entscheidungen und Debattierzirkeln zu finden, ist schwierig, das wissen wir.