Die Aufgabe eines Softwarearchitekten – und warum sie oft nicht stattfinden kann

In vielen Unternehmen gibt es den Titel „Softwarearchitekt". Oft wird er verwendet, um technische Reife zu signalisieren — intern wie extern. Doch Reife entsteht nicht durch Benennung. Sie entsteht durch die organisatorische Verankerung der Funktion.

Architektur ist eine Gestaltungsfunktion. Sie braucht Kontext, Einfluss, Zeit und ein klares Mandat. Fehlt eines davon, entsteht keine Architektur — sondern die Summe lokaler Entscheidungen, die niemand zusammenhält.

Die Frage ist deshalb nicht: „Haben wir einen Architekten?"
Sondern: „Haben wir die Voraussetzungen, damit Architektur stattfinden kann?"

Architektur scheitert selten an fehlender Kompetenz.
Sie scheitert an fehlender organisationaler Ehrlichkeit.

---

Architektur ist keine Implementierung mit mehr Erfahrung

Ein häufiger Irrtum ist die Annahme, ein Softwarearchitekt sei einfach ein besonders erfahrener Entwickler — ein „Senior Developer Plus".

Natürlich braucht ein Architekt technische Erfahrung. Viel sogar.
Aber seine primäre Aufgabe ist nicht das Schreiben von Code.

Ralph Johnson brachte es in einer vielzitierten Diskussion auf den Punkt, die Martin Fowler später in seinem Essay „Who Needs an Architect?" aufgriff: Architektur sind die Entscheidungen, die man gerne früh im Projekt richtig treffen würde — weil sie später schwer zu ändern sind.

Die Aufgabe eines Architekten ist es also, genau diese Entscheidungen zu treffen — Entscheidungen, die den Code überhaupt erst möglich und nachhaltig machen:

• Wie soll sich das System über Jahre entwickeln?
• Welche Struktur erlaubt Wachstum ohne exponentielle Komplexität?
• Welche Entscheidungen sind reversibel — und welche nicht?
• Wo entstehen zukünftige Risiken (Skalierung, Sicherheit, Betrieb, Compliance)?
• Welche Abhängigkeiten bauen wir gerade auf — und welche langfristigen Kosten entstehen daraus?

Das sind keine Implementierungsfragen.
Das sind Struktur-, Richtungs- und Nachhaltigkeitsfragen.

Mark Richards und Neal Ford formulierten dazu das erste Gesetz der Softwarearchitektur: Alles in der Softwarearchitektur ist ein Trade-off — und wer glaubt, etwas gefunden zu haben, das keiner ist, hat den Trade-off vermutlich nur noch nicht erkannt.

Ein Senior Developer optimiert die Lösung.
Ein Softwarearchitekt gestaltet den Lösungsraum.

Der Unterschied liegt nicht in der Fähigkeit zu implementieren, sondern im Schwerpunkt der Verantwortung.

---

Das strukturelle Spannungsfeld: Verantwortung hier, Entscheidungen überall

Wenn Architektur diese Art von Entscheidungen betrifft, ist die eigentliche Frage nicht Kompetenz — sondern ob die Organisation diese Entscheidungen überhaupt möglich macht.

Architektur setzt voraus, dass jemand das große Ganze sehen und wissen kann. Nicht im Sinne von Kontrolle, sondern im Sinne von Überblick: Welche Fähigkeiten existieren bereits? Welche Vorhaben laufen parallel? Welche Integrationen, Datenflüsse und Betriebsannahmen sind im Spiel?

In vielen Organisationen werden Zuständigkeiten scheinbar sauber aufgeteilt: Business entscheidet das Was, Engineering Manager organisieren die Teams, Tech Leads verantworten die Umsetzung im Alltag — und der Architekt kümmert sich um „die Struktur".

Klingt ordentlich. Funktioniert so oft nicht.

Denn Architektur ist keine isolierte Zuständigkeit. Sie ist das Ergebnis von Entscheidungen, die überall getroffen werden:

• Wenn das Business beschließt, in neue Märkte zu expandieren, hat das architektonische Konsequenzen.
• Wenn die Teamstruktur geändert wird, beeinflusst das, ob Microservices sinnvoll sind oder ein Monolith die bessere Wahl ist.
• Wenn ein Team eine neue Programmiersprache einführt, ein anderes ein neues Framework wählt und ein drittes eine eigene Deployment-Pipeline baut — dann entsteht genau die Insellandschaft, die Architektur verhindern soll.
• Wie eine Applikation deployed wird, ist eine Architekturentscheidung. Teamzuschnitt, Systemschnitt, Repository-Struktur und Deployment-Fähigkeiten hängen eng zusammen — oft als Kreislauf, der bis in SLAs, Verfügbarkeit und Compliance reicht.

Conway formulierte das bereits 1968: Organisationen, die Systeme entwerfen, sind gezwungen, Designs zu produzieren, die die Kommunikationsstrukturen dieser Organisationen abbilden. Und Ruth Malan formulierte die Konsequenz: Wenn Systemarchitektur und Organisationsarchitektur im Widerspruch stehen, gewinnt die Organisation.

