Wandel der Rolle
Was ein Softwarearchitekt tut, hat jede Generation neu verhandelt. Meist nicht aus Einsicht, sondern weil neue Werkzeuge die alten Antworten unbrauchbar gemacht haben.
Diese Seite ist ein Gerüst. Die 1980er und die jüngste Epoche sind ausgearbeitet, die übrigen werden nach und nach ergänzt.
1968 bis Ende der 1970er
Softwarekrise und die Idee der Struktur
Auf der NATO-Konferenz 1968 in Garmisch bekommt das Problem einen Namen: Software Engineering. Systeme werden größer, als ein Kopf überblicken kann. David Parnas fragt 1972, nach welchen Kriterien man ein System in Module zerlegt, und antwortet: nach den Entscheidungen, die sich ändern könnten. Fred Brooks fordert 1975 konzeptionelle Integrität, also einen einheitlichen Entwurf aus möglichst einem Kopf.
- Architektur ist
- die Zerlegung eines Systems und die Kontrolle über seine Komplexität
- Der Architekt ist
- der Chefdesigner, der für die Einheitlichkeit des Ganzen sorgt
- Werkzeugwechsel
- höhere Programmiersprachen, strukturierte Programmierung
1980er
Theoriebildung und die menschliche Perspektive
Während die Industrie auf strukturierte Analyse, erste CASE-Tools und grafische Notationen setzt, entstehen abseits des Mainstreams radikale Gegenentwürfe. Peter Naur beschreibt Programmieren 1985 als Theoriebildung: Das eigentliche Ergebnis von Softwareentwicklung ist das geteilte Verständnis im Kopf der Entwickler, nicht der geschriebene Code. Christiane Floyd fordert 1987 einen Paradigmenwechsel von der produkt- zur prozessorientierten Sicht: Software entsteht im gemeinsamen Lernen und in der Kommunikation mit den Menschen, die sie nutzen. Ein Ansatz, den ich ab 1987 im Studium direkt bei ihr kennenlernte. Beide Texte werden damals kaum beachtet. Jahrzehnte später, im Zeitalter von KI-Agenten, sind sie plötzlich hochaktuell (Programmieren war nie der Punkt).
- Architektur ist
- ein gemeinsames mentales Modell, das im Dialog mit den Nutzern wächst
- Der Architekt ist
- Theoriebildner, Lernender und Brückenbauer zur Fachwelt (damals noch eine Außenseiter-Sicht)
- Werkzeugwechsel
- CASE-Tools, strukturierte Analyse (SA/SD), erste Workstations und grafische Oberflächen
1990er
Architektur wird eine Disziplin
Perry und Wolf (1992), Garlan und Shaw (1993, Buch 1996) machen Softwarearchitektur zum eigenen Forschungsgebiet: Elemente, Verbindungen, Architekturstile. Kruchten beschreibt 1995 das 4+1-Sichtenmodell, die „Gang of Four“ 1994 die Entwurfsmuster. Es entsteht ein gemeinsames Vokabular.
- Architektur ist
- Strukturen, Stile und Muster, die man benennen und vergleichen kann
- Der Architekt ist
- der Experte für Strukturen und ihre Qualitätseigenschaften
- Werkzeugwechsel
- Objektorientierung, verteilte Systeme, Client/Server
ca. 1997 bis 2005
Modelle, Prozesse, Generatoren
Die UML wird 1997 Standard, der Rational Unified Process (1998) ist ausdrücklich architekturzentriert und macht den Architekten zur Prozessrolle, IEEE 1471 definiert 2000, was eine Architekturbeschreibung ist. Mit der Model Driven Architecture (2001) entsteht die Hoffnung, Code aus Modellen zu generieren. Es ist auch die Zeit, in der der Begriff „Elfenbeinturm“ an Architekten hängen bleibt.
- Architektur ist
- ein Modell, aus dem das System abgeleitet wird
- Der Architekt ist
- Modellierer und Dokumentar, oft weit weg vom Code
- Werkzeugwechsel
- Modellierungswerkzeuge, Codegeneratoren, Application Server
2001 bis ca. 2012
Agilität: Architektur als Teamaufgabe
Das Agile Manifest (2001) stellt den großen Vorabentwurf in Frage. Eric Evans bringt 2003 die Fachlichkeit ins Zentrum (Domain-Driven Design). Parallel boomt SOA. Im deutschsprachigen Raum entstehen arc42 und das iSAQB. Die Rolle wird umstritten: Braucht ein agiles Team überhaupt einen Architekten, und wenn ja, muss er programmieren? Diese Debatte wurde 2009 bis 2012 auch auf dieser Seite geführt (Archiv).
- Architektur ist
- gerade genug Entwurf, der mit dem System wächst
- Der Architekt ist
- Teammitglied, Mentor, programmierender Entscheider
- Werkzeugwechsel
- Continuous Integration, testgetriebene Entwicklung, Open-Source-Frameworks
ca. 2012 bis 2022
Cloud, Microservices, Plattformen
Die Cloud macht Infrastruktur zu Code, Microservices (Lewis und Fowler, 2014) machen Teamgrenzen zu Systemgrenzen. Conways Gesetz von 1968 wird wiederentdeckt, Team Topologies (2019) macht Architektur endgültig soziotechnisch. Architekturentscheidungen werden in ADRs festgehalten, Fitness Functions (2017) prüfen Architekturziele automatisch. Gregor Hohpe beschreibt den Architekten als jemanden, der im „Architect Elevator“ zwischen Vorstandsetage und Maschinenraum pendelt.
- Architektur ist
- die Summe der Entscheidungen, die Teams unabhängig liefern lassen
- Der Architekt ist
- Enabler, Vermittler zwischen Organisation und Technik
- Werkzeugwechsel
- Cloud, Container, Infrastructure as Code, Platform Engineering
seit ca. 2022
KI: Code wird immer billiger, Urteil wird teuer
Mit Code-Assistenten und ChatGPT beginnt es, mit autonomen Coding-Agenten wird es ernst. Code zu schreiben kostet fast nichts mehr. Hier schließt sich der Kreis zu Naur und Floyd aus den 1980ern: Wenn KI den Code liefert, bleibt für Menschen genau das übrig, was schon damals als Kern der Sache erkannt wurde: Theoriebildung, Domänenverständnis und gemeinsame Verantwortung.
Der Engpass wandert zum Review, zur Entscheidung und zur Fachseite. Architekten entwerfen zunehmend nicht mehr den Code, sondern die Umgebung, in der Agenten ihn erzeugen: Leitplanken, Invarianten, Prüfschleifen. Die Fitness Functions der vorigen Epoche werden von der Kür zur Pflicht.
- Architektur ist
- das, was mechanisch durchgesetzt wird, und das, worüber Menschen entscheiden müssen
- Der Architekt ist
- Harness-Designer, Prüfer, Übersetzer zwischen Fachlichkeit und Agenten
- Werkzeugwechsel
- LLMs, Coding-Agenten, Spec-Driven Development
Essays dazu: Programmieren war nie der Punkt · Der Engpass wandert · Vom Code-Design zum Harness-Design · Architekten mauern keine Wände, 2009 und 2026
Ein Muster
Zwei Dinge wiederholen sich über alle Epochen. Erstens: Jede neue Werkzeuggeneration verspricht, den Architekten überflüssig zu machen, sei es durch Generatoren, durch agile Teams oder durch Agenten. Zweitens: Was bleibt, ist jedes Mal dasselbe: das Verständnis des Problems, das ein Team teilen muss, und die Verantwortung für Entscheidungen, die teuer zu ändern sind. Nur der Ort, an dem diese Entscheidungen fallen, wandert.