Der SOA-Reflex ist das Problem

Manchmal reicht ein Satz in einer Stellenanzeige, und man hört innerlich irgendwo ein altes ESB-Handbuch zufallen.

In einer Staff-Engineer-Rolle stand sinngemäß:

You lead the technical migration of our legacy monolith towards a modular, service-oriented architecture – from planning to hands-on delivery.

Dieser Satz triggert mich.

Nicht, weil Services schlecht sind. Nicht, weil Modularisierung falsch ist. Nicht einmal, weil „service-oriented“ grundsätzlich böse wäre.

Sondern weil diese Formulierung nach einem alten Enterprise-Reflex riecht:

Legacy-Monolith kaputt? Dann bauen wir eine service-orientierte Zielarchitektur. Mit Planung. Governance. Service-Schnitten. Integrationslogik. Und vermutlich PowerPoint.

Das Problem ist nicht das Wort „Service“. Das Problem ist der Reflex dahinter.

SOA war nicht dumm

Es wäre billig, jetzt „SOA ist tot“ zu rufen und sich dafür modern zu fühlen.

SOA war eine nachvollziehbare Antwort auf reale Probleme. Unternehmen hatten Punkt-zu-Punkt-Integrationen, technische Wildwuchslandschaften, Monolithen, direkte Datenbankkopplung, proprietäre Schnittstellen und Abhängigkeiten, die niemand mehr sauber erklären konnte.

Die Idee, Fähigkeiten über Services zugänglich zu machen, war nicht absurd. Im Gegenteil: Viele moderne Architekturformen stehen auf Ideen, die man auch in service-orientierten Ansätzen wiederfindet. Lose Kopplung. Vertragliche Schnittstellen. Wiederverwendbare Fähigkeiten. Klare Verantwortungen. Technische Entkopplung.

Services sind nicht das Problem.

Zentrale Intelligenz ist das Problem.

Der alte SOA-Reflex ist gefährlich

In der wirtschaftlichen Praxis wurde aus SOA oft etwas anderes als das schöne Architekturversprechen.

Aus fachlicher Orientierung wurde Service-Inventur. Aus Entkopplung wurde zentrale Integrationslogik. Aus Wiederverwendung wurde ein Abhängigkeitsnetz. Aus Architektur wurde Governance. Aus Wissen wurde Expertenmonopol.

Das ist der Teil, der 2026 gefährlich ist.

Wenn ein Legacy-Monolith nicht mehr lieferfähig ist, hilft es wenig, ihn einfach in technisch benannte Services zu zerlegen und dann eine zentrale Integrationsschicht darüberzulegen. Dann ist der Monolith nicht verschwunden. Er hat nur seine Form geändert.

Vorher war er ein deploybares Problem. Nachher ist er ein verteiltes Problem mit Meeting-Serie.

Ein schlechter Schnitt erzeugt Services, aber keine Autonomie. Dann hat man keinen modernen Systemverbund. Dann hat man einen verteilten Monolithen mit besserem Merchandising.

Die alte Kritik kam nicht aus dem Nichts

Bereits Ende der 2000er wurde SOA deutlich kritischer gesehen. Eine Burton-Group-Studie, später häufig im Gartner-Kontext zitiert, kam sinngemäß auf „nur 1 von 5 SOA-Projekten erfolgreich“. Die berichteten Zahlen: ungefähr die Hälfte klare Fehlschläge, weitere rund 30 Prozent weder klar erfolgreich noch komplett gescheitert. Also grob nur 20 Prozent eindeutig erfolgreich.

Das ist keine Naturkonstante. Es ist auch kein Beweis, dass jede service-orientierte Architektur scheitern muss.

Aber es ist ein Warnsignal.

Ein 2014er Paper zu SOA Governance griff diese Burton-Group-Zahl wieder auf und verwies ebenfalls darauf, dass nur eines von fünf SOA-Projekten tatsächlich erfolgreich gewesen sei. Interessant ist daran weniger die exakte Prozentzahl. Interessant ist, dass SOA offenbar nicht am Mangel an Tools, Standards oder Diagrammen litt.

SOA litt oft daran, dass Organisationen ihre eigenen Abhängigkeiten nicht ernst genug nahmen.

Noch deutlicher wird es beim ROI. Gartner wurde 2009 damit zitiert, dass viele SOA-Initiativen ihren Return on Investment nicht sauber maßen: Rund 40 Prozent der SOA-Nutzer maßen demnach nicht, wann ROI erreicht wird. Bei Nicht-Anwendern konnte etwa die Hälfte den Business Value nicht artikulieren oder belegen.

Das ist hart.

Wenn man den Business Value nicht erklären oder messen kann, baut man keine Architektur. Man baut ein Integrationsprogramm mit Hoffnungsschimmer.

