Wahrscheinlich hat jeder, der sich mit moderner Software-Architektur mittelbar oder unmittelbar beschäftigt (oder beschäftigen muss) schon mal was von Service Oriented Architecture oder kurz SOA gehört. Mir ist dieser Begriff das erste Mal über den Weg gelaufen, als ich gezwungen war Excel-basierte Auswertungen einer Bank in ein Business-Intelligence-System zu bringen, um es Kunden und Bankmitarbeitern möglichst ohne Zeitverzögerung zur Verfügung zu stellen.
Anfang der 2000er wurde SOA als Idee eingeführt, Geschäftsprozesse als technische Services zu implementieren, um sie flexibel miteinander verbinden zu können. Die Hoffnung war, dass heterogene Systemlandschaften, wie sie heute in allen Unternehmen existieren, flexibel und unaufwendig miteinander verbinden zu können.
Zu dieser Zeit wurde ein richtiger Hype ausgelöst und viele, sehr große SOA-Projekte ins Leben gerufen. Die Protagonisten und Berater sind durch die Lande gezogen und riefen:
„Nur noch ein paar Monate und Ihr braucht Eure Daten nicht mehr per E-Mail und Excel-Sheets auszutauschen. Sie liegen dann aufbereitet morgens auf Eurem Schreibtisch.“
Die Projekte legten los und produzierten noch mehr E-Mails und Excel-Sheets. Daraufhin wurde 2009 SOA für tot erklärt.
(K)eine gemeinsame Sprache
Es dauerte einige Zeit bis alle Beteiligten verstanden, warum sich eine so brillante Idee nicht durchsetzen konnte. Die Geschäftsprozesse waren in ihren Details nicht bekannt und konnten somit nicht in einer Form modelliert werden, dass sie komplett technisch abbildbar war. Techniker konnten die Anforderungen der Modellierer nicht erfüllen, da es an geeigneten und gut definierten Schnittstellen fehlte. Das wichtigste aber war, dass Techniker und Geschäftsprozess-Modellierer (noch) keine gemeinsame Sprache fanden.
Heute hat sich SOA als Entwurfsprinzip in der Software-Architektur durchgesetzt. Es ist mittlerweile so selbstverständlich geworden, dass die Beteiligten es noch nicht mal für nötig erachten, ihr Software-Design SOA zu nennen, auch wenn es SOA ist. Wir modellieren Prozesse und benutzen dabei technische Services, die gemäß den Geschäftsanforderungen geschnitten sind. Wir benutzen wie selbstverständlich BPMN und Komponenten. Standardisierte Schnittstellen sind für uns flexibel und verlässlich benutzbar.
Es lebe SOA!
