Ein kritischer Rückblick auf ein Architekturparadigma, das zwar vielversprechend war, aber in der Praxis oft an unrealistischen Erwartungen scheiterte.
Über Jahre hinweg galt die Serviceorientierte Architektur (SOA) als Revolution der IT. Die Versprechen klangen verlockend: Services, die sich mehrfach nutzen lassen, Systeme mit lockerer Bindung und flexible, modulare Strukturen. Das sollte die Antwort auf zahlreiche IT- Herausforderungen in Unternehmen sein. Doch die Realität holte viele Projekte ein.
Zahlreiche SOA-Initiativen blieben hinter den Erwartungen zurück. Manche wurden zu komplex, andere kollabierten komplett – und nicht wenige hinterliessen Systeme, die kaum mehr zu warten waren.
Der bekannte Blogpost «SOA is Dead» von Anne Thomas Manes wurde zum Wendepunkt. Aber warum kam es überhaupt dazu?
Das Konzept war richtig – die Ausführung war es oft nicht
Die positive Erkenntnis: SOA an sich war nicht das Problem.
Die ernüchternde Wahrheit: Wir haben es falsch umgesetzt.
Die Grundidee der SOA war überzeugend:
- Systeme tauschen Daten über standardisierte Services aus.
- Services können wiederverwendet werden.
- Anwendungen werden in Module aufgeteilt.
- Prozesse können aus verschiedenen Services zusammengebaut werden.
In der Theorie klang das einwandfrei – in der Realität ging vieles schief
Irrtum 1: Bottom Up statt Top Down Vorgehen
Viele IT-Abteilungen starteten damit, Services zu entwickeln, die möglichst universell und flexibel sein sollten
Das Resultat:
- Schnittstellen, die zu allgemein waren
- Riesige, komplizierte Datenmodelle
- Services, die in keinem konkreten Prozess richtig passten
- Architekturen, die technisch korrekt, fachlich aber nutzlos waren
Der Fokus lag auf der Technologie – nicht auf den Geschäftsprozessen, die eigentlich unterstützt werden sollten.
SOA mutierte zur technischen Fingerübung statt zur fachlichen Lösung.
Irrtum 2: Remote Calls wurden wie lokale Aufrufe behandelt
Eine der gravierendsten Fehleinschätzungen war die Annahme, dass Aufrufe über Netzwerk genauso zuverlässig funktionieren wie Methodenaufrufe innerhalb derselben Anwendung.
Doch das stimmt nicht.
Netzwerkaufrufe sind:
- langsamer
- anfälliger für Fehler
- komplexer
- abhängig von der Netzwerkqualität
- problematisch bei hoher Last
Die Folge: Anstatt lose gekoppelter Systeme entstanden eng verkoppelte verteilte Monolithen.
Irrtum 3: Die Komplexität der Integration wurde unterschätzt
Viele SOA-Projekte setzten ausschliesslich auf synchrone Webservices als Kommunikationsweg.
Doch reale Unternehmenslandschaften sind vielfältiger:
- unterschiedliche Systeme
- Altsysteme
- externe Partner und Dienstleister
- Cloud Services
- Datenmodelle, die sich ständig weiterentwickeln
SOA ignorierte diese Realität – prozessgesteuerte Anwendungen berücksichtigen sie hingegen.
Irrtum 4: Der Prozess stand nicht im Zentrum
SOA konzentrierte sich auf Services – nicht auf Prozesse. Doch genau Prozesse sind es, die Unternehmen von anderen unterscheiden und Mehrwert schaffen.
Wenn der Prozess nicht die Architektur bestimmt, entsteht eine Ansammlung technischer Komponenten – aber keine geschäftsrelevante Lösung.
Was heute anders gemacht werden muss
Moderne Architekturen – insbesondere prozessgesteuerte Anwendungen – haben aus den Schwächen von SOA gelernt.
Die zentralen Lektionen:
- Prozesse müssen die Architektur von oben nach unten bestimmen (Top Down)
- Services sind Mittel zum Zweck – nicht das eigentliche Ziel
- Lose Kopplung funktioniert nur mit durchdachter Integration
- Asynchrone Muster sind häufig die bessere Wahl
- Fachliche und technische Prozesse müssen klar getrennt sein
SOA war der richtige Ansatz – aber nicht der Endpunkt.
Fazit
SOA hat uns wichtige Erkenntnisse gebracht, aber auch aufgezeigt, wo rein technische Ansätze an ihre Grenzen stossen. Die Zukunft liegt nicht in noch mehr Services, sondern in durchdachteren Architekturen. Architekturen, die vom Fachbereich getrieben werden, flexibel bleiben und technische Komplexität sinnvoll verbergen.
Und genau das leisten prozessgesteuerte Anwendungen.
Im nächsten Beitrag schauen wir uns deshalb eine zentrale Frage an: Was genau macht prozessgesteuerte Anwendungen aus – und weshalb sind sie die logische Weiterentwicklung?
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.
