Während sich unter dem Schlagwort Service Oriented Architecture (SOA) vor zwei Jahren nur einige Wenige etwas vorstellen konnten bzw. dieser als Treiber für die Ausrichtung neuer Produktstrategien diente, hat man heute schon eine konkretere Vorstellung von dem Begriff SOA. Erstmals kam ich mit dem Begriff in Kontakt, als ich “ganz begeistert” von der “Defragmentierung der Wetschöpfungskette” in einem Papier von Prof. Scheer las. Zeitgleich kam bei mir die neue SAP-NetWeaver-Strategie ins Visier. Ich war sehr interessiert daran, weil SAP zu erkennen gab, das sich die NetWeaver-Strategie der Java-Welt öffnet. Im Zusammenhang mit der Auseinandersetzung der SAP-NetWeaver-Strategie fiel auch immer wieder der Begriff serviceorientierte Architektur bzw. ESA (Enterprise Service Architecture). Zwischenzeitlich gibt es die ersten “SOA-Produkte” namhafter Hersteller wie IBM, BEA, SAP, ORACLE, …. Googelt man nach SOA-Definitionen findet man viel. Weiter hört und liest man, ein Unternehmen muss SOA-ready sein! Außerdem sei SOA erst in zweiter Linie ein technisches Konzept bzw. Systemarchitekturkonzept und vorrangig ein Managementkonzept?

Was aber ist eine SOA nun? Nun, rein radikal-konstruktivistisch müsste ich ja antworten: “Genau das, was der Betrachter darin sieht”. Deshalb schildere ich in meinem Beitrag meine eigene Konstruktion zur Reflektion nach außen (Kommentare willkommen). Um meinen Beitrag etwas zu strukturieren, will ich ihn wie folgt aufbauen:

  1. Wozu eine SOA (Anforderungen des Managements für die Daseinsberechtigung einer SOA)?
  2. Was ist eine SOA und aus welchen Komponenten besteht eine SOA?
  3. Wie wird eine SOA implementiert?

Wozu braucht man (oder das Unternehmen/Management) eine SOA?

Nun, wie wir alle wahrscheinlich schon mal erfahren bzw. am eigenen Leib gespürt haben, sind wir schon einmal in einen “Geschäftsprozess geraten”, einen sogenannten Standardprozess. Er dient dazu sich oft wiederholende Vorfälle standardisiert und mehr oder weniger effizient abzuarbeiten (eigentlich sollten Sie effizient sein, oft stellt sich aber das Gegenteil heraus). Genug der Ironie – auf jeden Fall liegen diese Prozesse, insbesondere in Großunternehmen, haufenweise vor. “Mal eben” durchführen ist nicht, “Wir halten uns an die Standardprozesse”. Somit habe ich schon oft die Aussage gehört “Wir sind unbeweglich wie ein Tanker oder ein Elefant”. Eingeführt wurden Standardprozesse im Industriezeitalter für die Herstellung von Massengütern. Heute finden wir Standardprozesse auch im Dienstleistungsbereich, bei der Bahnauskunft, in Callcentern, … überall Prozesse …. Ein nach außen gerichteter Kunden-Prozess dient also als “Schnittstelle” zwischen Unternehmen und Außenwelt, um möglichst effizient sich wiederholende Vorgänge möglichst wirtschaftlich abzuarbeiten.ddd Das Problem ist nur, das sich die Umwelt um uns herum und marktwirtschaftlich betrachtet der Markt immer schneller ändert. Hier haben kleine Unternehmen gegenüber den Großkonzernen enorme Vorteile. Kleinere Unternehmen können sich schneller, fluider an den Markt anpassen und Angebote anbieten. Das können gewachsen Großunternehmen mit all ihren Strukturen und eingeschliffenen Prozessen nur schwer. Man beobachte dies derzeit in der Telekommunikationsbranche: Festnetz-Flat über VoIP, Handy-Flat mit einfachen, schlichten, transparenten Tarifen. Da kommt der ein oder andere Tanker ganz schön ins Schwitzen beim Gegensteuern :-) Einige größere Vögel aus dem Festnetzgeschäft mussten auch schon “ordentlich Federn” lassen. Das Problem ist eigentlich, das sich die Anforderungen des Marktes, schneller verändern als wir die IT-Systeme anpassen können.