Bus-Faktor mit Enterprise-Vokabular

Meine Erfahrung mit SOA-Landschaften ist nicht, dass dort niemand klug war. Im Gegenteil.

Oft waren dort sehr kluge Leute unterwegs. Zu klug für das System.

Ein paar Architekten wussten, warum Service A mit Service B über Route C spricht. Ein paar Integrationsspezialisten wussten, welche Transformation im ESB wirklich entscheidend ist. Ein paar alte Hasen wussten, warum das zentrale Datenmodell an genau dieser Stelle nicht angefasst werden darf.

Und wenn diese Leute gingen, krank wurden oder vom sprichwörtlichen Bus erwischt wurden, stand das System zwar technisch noch da.

Aber fachlich verstand es kaum noch jemand.

Das war Bus-Faktor als Architekturprinzip. Nur mit Enterprise-Vokabular.

Man hatte kein robustes System. Man hatte ein Wissensmonopol mit SLA.

Das ist keine Entkopplung. Das ist Zentralisierung von Verständnis.

Moderne Migration fragt anders

Moderne Architektur sollte nicht zuerst fragen:

Wie sieht das brillante Zielsystem aus?

Sie sollte zuerst fragen:

Welche Teams müssen welche fachlichen Entscheidungen unabhängig treffen können?

Das ist ein anderer Denkmodus.

Teamautonomie ist wichtiger als abstrakte Systemschönheit. Ein guter Schnitt erlaubt einem Team, fachlich sinnvoll zu ändern, zu testen und zu deployen, ohne fünf andere Teams zu synchronisieren. Ein schlechter Schnitt sieht im Diagramm sauber aus, erzeugt aber in der Realität Abstimmungsbedarf, Ticketketten, Release-Koordination und Integrationsangst.

Architektur muss an Lieferfähigkeit gemessen werden, nicht an Diagramm-Schönheit.

Darum ist der Strangler-Fig-Ansatz als Gegenbild so wichtig. Nicht, weil der Name hübsch ist. Strangler Fig ist kein romantisches Naturbild. Es ist ein Gegenmittel gegen Big-Bang-Architektur.

Die Idee: Man ersetzt den Monolithen nicht in einem großen heroischen Umbau. Man legt neue Funktionalität um das alte System, zieht einzelne Flows heraus, kapselt fachliche Bruchlinien, lernt aus realer Nutzung und macht den alten Monolithen schrittweise kleiner.

Das ist weniger spektakulär als eine Zielarchitektur-Präsentation.

Aber es hat einen Vorteil: Es kann funktionieren.

EDA ist kein Zauberstab, aber ein besserer Denkmodus

2026 sprechen wir häufiger über Event-driven Architecture, fachliche Events, lose Kopplung, autonome Teams und unabhängige Veränderbarkeit.

Gut so.

Aber bitte nicht naiv.

EDA löst nicht magisch alle Probleme. Events bringen eigene Schmerzen mit: Debugging, Event-Versionierung, Schema-Evolution, Konsistenzmodelle, Observability, fachliche Koordination, Reprocessing, Ownership. Wer Events ohne Disziplin einführt, baut keine moderne Architektur. Er baut Logfile-Bingo mit Kafka.

Trotzdem ist der Denkmodus interessant.

EDA ist nicht modern, weil Events cooler klingen als Services. EDA ist interessant, wenn fachliche Ereignisse echte Autonomie ermöglichen.

Ein gutes Event sagt nicht: „Datensatz 4711 wurde geändert.“

Ein gutes Event sagt fachlich etwas aus:

• Rechnung wurde freigegeben.
• Bestellung wurde storniert.
• Mitgliedschaft wurde aktiviert.
• Zahlung ist fehlgeschlagen.
• Prüfung wurde abgeschlossen.

Solche Events können Kontextgrenzen respektieren. Sie erlauben anderen fachlichen Bereichen zu reagieren, ohne dass eine zentrale Integrationsintelligenz jede Entscheidung orchestriert.

Das ist der Unterschied.

Nicht zentrale Steuerung. Sondern fachliche Verantwortungen, die über stabile Ereignisse miteinander kommunizieren.

Der DRY-Reflex ist Teil des Problems

Viele SOA-Landschaften liebten Wiederverwendung.

Zentrale Modelle. Zentrale Schemas. Zentrale Services. Gemeinsame Datentypen. Einmal definiert, überall genutzt.

Klingt effizient.

Ist oft gefährlich.

Denn Wiederverwendung kann Kopplung sein, die sich als Effizienz verkleidet. Gerade bei fachlichen Modellen ist geteiltes Modellwissen nicht automatisch ein Gewinn. Es kann bedeuten, dass mehrere Fachlichkeiten an einem gemeinsamen Begriff ziehen, bis er niemandem mehr gehört.

