Service-orientierte Architektur (SOA) ist ein Architekturparadigma, bei dem Softwarefunktionen als eigenständige, wiederverwendbare Services bereitgestellt werden, die über standardisierte Schnittstellen kommunizieren. SOA wurde in den frühen 2000er Jahren als Antwort auf die Inflexibilität monolithischer Enterprise-Systeme entwickelt und war der Vorläufer der modernen Microservice-Architektur.
Das Grundprinzip ist dasselbe: Funktionalität als Services kapseln, die über definierte Schnittstellen genutzt werden können – unabhängig von der internen Implementierung. SOA wurde typischerweise im Enterprise-Umfeld mit dem Enterprise Service Bus (ESB) als Kommunikations-Backbone eingesetzt und nutzte häufig SOAP und XML als Protokolle.
SOA vs. Microservices
SOA (klassisch)
- Enterprise-fokussiert
- Zentral orchestriert (ESB)
- Schwergewichtig (SOAP/XML)
- Große, fachlich orientierte Services
- Geteilte Datenbanken üblich
- Governance-intensiv
Microservices (modern)
- Cloud-native, skalierend
- Dezentral orchestriert
- Leichtgewichtig (REST/JSON, Events)
- Kleine, technisch abgegrenzte Services
- Eigener Datenspeicher je Service
- Team-Autonomie betont
Gemeinsamkeiten und gemeinsame Prinzipien
SOA und Microservices teilen denselben Kern-Gedanken: Loose Coupling (lose Kopplung zwischen Services), High Cohesion (hohe Kohäsion innerhalb eines Services), Wiederverwendbarkeit und klar definierte Schnittstellen. Der Unterschied liegt weniger im Prinzip als in der Umsetzung: SOA tendiert zu schwergewichtigen, zentralisierten Strukturen; Microservices zu leichtgewichtigen, dezentralisierten. In der Praxis sind viele Enterprise-Architekturen hybride: SOA-Strukturen für Legacy-Integration, Microservices für neue digitale Services.
SOA-Prinzipien in der Automatisierung
Die Prinzipien der SOA sind direkt auf Automatisierungsarchitekturen übertragbar: Automation-Services sind wiederverwendbare Workflows mit klar definierten Eingaben und Ausgaben, die über standardisierte Schnittstellen (Webhooks, APIs) aufgerufen werden können. Die Automationsplattform übernimmt die Rolle des Orchestrators – analog zum ESB in klassischen SOA-Architekturen, aber deutlich leichtgewichtiger und agiler.
SOA und Microservices sind keine konkurrierenden Architekturen, sondern aufeinander aufbauende Evolutionsstufen desselben Grundgedankens: Komplexität durch Dekomposition beherrschbar machen. Wer SOA versteht, versteht den konzeptionellen Ursprung von Microservices – und wer Microservices versteht, erkennt in vielen modernen Automationsarchitekturen die SOA-Prinzipien in leichtgewichtiger Form wieder.
Praxisbeispiel
Ein Versicherungskonzern betreibt seit 2009 eine klassische SOA-Architektur: 14 Enterprise Services (Kundenstammdaten, Vertragsverwaltung, Schadensabwicklung etc.), orchestriert über einen IBM ESB, kommunizierend per SOAP/XML. Neue digitale Projekte (Kundenportal, App, Chatbot) nutzen diese Services über den ESB – aber die Integrationszeiten von 4–8 Wochen pro neuer Service-Anbindung bremsen die Agilität. Lösung: Adapter-Schicht über den ESB, die die SOAP-Services als REST/JSON exponiert. Neue digitale Services können nun in Tagen statt Wochen integriert werden. SOA bleibt als stabiles Backbone für Kernsystemintegration – ergänzt durch eine modernere, API-first Schicht für neue Initiativen.
