Blog

Flexible Architektur gilt als eines der wichtigsten Ziele moderner Softwareentwicklung. In der Praxis scheitert sie jedoch oft an hoher Kopplung, unklaren Verantwortlichkeiten und vorschnellen Technologieentscheidungen. Im Interview erklären Eberhard Wolff und Falk Sippach, wie sich Flexibilität durch klare fachliche Grenzen, passende Architekturmodelle und kontinuierliche Architekturarbeit tatsächlich erreichen lässt.

Viele sprechen von „flexibler Architektur“. Was bedeutet Flexibilität für euch ganz konkret in der Praxis und woran erkennt man, ob ein System wirklich flexibel ist?

Flexibilität bedeutet vor allem, dass ein System auf Änderungen reagieren kann, ohne dass jede Anpassung teuer und riskant ist oder die Entwicklung verlangsamt. Es geht also nicht darum, möglichst viele Optionen offen zu halten, sondern darum, Veränderungen gezielt und mit vertretbarem Aufwand umzusetzen. Ob ein System wirklich flexibel ist, merkt man im Alltag: Bleiben Änderungen lokal? Sind Abhängigkeiten beherrschbar? Lassen sich neue Anforderungen ohne große Seiteneffekte und unabhängig von anderen Teams umsetzen? 

Was sind aus eurer Erfahrung die größten Hindernisse, die Teams davon abhalten, flexible Architekturen umzusetzen? Wie kann man diese überwinden?

Das größte Hindernis ist oft der kurzfristige Lieferdruck. Saubere Schnitte, gute Modulgrenzen und kontinuierliche Architekturarbeit sind zunächst ein gewisser Mehraufwand, zahlen sich aber langfristig aus. Oft ist der Druck so hoch, dass Teams gar nicht dazu kommen, über eine langfristig tragfähige Architektur nachzudenken. Hinzu kommen unklare Verantwortlichkeiten, historisch gewachsene Strukturen und die Versuchung, technische Trends zu übernehmen, ohne das eigentliche Problem verstanden zu haben. Überwinden lässt sich das nur schrittweise: mit mehr Transparenz über Abhängigkeiten, klareren fachlichen Grenzen und Architekturarbeit als kontinuierlicher Teamaufgabe.

Ihr sprecht in eurer Session sowohl über Domain-driven Design als auch über Microservices und Self-contained Systems. Wie greifen diese Ansätze ineinander, wenn es um Flexibilität geht?

Domain-driven Design hilft dabei, fachlich sinnvolle Grenzen zu finden. Genau dort beginnt Flexibilität: beim Verständnis der Domäne und bei klar geschnittenen Verantwortlichkeiten. Microservices und Self-contained Systems können darauf aufbauen und bieten technische Flexibilität, sind aber kein Selbstzweck. Ohne gute fachliche Schnitte entsteht keine fachliche Flexibilität und genau darauf kommt es häufig an. DDD liefert also die Grundlage, auf der man dann sinnvoll über Modulith (modularer Monolith), Microservices oder Self-contained Systems mit ihren jeweiligen Trade-Offs entscheiden kann.

Viele Organisationen setzen auf Microservices, ohne wirklich flexibler zu werden. Was wird dabei häufig falsch gemacht und worauf sollte man stattdessen achten?

Häufig werden Microservices als moderner Architekturstil eingeführt, ohne sich über die Vorteile und vor allem die Herausforderungen bewusst zu sein. Dann verteilt man ein System, ohne vorher die fachlichen Schnitte, Abhängigkeiten und Teamgrenzen sauber geklärt zu haben. Das Ergebnis sind viele kleine Services mit hoher Kopplung und großem Abstimmungsaufwand. Oft kann z. B. ein gut strukturierter Modulith der bessere Ausgangspunkt sein. Bei höheren Anforderungen an Skalierbarkeit oder stärkerer Unabhängigkeit können später Teile als Microservices herausgetrennt werden.

Wenn ein Team heute vor der Herausforderung steht, ein bestehendes System flexibler zu machen: Mit welchen ersten konkreten Schritten sollte es eurer Meinung nach beginnen?

Zuerst sollte das Team die größten Änderungsprobleme sichtbar machen: Wo dauern Änderungen zu lange? Wo entstehen immer wieder unbeabsichtigte Seiteneffekte? Welche Abhängigkeiten bremsen besonders? Danach gilt es, fachliche Verantwortlichkeiten zu schärfen, Modulgrenzen zu verbessern und Abhängigkeiten zu reduzieren. Wichtig ist, nicht mit einer großen Zielarchitektur zu starten, sondern mit kleinen, konkreten Verbesserungen dort, wo das System ohnehin gerade verändert wird.

Wie verändert sich das Thema flexible Architektur aktuell – zum Beispiel durch neue Anforderungen wie KI oder die Notwendigkeit, neue Features schneller auf den Markt zu bringen?

Flexible Architektur wird heute noch wichtiger, weil sich Anforderungen, Technologien und Märkte schneller ändern. Teams müssen schneller liefern und gleichzeitig mit mehr Unsicherheit umgehen. Das zeigt sich besonders beim Thema KI: Oft ist anfangs noch gar nicht klar, welche Modelle, Anbieter oder Integrationsformen sich langfristig durchsetzen. Gerade deshalb braucht es Architekturen, die Experimente erlauben, Kopplung begrenzen und Veränderungen möglich machen, ohne das Gesamtsystem zu destabilisieren.

Mehr zum Thema gibt es beim Software Architecture Forum 2026. In ihrer Session zeigen Eberhard Wolff und Falk Sippach, wie sich flexible Architekturen mit Domain-driven Design, Modulithen, Microservices und Self-contained Systems gezielt gestalten lassen und worauf es dabei in der Praxis wirklich ankommt.

Über die Sprecher:

Eberhard Wolff verfügt über mehr als 20 Jahre Erfahrung als Architekt und Berater – häufig an der Schnittstelle von Fachlichkeit und Technologie. Er ist Head of Architecture bei SWAGLab. Als Speaker hat er auf internationalen Konferenzen Vorträge gehalten und als Autor mehr als 100 Artikel und Bücher veröffentlicht, unter anderem zu Microservices und Continuous Delivery. Sein technologischer Fokus liegt auf modernen Architekturen – oft im Kontext von Cloud, Domain-Driven Design und Microservices.

Falk Sippach ist bei der embarc Software Consulting GmbH als Softwarearchitekt, Berater und Trainer stets auf der Suche nach dem Funken Leidenschaft, den er bei seinen Teilnehmern, Kunden und Kollegen entfachen kann. Bereits seit über 20 Jahren unterstützt er in meist agilen Softwareentwicklungsprojekten im Java-Umfeld. Als aktiver Bestandteil der Community (Mitorganisator der JUG Darmstadt und Mitglied der Java Champions) teilt er zudem sein Wissen gern in Artikeln, Blog-Beiträgen, sowie bei Vorträgen auf Konferenzen oder User Group Treffen und unterstützt bei der Organisation diverser Fachveranstaltungen.