Die vielen Gesichter von Softwarearchitekten

Die Architekten der digitalen Welt: Eine nicht ganz ernst gemeinte Erkundung der Charaktere hinter den Software­architekturen

Einleitung

Bei der Besetzung von Rollen in IT-Projekten ist eine gewisse Findungsphase mit dem Auftraggeber nicht unüblich. Während viele Rollen im Lehrbuch (recht) eindeutig definiert sind, spricht die Praxis oftmals eine andere Sprache. Eine besonders komplexe Rolle hierbei ist die des Softwarearchitekten, bei welcher sich Anforderungen und Erwartungen von Organisation zu Organisation teils stark unterscheiden. Dies hat sicherlich auch damit zu tun, dass selbst der Begriff von Softwarearchitektur in der Literatur nicht einheitlich und erst recht nicht präzise definiert ist. Gleichzeitig trägt die Rolle aber wesentlich zum Erfolg von IT-Projekten bei. Grund genug für uns, den vielen Facetten von Softwarearchitektur eine kleine Blogserie zu widmen.

Einleiten wollen wir diese Blogserie mit einer nicht ganz ernst gemeinten Betrachtung verschiedener (Stereo-)Typen von Softwarearchitekten, wie sie die meisten Menschen, die sich im Kontext von IT-Projekten bewegen, wohl schon erlebt haben. Die durchaus sinnvollen Unterscheidungen zwischen Enterprise, Solution und Technical Architecture klammern wir an dieser Stelle erst einmal bewusst aus, da sich unserer Erfahrung nach untenstehende Typen auf eigentlich jedem Abstraktionslevel finden lassen. Aber Achtung – der Beitrag kann Spuren von Ironie enthalten. 

Der Powerpoint-Architekt

Für ihn bestehen Softwaresysteme aus Kästchen und Pfeilen. Alles andere sind doch auch nur lästige Implementierungsdetails. Wird von agilen Teams häufig nach oben weggelobt und zeichnet seine Powerpoints nun auf höherer Ebene.

Der Elfenbeinturm-Architekt

Durchaus verwandt mit dem Powerpoint-Architekten befindet sich der Elfenbeinturm-Architekt im… nun ja, in seinem persönlichen Elfenbeinturm. Oftmals zeichnen Elfenbeinturm-Architekten sich gleichzeitig durch ein tiefes, zumeist akademisch geprägtes Fachwissen auf der einen und eine komplette Ignoranz für die (Projekt-)Bedürfnisse der Entwicklungsteams auf der anderen Seite aus. Liebt Gremien, in welchen die Entwicklungsteams sich ihre Architekturen abnehmen lassen müssen. Oder es zumindest versuchen. Der natürliche Feind agiler Teams.

Der Chronisten-Architekt

Sieht sich als Wächter der Dokumentation, welche in ihrer Bedeutung der Bibliothek von Alexandria quasi in nichts nachsteht. Etwas, was nicht ausführlich dokumentiert ist, existiert für ihn nicht und kann auf gar keinen Fall funktionieren. Idealerweise wird die Architektur und ihre Dokumentation in mehrstufigen Gremien freigegeben. Im Gegensatz zum Elfenbeinturm-Architekten sieht der Chronisten-Architekt seine Rolle aber eher in der Vorbereitung und Dokumentation der Gremienarbeit.

Der Podcast-Architekt

Hört wirklich jeden Architektur – und Technologie-Podcast auf dem Markt. In mehr als einer Sprache. Der Podcast-Architekt predigt die neuesten Technologien und Methoden und versucht, jeden in seinem Umfeld davon zu überzeugen. Hält sich auch liebend gerne auf Konferenzen und Meetups auf. Seine Wahrnehmung in den Projektteams variiert stark – manche lieben ihn und seine Impulse, manche möchten doch einfach nur das Projekt zu Ende bringen.

Der Prototypen-Architekt

Dieser Architekten-Typus ist der natürliche Gegenpart zum Powerpoint-Architekten. Architektur findet für ihn direkt im Code statt, neue Pattern oder Ideen stellt er am liebsten als Prototyp direkt in seinem Repo zur Verfügung. Die Entwicklungsteams lieben ihn, auch wenn sein sonstiges Umfeld sich durchaus ein wenig mehr Dokumentation und Struktur wünschen würde.

Der U-Boot-Architekt

Nicht zu verwechseln mit dem Elfenbeinturm-Architekten, ist sein natürliches Wirkungs-Habitat der Besprechungsraum. Hier weiß er zu brillieren und durch die geschickte Platzierung von Fragen und Prüfaufträgen jede noch so kleine Entscheidung zielsicher zu torpedieren. Nur um dann wieder abzutauchen – bis zum nächsten Mal.

Der basisdemo­kra­tische Architekt

Architektur ergibt sich für ihn nur evolutionär aus der Diskussion im Team und hat sich dem Code unterzuordnen. Vorabentschei­dungen sind unbedingt zu vermeiden, zentrale Beschlüsse oder übergreifende Einschränkungen werden als persönlicher Affront aufgefasst. Auf diese Weise hat der basisdemokratische Architekt immer ein lokales Optimum fest im Blick – oftmals jedoch nicht das große Ganze. 

Uns selbst laufen eigentlich alle oben genannten Typen regelmäßig in Rein- oder Mischform in unseren Projekten über den Weg. Sehr gerne denke ich an einen großen Kunden zurück, bei dem der Auf­trag­geber selbst von 3-6 Monaten Onboarding ausge­gangen ist, um die komplexen Dokumentations- und Prozess­anforderungen an die Entwicklung der Software­architektur zu verinnerlichen. Ein typischer Fall von (in diesem Fall gewollten) Chronisten-Architekten. 

Aber was lernen wir nun aus den verschiedenen Typen von Softwarearchitekten? Auch wenn die Darstellung bewusst überspitzt war, verdeutlicht die Betrachtung sehr schön, mit welchen komplexen Anforderungen sich ein Softwarearchitekt konfrontiert sieht. Persönlich mag ich das Bild des Softwarearchitektur-Aufzuges von Gregor Hohpe, in welchem der Architekt sich vom Maschinen­raum im Keller (Technik, Programmiersprache, Design Pattern) bis zum Vorstands-Penthouse auf dem Dach (IT-Transformation, Organisationsentwicklung) bewegt. Auch wenn man durchaus hinterfragen kann, ob es sinnvoll ist, so viele Aufgaben und Anforderungen in eine einzige Rolle zu projizieren. Im nächsten Blogpost beschäftigen wir uns etwas ausführlicher damit, was Softwarearchitektur für uns eigentlich bedeutet – ganz ohne Ironie.

Die in diesem Artikel verwendeten Bilder wurden mit Hilfe von DALL·E 2, einer KI zur Bildgenerierung, erstellt.