Die vielen Gesichter von Softwarearchitekten

Wer ist hier eigentlich Architekt?

In IT-Projekten weichen Rollendefinitionen gerne mal von dem ab, was in Lehrbüchern steht. Besonders kreativ wird es bei der Rolle des Softwarearchitekten. Fragt man zehn Projektleiter, was ein Softwarearchitekt tut, bekommt man zwölf verschiedene Antworten — zwei davon widersprüchlich.

Selbst der Begriff „Softwarearchitektur” ist in der Fachliteratur nicht einheitlich definiert. Trotzdem — oder gerade deshalb — ist die Rolle für den Projekterfolg entscheidend. Irgendjemand muss schließlich die großen Entscheidungen treffen. Oder zumindest so tun, als würde er sie treffen.

Dieser Beitrag ist der Auftakt einer kleinen Blogserie, in der wir uns dem Thema Softwarearchitektur von verschiedenen Seiten nähern. Den Anfang machen wir bewusst augenzwinkernd: mit einer Typologie der Architektenstereotypen, die uns in Projekten immer wieder begegnen. Aber Achtung — der Beitrag kann Spuren von Ironie enthalten.

Die sieben Gesichter

Der Powerpoint-Architekt

Für den Powerpoint-Architekten bestehen Softwaresysteme aus Kästen und Pfeilen. Alles andere? Lästige Implementierungsdetails, mit denen sich andere herumschlagen dürfen. Sein natürlicher Lebensraum ist der Besprechungsraum mit Beamer, seine Waffe der Wahl die Folienpräsentation mit strategisch platzierten Wolken-Symbolen.

Oft wurde er von agilen Teams „nach oben wegbefördert” — eine elegante Lösung für alle Beteiligten. Jetzt zeichnet er seine PowerPoints eben auf einer höheren Abstraktionsebene. Die Kästen sind größer geworden, die Pfeile dicker, und das Wort „Microservices” taucht auf jeder zweiten Folie auf. Den Quellcode hat er zuletzt gesehen, als Git noch Subversion hieß.

Der Elfenbeinturm-Architekt

Ein naher Verwandter des Powerpoint-Architekten, aber mit akademischem Unterbau. Der Elfenbeinturm-Architekt verfügt über tiefgehendes theoretisches Wissen — und eine ebenso tiefgehende Ignoranz gegenüber den tatsächlichen Bedürfnissen der Entwicklungsteams.

Er liebt Gremien, Architektur-Boards und Review-Komitees, in denen Teams ihre Entwürfe zur Genehmigung vorlegen müssen. Sein Lieblingssatz beginnt mit „Aus architektonischer Sicht…” und endet selten mit etwas, das dem Team weiterhilft. Er ist der natürliche Feind agiler Teams — und wundert sich aufrichtig, warum die Leute im Daily Standup die Augen verdrehen, wenn sein Name fällt.

Der Chronisten-Architekt

Der Chronisten-Architekt ist der Hüter der Dokumentation. Einer Dokumentation, die es in Umfang und Bedeutung locker mit der Bibliothek von Alexandria aufnehmen kann — und die ungefähr genauso häufig gelesen wird.

Sein Credo: Was nicht dokumentiert ist, existiert nicht. Und was nicht existiert, kann definitiv nicht funktionieren. Idealerweise werden Architektur und Dokumentation in mehrstufigen Gremien abgenommen, wobei jede Änderung einen eigenen Change-Request-Prozess durchläuft. Dass das Feature inzwischen seit drei Sprints in Produktion läuft, ist dabei höchstens ein unangenehmes Detail.

Der Podcast-Architekt

Der Podcast-Architekt hört jeden Architektur- und Technologie-Podcast auf dem Markt. In mehr als einer Sprache. Er kennt die neuesten Trends, bevor sie Trends sind, und hat zu jedem Thema eine Meinung — idealerweise die, die Stefan Tilkov letzte Woche im Podcast vertreten hat.