Vaughn Vernon hat im DDD-Kontext sinngemäß daran erinnert, dass DRY nicht einfach „keine doppelte Codezeile“ bedeutet, sondern vor allem „Don’t repeat knowledge“. Es geht um Wissen, nicht um kosmetische Duplikate.

Manchmal ist ein eigenes Modell pro fachlichem Kontext sauberer als ein zentrales Modell, das alle benutzen und niemand verantwortet.

Geteilte Modelle sind kein Architekturpreis. Sie sind eine Haftung, die man bewusst eingeht.

Warnsignale für SOA-Reflexe

Wenn bei einer Monolith-Migration einer dieser Sätze fällt, sollte man genauer hinhören:

• „Wir definieren zuerst die Zielarchitektur.“
• „Wir brauchen ein zentrales Datenmodell.“
• „Das Team kann das Feature bauen, aber die Integration macht ein anderes Team.“
• „Alle Services laufen über eine zentrale Schicht.“
• „Wiederverwendung ist unser Hauptziel.“
• „Die Fachlichkeit schneiden wir später.“
• „Events sind bei uns technische Änderungsnachrichten.“
• „Deployment ist verteilt, Entscheidungen aber zentral.“
• „Nur zwei Leute verstehen die Integrationslogik.“

Jeder einzelne Satz kann in einem bestimmten Kontext erklärbar sein.

Zusammen ergeben sie ein Muster.

Und dieses Muster heißt nicht Modernisierung. Es heißt Rückfall.

Was man stattdessen tun sollte

Einen Legacy-Monolithen sollte man nicht zuerst technisch schneiden. Man sollte fachliche Bruchlinien suchen.

Wo ändert sich das System häufig? Wo entstehen fachliche Konflikte? Wo haben Teams heute Wartezeiten? Wo ist Datenhoheit unklar? Wo müssen Releases koordiniert werden? Wo verhindert Kopplung echte Produktentwicklung?

Daraus entstehen bessere Architekturfragen:

• Welche fachliche Verantwortung kann ein Team wirklich besitzen?
• Welche Daten gehören zu dieser Verantwortung?
• Welche Entscheidungen kann dieses Team unabhängig treffen?
• Welche Schnittstellen braucht es nach außen?
• Welche Events drücken echte fachliche Tatsachen aus?
• Welche Teile des Monolithen können inkrementell stranguliert werden?
• Welcher Business Value entsteht durch den Schnitt?
• Welches Risiko wird reduziert?
• Welche Lieferfähigkeit wird verbessert?

Neue Services sollte man nur dort bauen, wo Verantwortung, Datenhoheit und Änderungsdruck zusammenpassen.

EDA sollte man nur dort einsetzen, wo fachliche Ereignisse wirklich lose Kopplung ermöglichen.

Ein zentrales Datenmodell sollte man nicht als Allheilmittel betrachten.

Shared Models sollte man skeptisch prüfen.

Integration darf nicht zum neuen Monolithen werden.

Und Architekturwissen darf nicht auf drei Leute verteilt sein, die alle nie gleichzeitig Urlaub machen dürfen.

„Service-oriented“ muss 2026 mehr bedeuten

Wer 2026 „service-oriented architecture“ sagt, sollte sehr genau erklären, was gemeint ist.

Wenn damit gemeint ist: fachliche Verantwortungen, klare Ownership, autonome Teams, stabile Schnittstellen, unabhängige Veränderbarkeit — gut. Dann reden wir über etwas Sinnvolles.

Wenn damit gemeint ist: zentrale Integrationsschicht, zentrales Datenmodell, Service-Katalog, Governance-Board, technische Wiederverwendung und Zielarchitektur-Theater — dann ist es ein Warnsignal.

SOA war nicht dumm. Aber der alte SOA-Reflex ist gefährlich.

Services retten keinen Monolithen, wenn die Organisation weiterhin zentral denkt. Verteiltes Deployment ist keine verteilte Verantwortung. Technische Services sind keine fachliche Autonomie. Und ein Integrationshub ist kein Architekturmodell, nur weil er viele Pfeile anzieht.

Der eigentliche Test ist einfach:

Kann ein Team eine fachliche Änderung verstehen, bauen, testen und deployen, ohne erst eine halbe Organisation zu synchronisieren?

Wenn nein, ist die Architektur nicht autonom. Egal, wie viele Services sie hat.

SOA scheiterte selten an Services. SOA scheiterte daran, dass Unternehmen zentrale Intelligenz für Architektur hielten.

Wer 2026 einen Monolithen zerlegt, sollte deshalb nicht fragen, wie viele Services entstehen.

Er sollte fragen, wie viel fachliche Autonomie entsteht.