Teil 4. Warum SOA so oft gescheitert ist – und was wir heute daraus lernen können
Ein ehrlicher Blick auf ein vielversprechendes Paradigma, das in der Realität an falschen Annahmen litt.
Die Serviceorientierte Architektur (SOA) galt über viele Jahre hinweg als Hoffnungsträger der IT. Wiederverwendbare Services, lose Kopplung, modulare Architekturen – das klang nach der perfekten Lösung für viele Unternehmensprobleme. Doch nach den ersten großen Implementierungen zeigte sich Ernüchterung.
Viele SOA-Projekte hielten nicht, was sie versprachen.
Einige wurden überkomplex, andere scheiterten völlig – und manche hinterließen schwer wartbare Landschaften.
Der berühmte Blogbeitrag „SOA is Dead“ von Anne Thomas Manes markierte einen Wendepunkt. Doch warum kam es überhaupt so weit?
Die gute Nachricht: SOA war nicht das Problem.
Die schlechte: Wir haben es falsch angewendet.
Die Idee hinter SOA war brillant:
Systeme kommunizieren über standardisierte Services.
Services sind wiederverwendbar.
Anwendungen werden modular.
Prozesse lassen sich aus Services zusammensetzen.
In der Theorie perfekt – in der Praxis häufig fehlgeleitet.
Fehler 1: SOA wurde bottom-up implementiert
Viele IT-Teams begannen damit, Services zu entwickeln, die möglichst flexibel und universal einsetzbar sein sollten.
Das führte zu:
übergenerischen Schnittstellen
monströsen Datenstrukturen
Services, die in keinem Prozess wirklich passten
Architekturen, die zwar technisch „sauber“, aber fachlich unbrauchbar waren
Der Fokus lag auf Technologie – statt auf den Geschäftsprozessen, die man eigentlich unterstützen wollte.
SOA wurde zur technischen Übung statt zur fachlichen Lösung.
Fehler 2: Synchrone Remote Calls wurden wie lokale Aufrufe behandelt
Eine der grundlegendsten Fehleinschätzungen war die Annahme, dass entfernte Services genauso stabil funktionieren wie lokale Methodenaufrufe.
Doch das stimmt nicht.
Remote Calls sind:
langsam
fehleranfällig
komplex
abhängig von Netzwerkstabilität
problematisch bei Lastspitzen
Die Konsequenz:
Statt lose gekoppelten Systemen entstanden hart gekoppelte verteilte Monolithen.
Fehler 3: Integration wurde unterschätzt
Viele SOA-Initiiativen setzten ausschließlich auf synchrone Webservices für die Kommunikation. Doch echte Unternehmenslandschaften bestehen aus:
heterogenen Systemen
Legacy-Software
externen Partnern
cloudbasierten Services
Datenmodellen, die sich ständig ändern
SOA ignorierte die Realität – prozessgesteuerte Anwendungen berücksichtigen sie.
Fehler 4: Die Prozesssicht fehlte
SOA fokussierte auf Services – nicht auf Prozesse.
Doch Prozesse sind es, die Unternehmen differenzieren und Wert schaffen.
Wenn ein Prozess nicht im Zentrum der Architektur steht, entsteht eine Sammlung technischer Bausteine – aber keine geschäftsrelevante Lösung.
Was wir heute anders machen müssen
Moderne Architekturen – insbesondere prozessgesteuerte Anwendungen – haben aus den Schwächen der SOA gelernt.
Die wichtigsten Erkenntnisse:
Prozesse müssen die Architektur treiben (Top-Down)
Services sind Mittel zum Zweck – nicht das Ziel
Lose Kopplung gelingt nur mit intelligenter Integration
Asynchrone Muster sind oft überlegen
Fachliche und technische Prozesse müssen getrennt werden
BPMN schafft Transparenz und Änderungsfähigkeit
SOA war der richtige Ansatz – aber nicht der letzte Schritt.
Fazit
SOA hat viel Wertvolles gebracht, aber auch gezeigt, wo die Grenzen rein technischer Ansätze liegen. Die Zukunft liegt nicht in mehr Services, sondern in besseren Architekturen. Architekturen, die fachlich getrieben sind, flexibel bleiben und technische Komplexität sinnvoll kapseln.
Und genau das leisten prozessgesteuerte Anwendungen.
Im nächsten Beitrag widmen wir uns deshalb einer zentralen Frage:
Was genau macht prozessgesteuerte Anwendungen aus – und warum sind sie der logische nächste Evolutionsschritt?
Quelle / Ursprung
Dieser Blogbeitrag basiert auf Inhalten aus dem Buch
„Prozessgesteuerte Anwendungen entwickeln und ausführen mit BPMN:
Wie flexible Anwendungsarchitekturen wirklich erreicht werden können“
von Prof. Dr. Volker Stiehl.