Die Diskussion ist schon im vollen Gange. Irgendwann dreht sich jemand um und fragt: „Du kennst das System doch am besten – warum haben wir das damals eigentlich so gebaut?“
Für eine Person im Raum ist die Antwort klar. Für alle anderen nicht.
Dieser Moment passiert täglich in Entwicklungsteams jeder Größe. Viele Entwickler lernen Softwarearchitektur im Laufe ihrer Karriere durch praktische Erfahrung – und entschieden sich später, diese Wissen systematisch zu vertiefen.
Solange die richtige Person im Raum sitzt, fällt es kaum auf. Aber wenn sie fehlt, zeigt sich, was dahinter steckt: Das Wissen über das System sitzt nicht im System. Es sitzt in einem Menschen.
Wir haben erfahrene Softwarearchitekten gefragt, wie sie mit diesem Moment umgehen – Autoren, Trainer, Speaker unserer Magazine, Konferenzen und Trainings. Die Antworten entstammen einer Experten-Umfrage, die wir im Java Magazin (Juli 2025) veröffentlicht haben.
Viele Entwickler lernen Softwarearchitektur nicht im Rahmen einer formalen Ausbildung. Stattdessen wachsen sie mit zunehmender Erfahrung in diese Rolle hinein: Projekte werden größer, Entscheidungen komplexer, und irgendwann übernehmen sie die Verantwortung für die Architektur.
Mit zunehmender Verantwortung entsteht oft der Wunsch, Architekturentscheidungen nicht nur zu treffen, sondern sie auch klar zu begründen und zu kommunizieren. Methoden, gemeinsame Begriffe und strukturierte Kommunikation helfen dabei, Architekturwissen explizit zu machen und es im Team besser zu teilen.
Lars Röwekamp, Softwarearchitekt und langjähriger Berater: „Um ehrlich zu sein, stamme ich aus einer Zeit, in der man automatisch zum Architekten ernannt wurde, wenn man mehr als drei Jahre Berufserfahrung hatte.“
Das ist kein Sonderfall. Ein Projekt wächst, Entscheidungen werden komplexer, und irgendwann ist da jemand, der sie trifft. Meistens der Erfahrenste im Raum.
Das funktioniert und oft sogar gut. Aber die Struktur, die dabei entsteht, ist personengebunden – und damit fragil.
Tom Asel, Softwarearchitekt und Leiter eines Architektenteams: „Architektur ist Teamsport.“ Wissen, das nur in Gesprächen existiert, ist keine Architektur.
Gernot Starke, Mitbegründer von arc42 und eine der prägenden Stimmen der deutschsprachigen Architektur-Community, beobachtet seit Jahren:
„Die Hard Skills finde ich teilweise überbewertet in der Praxis – den besten Techies fehlt es aus meiner Sicht öfter mal an Verständnis für andere Stakeholder, an Empathie oder Überzeugungsfähigkeit.“
Falk Sippach, Softwarearchitekt bei embarc, beschreibt die Rolle konkret:
„In der Softwarearchitekturarbeit sind wir das Bindeglied zwischen allen Projektbeteiligten, müssen die Qualitätsanforderungen herausarbeiten, Kompromisse bei Entscheidungen finden und die Architektur für alle Stakeholder möglichst transparent machen.“
Eine Architekturentscheidung kann technisch richtig sein – und trotzdem scheitern, weil niemand sie begründen kann.
Es gibt einen Punkt, den viele erfahrene Entwickler:innen kennen. Das System läuft, die Entscheidungen waren gut. Und dann kommt eine Frage – aus dem Management, von einem neuen Teamkollegen, in einer Präsentation – auf die keiner eine klare Antwort hat.
Nicht weil das Wissen fehlt, sondern weil es nie in eine Form gebracht wurde, die andere verstehen oder einfach abrufen können.
Viele Entwickler beginnen bewusst, Softwarearchitektur zu vertiefen, wenn sie ihre Architekturentscheidungen klarer erklären und nachvollziehbar begründen möchten.
Ich weiß es zwar – aber ich kann es nicht erklären, nicht weitergeben, nicht verteidigen.
Das ist der Moment, an dem viele Entwickler anfangen, Architektur systematisch zu lernen.
Nicht weil sie scheitern, sondern weil sie merken: ihr Können ist größer als das Vokabular, das sie dafür haben.
Sönke Magnussen, Trainer beim Software Architecture Camp Foundation und Mitarbeiter beim Softwaredienstleister WPS, kennt diesen Moment aus dem Training:
„Viele Teilnehmer können Architektur – aber sie können sie nicht zeigen. Sie haben keine Sprache dafür. Und ohne Sprache kann man nicht gemeinsam entscheiden.“
Was im Camp vermittelt wird, sind Methoden und eine gemeinsame Nomenklatur – beides gehört zusammen.
Methoden geben dem Entwurf eine Struktur, die Sprache macht ihn für andere greifbar. Was in einem Unternehmen als „sauber modularisiert“ gilt, ist anderswo eine unbekannte Kategorie. Kommunikation über Architektur scheitert selten am Können, öfter am fehlenden Vokabular.
Architekturen werden im Camp nicht nur entworfen, sondern präsentiert und verteidigt. Magnussen beschreibt, was dabei regelmäßig passiert: „Jemand präsentiert seinen Entwurf. Nach zwei Minuten kommen Fragen, die er nicht erwartet hat – nicht weil der Entwurf schlecht ist, sondern weil er ihn bisher nie vor Fremden erklären musste.“ Genau dort, wo Gewissheit endet, beginnt das Lernen.
Das Camp läuft drei Tage – als Präsenztraining und als Online-Camp mit Live-Sessions. Die Gruppe ist bewusst heterogen, sodass man viel voneinander lernen kann: erfahrene Architekten neben Lead-Entwicklern, Startups neben Konzernen. Andere Kontexte werfen andere Fragen auf – das ist keine Nebenwirkung, sondern Teil der Methode.
Erfahrung hält Projekte am Laufen. Architektur sorgt dafür, dass sie auch ohne bestimmte Personen weiterlaufen.
Wer das Software Architecture Camp Foundation besucht, kann im Anschluss direkt die CPSA-F-Prüfung des iSAQB ablegen – eine international anerkannte Zertifizierung, die diesen Schritt nach außen sichtbar macht.