So entsteht ein strukturelles Spannungsfeld: Die Verantwortung für die langfristige Systementwicklung liegt bei der Architektur. Die entscheidungsprägenden Faktoren entstehen aber verteilt in der Organisation. Die Erwartung, dass „der Architekt schon dafür sorgt", besteht — auch wenn er gar nicht eingebunden war. Und das Mandat, an den relevanten Stellen mitzuwirken, fehlt oder ist unklar.

Wenn diese Dinge nicht zusammenpassen, entsteht eine fatale Situation: Architektur wird erwartet, kann aber nicht aktiv gestaltet werden. Sie reagiert auf Entscheidungen, die bereits getroffen wurden, statt sie im Vorfeld mitzuprägen.

Das ist kein Kompetenzproblem. Es ist ein organisationsstrukturelles Muster.

Deshalb muss ein Softwarearchitekt in all diesen Bereichen zumindest einbezogen werden — nicht um das „Ob" zu entscheiden, sondern um das „Was bedeutet das für das System?" rechtzeitig einzubringen. Alles, was über ein einzelnes Team hinausgeht, sollte architektonisch sichtbar sein. Nicht als Genehmigungsprozess. Nicht als Bürokratie. Sondern weil jemand den Überblick behalten muss.

Je nach Teamgröße und Komplexität kann Architektur als Rolle zentral, verteilt oder rotierend gelebt werden. Wichtig ist nicht der Titel. Wichtig ist, dass die Funktion existiert und organisatorisch verankert ist.

Wenn das nicht passiert, sieht man es nicht sofort im Code — sondern in Mustern: Es entstehen lokal sinnvolle Lösungen, die global nicht zusammenpassen. Ähnliche Dinge werden mehrfach gebaut, weil niemand weiß, dass es sie schon gibt. Jede Lösung bringt ihre eigenen Begriffe, Datenmodelle und Schnittstellen mit. Integration und Betrieb werden mit jeder Insel teurer.

Von außen kann das so wirken, als sei Architektur „unnötig". Nicht, weil Architektur keinen Wert hätte, sondern weil die Organisation sie nicht als verbindende Funktion nutzt. Dann bleibt Architektur eine Sammlung von Einzelentscheidungen, die nicht aus einem gemeinsamen Bild heraus entstehen, sondern aus zufälliger Reihenfolge und lokalem Druck.

Das ist keine Kritik an einzelnen Entwickler:innen — es ist eine Beobachtung über Organisationsmechanik.

---

Ein Beispiel aus der Praxis

Ein System verwaltet Kampagnen mit Start- und Enddaten. Am Anfang reicht ein einfaches DateTime-Feld. Die Annahme: Alle Nutzer sitzen in derselben Zeitzone, Deadlines sind „Ende des Tages", und niemand fragt, welcher Tag genau gemeint ist.

Das funktioniert — solange die Annahme stimmt.

Dann kommen internationale Kunden. Ein Nutzer in New York gibt „5. Juni" als Deadline ein. Ein Nutzer in Wien sieht dasselbe Datum — aber wessen Mitternacht gilt? Das System weiß es nicht, weil der Typ DateTime diese Information nicht trägt. Er speichert eine Zahl ohne Kontext.

Jedes Team löst das Problem lokal:

• Das Backend-Team konvertiert alles stillschweigend nach UTC — verliert dabei aber die Information, welche Zeitzone der Nutzer gemeint hat.
• Das Frontend-Team zeigt Daten in der Browser-Zeitzone an — die sich vom Server unterscheiden kann.
• Ein drittes Team baut einen Reporting-Export, der die Datenbank-Werte direkt ausgibt — in UTC, ohne Umrechnung.

Kein Team hat einen Fehler gemacht. Jede Entscheidung war lokal nachvollziehbar. Aber das System zeigt jetzt für dasselbe Ereignis drei verschiedene Uhrzeiten an — je nachdem, wo man hinschaut.

Das eigentliche Problem liegt tiefer: „Was ist ein Datum in unserem System?" wurde nie als Frage gestellt. Ist es ein Zeitpunkt auf dem Zeitstrahl? Ein Kalendertag im Sinne des Nutzers? Eine Deadline, die eine Zeitzone braucht? Ein wiederkehrendes Ereignis, das sich nach lokalen Regeln richtet? Das sind fundamental verschiedene Konzepte — aber das Datenmodell behandelt sie alle gleich: als eine einzelne Spalte vom Typ timestamp.

Technisch ist all das lösbar. Aber nicht mehr einfach. Das Datenmodell muss aufgespalten werden. Bestehende Daten müssen migriert werden — ohne zu wissen, welche Zeitzone bei der Eingabe gemeint war. Jede Schnittstelle, jeder Report, jede Anzeige muss geprüft werden.