Der Markt verändert sich schneller als wir Informationstechnologie anpassen können. 

IT-Systeme haben mittlerweile eine unglaubliche Komplexität, die fast nicht mehr zu managen ist. Hier ein paar Schlagworte aus der IT-Welt, um die Prozesse um die Softwareentwicklung anzureißen: Sich ändernde fachliche Anforderungen durch neue Strategien/Marktveränderungen, sich ändernde Datenstrukturen, Change-Management-Prozesse, Incident- und Problemmanagement (ITIL), Paketierungsplanung für die Releases, Projektmanagement/Ressourcenmanagement, Offshoring, Nearshoring, viele Standards (XML, SOA, MBA, J2EE, SOAP, …), Spezialprodukte, Mehrsystemelandschaften (Entwicklung, Test & Abnahme, Konsolidierung, Produktion), ….

Hier liegt der Wunsch nah, IT-Landschaften zu haben, die sich entsprechen schnell und “fluide” an die Umwelt anpassen können, und zwar in Form von Services, die nach dem Paradigma der “losen Kopplung” miteinander kombinierbar sind. Der “Prozessring”, welcher die Schnittstelle zwischen Unternehmen und Außenwelt darstellt muss also “fluide” werden, sich schnell anpassen können.Fluides Unternehmen Das “Unternehmen wird geschmeidig”, es passt sich seinen Kunden an.

Aus kybernetischer Sicht betrachte ich ein solches “fluides” Unternehmens-System als ein autopoietisches System, welches sich selbständig an seine Umwelt anpassen kann. Dies kann SOA jedoch im Sinne der Autopoesis nicht leisten, da sich SOA aus der Managementsicht nur auf die Prozesse und aus technischer Sicht auf die IT konzentriert.

Aber zurück zur SOA. Eine serviceorientierte Architektur zerlegt Prozesse in kleinere Services. Die Services sind lose gekoppelt und haben deshalb eine sehr hohe Wiederverwertbarkeit. Prozesse können kombiniert werden, Services innerhalb eines Prozesses können ausgetauscht werden. Dies gilt natürlich auch für die die inneren Prozesse eines Unternehmens, die sich durch Strukturveränderungen anpassen müssen. Ein weiterer “Charme” für Manager und Vorstände dürfte darin liegen, das eine funktionierdende SOA Mergers und Konsolidierungsprozesse bei Fusionen vereinfachen und beschleunigen soll. Schließlich brauche ich nach der Theorie “nur noch” die Services identifizieren welche ich benötige. Redundante Services werden konsolidiert. Bis dahin, wenn dies überhaupt jemals gelingt, dürfte es allerdings noch ein weiter Weg sein …

Zusammenfassend würde ich folgende Punkte anbringen, die eine SOA verspricht:

  1. Schnellere und wirtschaftliche Anpassung der Prozesse an die Marktanforderungen
  2. Schnellere und wirtschaftliche Anpassung der Prozesse bei Fusionen/Merger/Unternehmenskonsolidierungen

Im nächsten Beiträg möchte ich etwas näher darauf eingehen aus welchen Basiskomponenten eine SOA besteht und was deren Funktionen sind (Service-Repository, Process-Repository, Process-Engine, Presentation-Engine, BPEL, Enterprise Service Bus).

SOA Links:

  1. Präsentation Wolfgang Martin-Team 
  2. Technische Standards am W3C
  3. OASIS – Organization for the Adwancement of Structured Information Standards
  4. BPEL – Business Process Execution Language