Er predigt die neuesten Technologien und Methoden mit einer Begeisterung, die ansteckend sein kann — oder erschöpfend, je nachdem, wen man fragt. Die Wahrnehmung im Team schwankt wild: Die einen lieben seinen Input und die frischen Impulse. Die anderen wollen einfach nur das Projekt fertig bekommen und fragen sich, ob man wirklich jetzt noch auf Event Sourcing umstellen muss.

Der Prototypen-Architekt

Das natürliche Gegenstück zum Powerpoint-Architekten. Für den Prototypen-Architekten lebt Architektur im Code — und nur im Code. Neue Patterns und Konzepte werden nicht in Folien vorgestellt, sondern als funktionierende Prototypen direkt im Repository präsentiert. Pull Request statt PowerPoint.

Entwicklungsteams lieben ihn, denn er spricht ihre Sprache und liefert Dinge, die man anfassen kann. Alle anderen — Projektleiter, Stakeholder, das Management — wünschen sich manchmal ein klitzekleines bisschen mehr Dokumentation. Oder wenigstens ein Architekturdiagramm, das man in den Statusbericht einbauen kann.

Der U-Boot-Architekt

Sein natürlicher Lebensraum ist der Besprechungsraum. Dort taucht er in unregelmäßigen Abständen auf, platziert mit chirurgischer Präzision eine Frage oder einen Review-Kommentar, der geeignet ist, jede getroffene Entscheidung in Frage zu stellen — und verschwindet dann wieder in den Tiefen des Organigramms.

„Hat das Architektur-Board das abgenommen?” „Haben wir die nicht-funktionalen Anforderungen validiert?” „Ist das kompatibel mit unserer Zielarchitektur 2027?” Die Fragen sind meistens berechtigt. Das Timing ist es nie. Er torpediert keine Entscheidungen aus Böswilligkeit, sondern aus einem tief empfundenen Pflichtgefühl — was es für das Team aber auch nicht angenehmer macht.

Der basisdemokratische Architekt

Für den basisdemokratischen Architekten entsteht Architektur ausschließlich evolutionär aus der Diskussion im Team. Vorab-Entscheidungen sind zu vermeiden, zentrale Vorgaben werden als persönlicher Affront aufgefasst. Jedes Team soll seine eigene Lösung finden — schließlich kennt niemand die Anforderungen besser als das Team selbst.

Das klingt in der Theorie wunderbar agil. In der Praxis hat der basisdemokratische Architekt immer ein lokales Optimum im Blick — aber selten das große Ganze. Wenn dann fünf Teams fünf verschiedene Authentifizierungslösungen gebaut haben, war das eben der Preis der Autonomie. Aber hey, jede einzelne ist perfekt auf ihren Kontext zugeschnitten.

Die Stereotypen auf einen Blick

Fazit und Ausblick

Alle sieben Typen begegnen uns regelmäßig in Projekten — manchmal in Reinform, häufiger als Mischform. Jeder einzelne Stereotyp hat seine Berechtigung und seine blinden Flecken. Die spannende Frage ist: Wie viel von jedem Typ braucht ein Projekt?

Ein Beispiel aus der Praxis: Bei einem großen Kunden wurde uns mitgeteilt, dass neue Architekten drei bis sechs Monate Einarbeitungszeit einplanen sollten — allein um die Dokumentationsanforderungen und Gremienstrukturen zu verinnerlichen. Ein klassischer Fall des Chronisten-Architekten in Reinkultur, gewürzt mit einer Prise Elfenbeinturm.

Was lernen wir aus dieser Darstellung? Sie zeigt, wie vielfältig und widersprüchlich die Anforderungen an eine Softwarearchitektin oder einen Softwarearchitekten sind. Von tiefem technischem Verständnis über Kommunikationsstärke bis hin zu strategischem Denken — die Bandbreite ist enorm.

Man darf durchaus die Frage stellen, ob es sinnvoll ist, so viele unterschiedliche Aufgaben und Erwartungen auf eine einzige Rolle zu projizieren. Aber das ist ein Thema für einen eigenen Beitrag.

Im nächsten Teil dieser Serie nähern wir uns dem Thema von der anderen Seite: Was bedeutet Softwarearchitektur eigentlich — ganz ohne Ironie? Wir versprechen nichts, aber wir geben uns Mühe.