Was ein Architekt tut: Verantwortlichkeiten, Fähigkeiten und Arten von Architekten

Wozu es Architekten gibt

Wenn Architektur die Menge der bedeutenden Entscheidungen und Strukturen eines Systems ist (Abschnitt 1.1), dann ist Architekt, wer die Verantwortung dafür übernimmt, dass diese Entscheidungen gut getroffen, von anderen verstanden und bei Änderungen des Systems eingehalten werden. Das klingt einfach, doch die Rolle gehört zu den am uneinheitlichsten definierten in der Softwareentwicklung. In einem Unternehmen ist ein Architekt ein erfahrener Engineer, der noch täglich Code schreibt; in einem anderen ein Mitglied eines zentralen Teams, das Entwürfe prüft und Standards pflegt; in einem dritten jemand, der vor allem mit der Geschäftsleitung und mit Anbietern spricht.

Hinter der Vielfalt steht ein gemeinsamer Kern. Architekten treffen oder lenken Entscheidungen, die sich nur teuer umkehren lassen, kümmern sich um die Qualitäten des Gesamtsystems statt nur eines Teils und verbinden technische Entscheidungen mit Geschäftszielen. Der Rest dieses Abschnitts beschreibt, was dazugehört, welche Fähigkeiten es erfordert und wie die Rolle organisiert ist.

Acht Erwartungen an einen Architekten

