Auf der InfoQ-Konferenz stellten erfahrene Software-Architekten eine unbequeme These in den Raum: Die größte Bedrohung für moderne Softwaresysteme ist nicht externe Komplexität – sondern die, die wir uns selbst schaffen. Ein Panel-Gespräch mit weitreichenden Konsequenzen für die Praxis.
Software-Architektur: Experten-Panel mahnt zu mehr Pragmatismus im Umgang mit Komplexität
Auf der InfoQ-Konferenz diskutierten erfahrene Software-Architekten, warum bestehende Architekturkonzepte in der Praxis häufig scheitern – und welche Denkansätze Unternehmen stattdessen verfolgen sollten. Der Tenor des Panels war eindeutig: Die Branche neigt dazu, Komplexität mit mehr Komplexität zu begegnen, anstatt grundlegende Fragen zur Systemgestaltung neu zu stellen.
Komplexität als selbst geschaffenes Problem
Ein zentrales Argument der Diskussionsrunde: Ein Großteil der Komplexität in modernen Softwaresystemen entsteht nicht durch äußere Anforderungen, sondern durch interne Entscheidungen. Besonders im Fokus stand die vorschnelle Einführung von Microservices-Architekturen, bevor ein Unternehmen die organisatorischen Voraussetzungen dafür geschaffen hat.
„Technische Schulden entstehen oft nicht durch schlechten Code, sondern durch schlechte Entscheidungsprozesse.”
Architekturen werden für eine Skalierung entworfen, die möglicherweise nie eintritt – während die laufenden Kosten für Wartung und Koordination stetig steigen. Das Panel verwies auf das sogenannte „Accidental Complexity”-Problem, das Fred Brooks bereits in den 1980er-Jahren beschrieben hat: Schwierigkeiten, die sich Entwickler selbst schaffen, statt jene, die dem Problemraum inhärent sind.
Jahrzehnte später sei dieses Muster in Cloud-nativen Umgebungen und verteilten Systemen allgegenwärtiger denn je.
Modularität neu denken
Die Diskussionsteilnehmer sprachen sich für einen klareren Fokus auf Modularität aus – nicht als architektonisches Dogma, sondern als pragmatisches Werkzeug:
Ein gut geschnittener Monolith, der klare interne Grenzen zieht, kann in vielen Kontexten besser skalieren und einfacher zu betreiben sein als ein verteiltes System mit dutzenden Diensten.
Entscheidend sei nicht die gewählte Architekturform, sondern ob die Grenzen zwischen Komponenten fachlich sinnvoll gezogen wurden – und ob Teams diese Grenzen eigenständig pflegen können.
Hier griffen die Experten auch das Konzept der „Cognitive Load” auf: Systeme, die zu viele Abhängigkeiten zwischen Teams erzeugen, verlangsamen Entwicklungszyklen unabhängig von der technischen Eleganz ihrer Architektur. Die Empfehlung lautete, Architekturentscheidungen stärker an Teamstruktur und Kommunikationswegen zu orientieren – ein Prinzip, das Conways Gesetz seit Jahrzehnten nahelegt, in der Praxis jedoch häufig ignoriert wird.
Entscheidungen dokumentieren, nicht nur treffen
Ein weiterer Schwerpunkt des Panels lag auf der fehlenden Nachvollziehbarkeit von Architekturentscheidungen. Viele Organisationen treffen weitreichende technische Weichenstellungen, ohne diese systematisch festzuhalten.
Architecture Decision Records (ADRs) wurden als einfaches, aber wirkungsvolles Mittel genannt, um Kontext und Begründung von Entscheidungen zu dokumentieren – gerade dann, wenn Teams wachsen oder Mitarbeitende wechseln.
Architektur ist keine einmalige Aufgabe, die zu Projektbeginn abgeschlossen wird – sie ist ein kontinuierlicher Prozess, der regelmäßige Überprüfung und Anpassung erfordert.
Einordnung für deutsche Unternehmen
Für deutsche Unternehmen – insbesondere im Mittelstand, wo IT-Ressourcen oft begrenzt sind – sind die Erkenntnisse des Panels direkt anwendbar:
Die Entscheidung für eine Microservices-Architektur oder eine Cloud-native Plattform sollte nicht primär durch Markttrends getrieben werden, sondern durch eine ehrliche Analyse von:
- Teamgröße und verfügbaren Kapazitäten
- Entwicklungsreife der eigenen Organisation
- Fachlichen Anforderungen und realistischem Skalierungsbedarf
Wer die Grundlagen solider Modularität und klarer Dokumentation beherrscht, schafft bessere Voraussetzungen für spätere Skalierungsschritte – unabhängig davon, welche Architekturmuster dann zum Einsatz kommen.
