ROLLEN

Software Architect

Die Person, die für die Form des Systems auf Gesamtebene verantwortlich ist: die großen strukturellen Entscheidungen, die teuer rückgängig zu machen sind, und die nicht-funktionalen Anforderungen, die sonst niemandem gehören.

Zuletzt geprüft: 2026-06-02 vonKevin Riedl wiki ↗

Ein Software Architect verantwortet die Entscheidungen, die schwer rückgängig zu machen sind. Wie das System in Services oder Module aufgeteilt wird, wie die Daten durch es fließen, wo die Grenzen liegen, auf welche Technologien sich der Stack festlegt und wie das Ganze unter Last, Ausfall und Wachstum standhält. Einzelne Features sind günstig zu ändern. Diese strukturellen Entscheidungen sind es nicht, weshalb jemand auf Systemebene und nicht auf Feature-Ebene denken muss.

Der eigentliche Wert liegt in den nicht-funktionalen Anforderungen: Performance, Skalierbarkeit, Sicherheit, Zuverlässigkeit, Wartbarkeit. Das sind die Dinge, die keinem einzelnen Feature-Ticket gehören und die ein Produkt im Stillen versenken, wenn man sie ignoriert. Die Aufgabe des Architekten ist es, die Trade-offs laut zu benennen. Jetzt schneller bauen versus später günstiger ändern. Einfach und begrenzt versus flexibel und komplex. Es gibt keine kostenlose Architektur, nur Trade-offs, die man bewusst gewählt hat, oder Trade-offs, die man aus Versehen geerbt hat.

Die meisten Startups brauchen keinen dedizierten Software Architect, und einen früh einzustellen ist meist ein Fehler. Bei kleiner Größe ist die Architektur klein, und der Tech Lead oder CTO trägt sie als Teil seiner Arbeit. Ein Vollzeit-Architekt ohne Code zum Schreiben und ohne Team zum Führen produziert tendenziell Diagramme und Standarddokumente, die das Team dann ignoriert. Die Rolle verdient ihren Platz, sobald das System groß genug ist, dass niemand mehr das ganze Bild im Kopf hat.

Die ehrliche Einschätzung: “Solutions Architect” im Organigramm eines Anbieters bedeutet oft eine Pre-Sales-Rolle, die Systeme entwirft, die sie nie warten muss. Ein guter Architekt bleibt nah genug am Code, um die Konsequenzen seiner eigenen Entscheidungen zu spüren. Wenn die Person, die die Kästchen zeichnet, nie in ihnen leben muss, werden die Kästchen falsch sein.

// FAQ

Häufige Fragen

Häufige Fragen

Er verantwortet die Entscheidungen auf Systemebene, die teuer rückgängig zu machen sind: wie das System strukturiert ist, wie die Daten fließen, auf welche Technologien es sich festlegt und wie es unter Last und Ausfall standhält. Außerdem verantwortet er die nicht-funktionalen Anforderungen wie Performance, Sicherheit und Zuverlässigkeit, die kein einzelnes Feature-Ticket abdeckt.
Ein Tech Lead führt die technische Arbeit eines Teams im Alltag. Ein Architekt denkt über das gesamte System und die langfristige Struktur. In einem kleinen Team sind sie dieselbe Person. Die Trennung entsteht erst, wenn das System zu groß ist, als dass eine Person das ganze Bild halten und zugleich ein Team führen könnte.
Meist nicht. Bei kleiner Größe ist die Architektur klein genug, dass der Tech Lead oder CTO sie trägt. Ein dedizierter Architekt früh produziert tendenziell Dokumente, die das Team ignoriert. Die Rolle verdient ihren Platz, sobald keine einzelne Person mehr das ganze System im Kopf halten kann.