Nicht das Feature war komplex. Die fehlende architektonische Einbettung war es. Eine einzige frühe Entscheidung — „Welche Typen von Zeit gibt es in unserem System, und wie modellieren wir sie?" — hätte den gesamten Folgeaufwand verhindert.

Und genau hier zeigt sich: Architektur ohne Kontext kann nur Inseln verwalten — aber keine Systeme gestalten.

---

Architektur braucht Fokus und Feedback

Architekturarbeit entsteht nicht im Task-Wechsel zwischen zwei Bugfixes, sondern durch Analyse, Modellierung, Bewertung von Alternativen, gedankliches Durchspielen von Szenarien und bewusste Entscheidungen unter Unsicherheit.

Typische Bestandteile sind:

• Dokumentation von Entscheidungen (z. B. ADRs)
• Bewertung von Trade-offs
• Definition von Leitplanken
• Evolutionspfade und Refactoring-Strategien
• Risikoanalyse
• Abhängigkeits- und Integrationslandkarten
• Kommunikation und Alignment über Teams hinweg

Wenn 90 % der Arbeitszeit für Feature-Implementierung reserviert sind, bleibt für all das faktisch kein Raum. Dann wird Architektur nicht gestaltet — sie entsteht als Nebenprodukt. Dann wird aus einem DateTime-Feld ein systemweites Problem — nicht weil die Frage schwer war, sondern weil niemand die Zeit hatte, sie zu stellen. Und das ist einer der teuersten Zustände, die ein Softwaresystem haben kann.

Gleichzeitig scheitert Architektur auch am anderen Ende: wenn Architekten weit entfernt von der täglichen Entwicklung arbeiten. Sie definieren Leitlinien und entwerfen Zielbilder — ohne die praktischen Einschränkungen der Umsetzung wirklich zu kennen. Die Folge ist „Elfenbeinturm-Architektur".

Gute Architektur braucht deshalb beides:

• Strategischen Abstand, um langfristig zu denken.
• Praktische Nähe, um realistisch zu bleiben.

Ein Architekt programmiert nicht, weil Features umgesetzt werden müssen.
Er programmiert, weil Architektur real sein muss — um Annahmen zu überprüfen, Risiken sichtbar zu machen und Strukturen zu erproben.

Fehlt eines davon, wird Architektur entweder reaktiv — oder realitätsfern.

Man könnte einwenden, dass reaktive Architektur gewollt sein kann. Moderne Architekturansätze verfolgen bewusst das Prinzip, Entscheidungen möglichst spät zu treffen — dann, wenn mehr Informationen verfügbar sind.

Der Unterschied liegt nicht im Zeitpunkt, sondern im Grund:

• Strategie: Wir könnten früher entscheiden, tun es aber absichtlich später. Beispiel: Wir lassen die Storage-Technologie offen, definieren aber klare Schnittstellen und Performance-Checks, bis Lastprofile messbar sind.
• Zwang: Wir müssen jetzt reagieren, weil uns vorher Informationen, Einfluss oder Zeit gefehlt haben. Beispiel: Wir wählen „irgendeine" Technologie unter Zeitdruck, ohne Lastannahmen, ohne Leitplanken, ohne Ausstiegspfad.

Beides sieht von außen „reaktiv" aus. Ist aber fundamental verschieden.

---

Woran du erkennst, dass Architektur nicht wirklich existiert

Nicht als Titel. Sondern als gelebte Funktion.

• Werden strukturelle Entscheidungen bewusst dokumentiert — oder nur umgesetzt?
• Gibt es explizite Zeit für Architekturarbeit — oder passiert sie „wenn gerade Luft ist"?
• Sind Architekten in strategische Produktentscheidungen eingebunden?
• Werden größere Änderungen vor Umsetzung teamübergreifend sichtbar gemacht?
• Gibt es Transparenz darüber, welche Fähigkeiten und Module bereits existieren?
• Werden technische Leitplanken aktiv definiert — oder entstehen sie implizit?
• Gibt es geplante Evolutionspfade — oder nur Refactorings bei Bedarf?
• Werden langfristige Risiken aktiv diskutiert — oder erst sichtbar, wenn sie auftreten?

Wenn die meisten Antworten „nein" sind, existiert Architektur vermutlich nicht als gestaltende Funktion.

Und Emergenz ist kein Ersatz für Verantwortung.

---

Fazit

Ein Softwarearchitekt ist nicht einfach ein Senior Developer mit anderem Titel.
Er ist verantwortlich für Struktur, Richtung und Zukunftsfähigkeit eines Systems.

Dafür braucht er Kontext, Einfluss, Zeit und ein Mandat. Wenn davon etwas fehlt, kann er seine Aufgabe nicht erfüllen — egal wie kompetent er ist.

Deshalb sollte jedes Unternehmen, das den Titel „Softwarearchitekt" verwendet, sich eine einfache Frage stellen:

Wollen wir Architektur wirklich gestalten?
Oder wollen wir nur so tun, als gäbe es sie?