Mark Richards und Neal Ford beschreiben in Fundamentals of Software Architecture (O'Reilly, 1. Auflage 2020, 2. Auflage 2025) acht zentrale Erwartungen an einen Architekten, unabhängig von Berufsbezeichnung oder Unternehmen. Sie sind unten sinngemäß wiedergegeben, jeweils mit einem Beispiel aus einem Essenslieferunternehmen.

Beachten Sie, wie wenige der acht rein technisch sind. Richards und Ford betonen, dass fast jede Entscheidung eines Architekten von jemandem infrage gestellt wird (Entwicklern, anderen Architekten, Product Ownern, Projektmanagern), sodass Verhandlungsgeschick und Überzeugungskraft Kernfähigkeiten sind, keine Extras. Eine Architektur, die auf dem Papier richtig ist, aber nicht verstanden oder akzeptiert wird, wird nicht wie beabsichtigt gebaut.

Die iSAQB-Sicht auf die Aufgaben von Architekten

Das International Software Architecture Qualification Board (iSAQB), dessen Foundation-Level-Lehrplan (CPSA-F) in Europa weit verbreitet ist, beschreibt die Aufgaben und Verantwortlichkeiten von Architekten ähnlich. Zusammengefasst: Architekten klären und hinterfragen Anforderungen und Randbedingungen; entscheiden, wie das System in Bausteine mit ihren Abhängigkeiten und Schnittstellen zerlegt wird; entscheiden über Querschnittsanliegen wie Persistenz, Kommunikation und Benutzeroberfläche; kommunizieren und dokumentieren die Architektur; begleiten ihre Realisierung und Umsetzung; analysieren und bewerten sie, besonders auf Risiken für die Erfüllung der Anforderungen; und erklären anderen Stakeholdern die Folgen von Architekturentscheidungen.

Der Lehrplan betont außerdem, dass diese Aufgaben iterativ sind: Architekten arbeiten in Zyklen und greifen Anforderungen und Entscheidungen erneut auf, wenn Rückmeldungen eintreffen, statt einmal zu entwerfen und dann zu übergeben. Abschnitt 1.8 zeigt, wie sich das in iterative und kontinuierliche Auslieferung einfügt.

Arten von Architekten

Die Bezeichnungen folgen den Ebenen der Architektur, die in Abschnitt 1.2 beschrieben sind. Die genauen Verantwortlichkeiten unterscheiden sich stark zwischen Organisationen; betrachten Sie die Tabelle unten daher als typisch, nicht als verbindlich.

Eine Rolle oder eine Berufsbezeichnung?

Architektur ist eine Reihe von Verantwortlichkeiten, bevor sie eine Berufsbezeichnung ist. In vielen Organisationen, besonders kleineren und solchen, die um autonome Produktteams herum organisiert sind, heißt niemand „Architekt“. Die Architekturarbeit wird trotzdem erledigt, von technischen Leads, erfahrenen Engineers oder dem Team gemeinsam. Entscheidend ist, dass jemand die bedeutenden Entscheidungen und die systemweiten Qualitäten klar verantwortet. Tut das niemand, entsteht trotzdem eine Architektur, aber zufällig.

Viele Technologieunternehmen haben eine technische Karriereleiter für erfahrene Fachkräfte ohne Führungsverantwortung, mit Stufen wie Staff Engineer und Principal Engineer. Will Larsons Staff Engineer (2021) beschreibt vier verbreitete Archetypen solcher Rollen, von denen einer ausdrücklich „Architect“ heißt: eine Person, die für Richtung und Qualität eines kritischen technischen Bereichs verantwortlich ist. Auch die anderen (Tech Lead, Solver und Right Hand) tragen erhebliche architektonische Verantwortung. In diesen Organisationen leisten Menschen die Arbeit des Architekten, die zugleich Engineers sind.

Martin Fowlers Artikel Who Needs an Architect? von 2003 stellt zwei Zerrbilder gegenüber: einen Architekten, der alle wichtigen Entscheidungen allein trifft, und einen, der eng mit dem Team arbeitet, Entwickler anleitet und ihnen hilft, selbst gute Entscheidungen zu treffen. Fowler sprach sich entschieden für den zweiten aus. Die meisten Fachleute sind sich heute einig, dass Architekten, die aus der Ferne Vorgaben machen, meist Entwürfe hervorbringen, die die Teams stillschweigend umgehen.

Technische Breite oder Tiefe

Entwickler werden meist für Tiefe belohnt: eine Sprache, ein Framework oder eine Plattform äußerst gut zu kennen. Architekten brauchen ein anderes Profil. Richards und Ford beschreiben eine Wissenspyramide mit drei Schichten: Dinge, die Sie wissen (wo Sie echtes Fachwissen haben), Dinge, von denen Sie wissen, dass Sie sie nicht wissen (Sie wissen, dass es sie gibt und ungefähr wofür sie gut sind, könnten aber heute nichts damit bauen), und Dinge, von denen Sie nicht wissen, dass Sie sie nicht wissen. Fachwissen in der obersten Schicht muss gepflegt werden, und das kostet Zeit. Die mittlere Schicht lässt sich günstig erweitern und ermöglicht es, Optionen zu erkennen.

Der Wert eines Architekten liegt großenteils in technischer Breite: zu wissen, dass es fünf Wege gibt, ein Problem zu lösen, wofür jeder gut und schlecht ist und welcher einen genaueren Blick verdient. Ein Architekt, der nur eine Datenbank kennt, wird sie jedes Mal empfehlen. Breite hat ihren Preis, denn Zeit, die man in die Verbreiterung der mittleren Schicht steckt, fehlt für die Vertiefung der obersten; Architekten lassen deshalb bewusst manches alte Fachwissen verblassen und investieren darin, über mehr Dinge Bescheid zu wissen. Richards und Ford warnen vor dem umgekehrten Fehler: dem Architekten, dessen Ansichten von einer schlechten Erfahrung vor Jahren geprägt wurden und der jede Option ablehnt, die ihr ähnelt.

Sollten Architekten Code schreiben?

Hier sind sich Fachleute wirklich uneinig, und der Streit ist nützlich, weil beide Seiten in einem Punkt recht haben.

Was für das Programmieren spricht. Architekten, die programmieren, verstehen die tatsächlichen Kosten ihrer Entscheidungen, merken, wenn ein Prinzip in der Praxis schmerzt, halten ihr technisches Urteilsvermögen aktuell und behalten den Respekt der Entwickler, die ihre Entwürfe umsetzen müssen. Architekten, die jahrelang nicht programmieren, laufen Gefahr, Systeme zu entwerfen, die am Whiteboard elegant und im Editor sperrig sind.

Was dagegen spricht. Die Zeit eines Architekten verteilt sich auf viele Teams, Meetings und Entscheidungen. Ein Architekt, der Features auf dem kritischen Pfad verantwortet, wird zum Engpass: Das Team wartet auf Code, der sich wegen der anderen Aufgaben des Architekten verzögert. Seine Aufmerksamkeit wird außerdem für teamübergreifende Anliegen gebraucht, um die sich kein einzelnes Team kümmert.

Die übliche Lösung. Die meisten erfahrenen Stimmen, darunter Richards und Ford, empfehlen, dass Architekten auf eine Weise praktisch mitarbeiten, die sie nicht auf den kritischen Pfad bringt. Beispiele sind ein Proof of Concept, um eine riskante Option zu testen, bevor sich das Team darauf festlegt; das Schreiben von Fitness Functions, automatischen Prüfungen, die Architekturregeln verifizieren, etwa „das Domänenmodul darf nicht vom Web-Framework abhängen“; Bugs beheben und kleinere Arbeiten an technischen Schulden erledigen; Werkzeuge und Automatisierung für das Team bauen; und regelmäßig Code-Reviews machen, die zeigen, wie Entscheidungen tatsächlich umgesetzt werden.

import pathlib, re

FORBIDDEN = re.compile(r"^\s*(from|import)\s+flask\b", re.M)

def test_domain_does_not_depend_on_web_framework():
    offenders = []
    for path in pathlib.Path("shop/domain").rglob("*.py"):
        if FORBIDDEN.search(path.read_text(encoding="utf-8")):
            offenders.append(str(path))
    assert not offenders, f"Domain code imports Flask: {offenders}"