So führen Sie SOA und SCM ein

Im Vordergrund einer Service-orientierten Architektur (SOA) steht eine verteilte Softwarearchitektur mit standardisierten Schnittstellen der Anwendungen und Geschäftskomponenten. Mit diesen soll es Unternehmen möglich sein, flexibel und agil auf sich verändernde Marktsituationen zu reagieren. Wie die jeweiligen Dienste im Inneren realisiert sind, bleibt für den Anwender meist intransparent. Durch die Kapselung soll die Unabhängigkeit von Plattformen und Programmiersprachen gewährleistet werden. SOA bietet damit die Möglichkeit, sowohl einfache und zusammengesetzte Dienste als auch Altanwendungen in eine einheitliche IT-Landschaft zu integrieren. Doch so viel versprechend der Ansatz der flexiblen Prozessunterstützung durch die Verwendung und Operationalisierung des SOA-Paradigmas sein mag, so groß sind dabei die Herausforderungen.

Mehr zum Thema SOA und Business-Process-Management im CW-Experten-Blog SOA meets BPM.

Problem 1: Funktionale Integration

Die Flexibilität im Rahmen des SOA-Ansatzes, die sich durch die technische Austauschbarkeit der jeweiligen verteilten Services ergibt, unterliegt unterschiedlichen Restriktionen (siehe auch: SOA Checkliste) Neben den betriebswirtschaftlich sinnvollen ablauforientierten Anordnungen gegebener Services müssen Projektverantwortliche vor allem den Bereich der betriebswirtschaftlich funktionalen Integration stärker beleuchten. Das bedeutet, dass die von einem Service gekapselte oder aufgerufene Funktion genau die Anforderungen erfüllt, die aus dem Prozessablauf erwachsen. Insbesondere bei neu zu einer Servicelandschaft hinzukommenden Services ist die Überprüfung auf die funktionale Integration unter betriebswirtschaftlichen Aspekten neben einer technischen Kontrolle wichtig. Analog dazu müssen Prozesse im Rahmen einer Neuorchestrierung bestehender Dienste im Zuge von Änderungen im Geschäftsumfeld auf betriebswirtschaftliche Konsistenz überprüft werden. Diese Konsistenzprüfung umfasst einerseits die betriebswirtschaftliche Ablauflogik, andererseits die fachlichen Abhängigkeiten zwischen den einzelnen Services, die im Rahmen der Prozessausführung orchestriert werden und gegebenenfalls auch Auswirkungen auf andere Prozesse (und die damit verbundenen Services) haben können. Diese Überprüfung lässt sich derzeit noch nicht automatisch vornehmen, sondern erfolgt manuell im Zuge der Service-Orchestrierung durch einen Modellierer.

Problem 2: IT-Organisation

Die technische Innovation bringt aber auch eine organisatorische Änderung im Arbeitsablauf der IT-Abteilung mit sich. Nicht mehr die reine Schnittstellendefinition und Programmierung ist die tägliche Arbeitsaufgabe der Mitarbeiter in den IT-Abteilungen, sondern die Steigerung der Prozessleistung in den Fachabteilungen. IT-Verantwortliche müssen zukünftig ein profundes Know-how im Prozessmanagement besitzen und sich immer tiefer in die fachlichen Prozessmodelle eindenken, um auch betriebswirtschaftliche Abhängigkeiten zu verstehen. Um diese Ausweitung der notwendigen Fähigkeiten einer IT-Abteilung betriebswirtschaftlich sinnvoll darstellen zu können, müssen Unternehmen ihre IT-Organisation anders strukturieren: Einerseits in IT-Fachabteilungen, die als Schnittstelle zwischen den organisatorischen Fachabteilungen und der zentralen IT-Abteilung dienen; andererseits in die dahintergelagerte zentrale IT-Abteilung.

Den IT-Fachabteilungen kommen dabei entscheidende Aufgaben für die betriebliche Umsetzung einer SOA zu. Sie übersetzen die Anforderungen der Fachabteilungen in das im Unternehmen benutzte Metamodell zur funktionalen Servicebeschreibung. In diesem werden den einzelnen betrieblichen Funktionen unternehmensweit Begriffe zur fachlichen Funktionsbeschreibung zugeordnet. Darüber hinaus prüfen die IT-Fachabteilungen, ob nicht ein nutzbarer Service bereits vorhanden ist. Sie leiten gegebenenfalls die Anforderungen an die IT-Abteilung weiter, die dann gemäß der Anforderungen der IT-Fachabteilungen die jeweiligen Services zur Verfügung stellt. Neben der Definition des Metamodells zur funktionalen Servicebeschreibung benötigt das Unternehmen für die Aufteilung der Aufgaben zwischen Fachabteilung (organisatorische Anforderungsbeschreibung), IT-Fachabteilung (Transformation der organisatorischen Anforderungen in technische Beschreibungen) und IT-Abteilung (Umsetzung der technischen Anforderungen) ein Regelwerk. Dieses ist Teil der so genannten SOA-Governance.

Problem 3: Prozess-Management

Die Kombination von informationsorientiertem und betriebswirtschaftlichem Wissen wird das entscheidende Handwerkszeug eines IT-Prozessmanagers. Begleitend hierzu ändern sich aber auch die rein phasenorientierten Vorgehensmodelle im fachlichen Prozessmanagement und vermischen sich mit den iterativen Ansätzen des Prototyping der Systemgestaltung: Konzepte aus der Informatik und den Ingenieurwissenschaften verschmelzen mit betriebswirtschaftlichen Vorgehensweisen.

So ergeben sich bei einer neuen Prozessdefinition und der damit einhergehenden Neu-Orchestrierung der technischen Komponenten verschiedene Szenarien, die im Folgenden näher beleuchtet werden.

1. Die betriebswirtschaftliche Ablaufreihenfolge wird geändert; die neue Sequenz ist aber mit den bestehenden und bereits bekannten Services im Rahmen der SOA des Unternehmens realisierbar. Allerdings muss eine neue Orchestrierung erfolgen. Die notwendige Überprüfung auf betriebswirtschaftliche Plausibilität bleibt aufgrund der bekannten Funktionen der einzelnen Services übersichtlich.

2. Die Reihenfolge der Prozessaktivitäten wird geändert; die neue Anordnung ist aber mit den bestehenden und bekannten Services nicht mehr darstellbar. Stattdessen entscheidet sich das Unternehmen, neue Services selbst zu entwickeln, die die notwendigen betriebswirtschaftlichen Funktionalitäten bereitstellen sollen.

3. Die Reihenfolge der Prozessaktivitäten wird abgeändert; die neue Anordnung ist mit den bestehenden und bekannten Services wieder nicht darstellbar. Stattdessen muss das Unternehmen neue Services extern beziehen.

Innerhalb des ersten Szenarios treten höchstens technische Herausforderungen oder Restriktionen auf, die sich durch diverse Testläufe wie beispielsweise Funktionstests, Systemtests und das so genannte Integration Testing lösen lassen. Die betriebswirtschaftliche Funktionalität der einzelnen Services ist dem Unternehmen aber bereits bekannt. Ferner kann der jeweilige Modellierer des Unternehmens aufgrund der bekannten betriebswirtschaftlichen Funktionalitäten die Abhängigkeiten der einzelnen Services untereinander und die Auswirkung der Ablaufreihenfolge prognostizieren.

Das zweite Szenario lässt sich noch in zwei Unterszenarien unterteilen. Generell gilt dabei aber, dass Schwierigkeiten hinsichtlich der betriebswirtschaftlichen funktionalen Integration der einzelnen Services nicht zwingend zu erwarten sind, da die Services im Unternehmen selbst beschrieben und generiert werden.

Problem 4: SOA-Governance

Die beiden Unterszenarien ergeben sich aus der Nutzung einer SOA-Governance. Dies ist ein unternehmensweit verbindlich gültiges Regelwerk, in dem beispielsweise Authentifizierungs- und Autorisierungsgrundsätze für die Wartung und Entwicklung von Services definiert werden. Darüber hinaus können die Verantwortlichen hier Regeln für den Prozessablauf der Servicedefinition hinterlegen, die Logik des verwendeten Vokabulars für die Beschreibung der betriebswirtschaftlichen Servicefunktionalität definieren und Regeln für die Einbindung externer Services aufstellen. Schließlich umfasst eine SOA-Governance noch Vorgaben bezüglich Verantwortlichkeiten, Rollen und Messmetriken, um die Konsistenz und Transparenz innerhalb einer Service-orientierten Landschaft sicherzustellen.

Wird eine SOA-Governance innerhalb des Unternehmens festgelegt und die Services entsprechend entwickelt, entstehen im Szenario 2 keine unlösbaren Aufgaben. Fehlt hingegen die Definition einer SOA-Governance (und somit zumindest unternehmensweiter Standards für den Umgang und die Konzeption von Services), erwachsen einer Organisation bereits in diesem Szenario große Herausforderungen, die analog zu denen in Szenario 3 sind.

• Das dritte Szenario birgt die größten Probleme für das Unternehmen, da es diverse Fragen aufwirft:

• Existieren überhaupt externe Services, die die notwendigen betriebswirtschaftlichen Funktionen bereitstellen können?

• Kann das Unternehmen die notwendigen betriebswirtschaftlichen Funktionen so darstellen, dass die Anforderungen für andere Serviceanbieter nachvollziehbar sind? Mit welchem Aufwand ist die Entwicklung eines Pflichten- oder Lastenheft verbunden?

• Welche technischen Voraussetzungen existieren und welche nichtfunktionalen Elemente sind zu berücksichtigen - von Governance über Kosten bis hin zu Performance?

• Können diese Services und somit auch ihr Einsatz für das Unternehmen auf betriebswirtschaftlicher Basis überprüft werden?

Problem 5: Standards

Im Rahmen der Operationalisierung und technischen Umsetzung des SOA-Paradigmas haben sich einige defacto Standards herausgebildet, die zumindest einige technische Fragen für das Szenario 3 beantworten. Zu diesen Spezifikationen gehören etwa BPEL, WSDL, SOAP und UDDI. Daneben können Service-Level-Agreements (SLAs), die von Serviceanbietern als weiterführende Informationen zu möglichen Services veröffentlicht werden, untersucht werden. Doch Vorsicht: es gibt kein verbindlicher Standard zur Definition und zum Inhalt von SLAs. Die größte Herausforderung steckt in der funktionalen betriebswirtschaftlichen Überprüfung des jeweiligen Service. Dafür existiert momentan noch keine wirksame und automatisierte Möglichkeit. Bereits für die notwendige semantische Beschreibung der Services fehlen derzeit die Standards, um eine einheitliche und verbindliche Taxonomie oder Ontologie bereitzustellen.

Somit ist die Möglichkeit, Services beliebig auszutauschen, im Rahmen einer SOA für ein Unternehmen heute innerhalb der eigenen IT-Landschaft nur unter bestimmten Voraussetzungen gegeben.

Wie SCM von SOA profitiert

Die theoretische Idee der vollständigen Flexibilität von verteilten Anwendungen, die sich implizit aus dem SOA-Integrationsparadigma ergibt, scheint gerade im Rahmen von Supply-Chain-Management-Ansätzen (SCM) interessant zu sein. Das SCM-Konzept dient zur Steuerung eines mehrstufigen Logistiknetzwerks. Vereinfacht ausgedrückt ist es Aufgabe des SCM, die einzelnen Lieferungen im Netz auf den Endkundenbedarf auszurichten. Häufig wird auch davon gesprochen, dass SCM den Ablauf nach dem so genannten Pull-Prinzip ausrichtet. Das bedeutet, dass möglichst alle Aktionen durch den konkreten oder erwarteten Kundenbedarf ausgelöst werden.

Was hinter SCM steckt

Innerhalb einer Supply Chain kooperieren diverse Unternehmen als Verbundpartner, die auf der Basis von Datenintegration und verbessertem Informationsfluss zwischen den Teilnehmern auch eine Harmonisierung der Produktion und Reduzierung der einzelnen Lagerbestände anstreben. SCM nimmt dabei keinerlei Rücksicht auf Unternehmensgrenzen oder IT-Systeme. Vielmehr bedingt das Konzept, dass alle Bereiche der einzelnen Lieferstufen möglichst ohne Reibungsverlust zusammenarbeiten, um den Marktbedarf unter Nutzung aller denkbaren Ressourcen effizient befriedigen zu können. Konkret lässt sich der Ablauf am Kundennutzen messen, er richtet sich folglich nach den Kundenwünschen und Einkaufspräferenzen aus. Dies bedeutet, dass der Kunde in die operative Steuerung der Supply Chain eingebunden wird: Er entscheidet über den Ort, die Zeit und die Gestaltung der gewünschten Leistung. Aus diesem Grund betreiben viele Unternehmen heute als erste Stufe ein so genanntes internes SCM, bei dem alle unternehmensinternen Logistikprozesse - zum Beispiel das Geschäft mit einzelnen Standorten und Auslandsgesellschaften - im Fokus der Aktivitäten stehen. Um sich stärker am Marktbedarf ausrichten zu können, werden in einem zweiten Schritt häufig bereits zusätzliche Informationen mit den eigenen Kunden und Lieferanten ausgetauscht. Als verbreitete Vertreter solcher einstufiger Zusammenarbeit gelten insbesondere Konzepte wie das Vendor Managed Inventory (Bestandssteuerung durch den Lieferanten), Collaborative Engineering (Austausch von Daten zur gemeinsamen Produktentwicklung) oder auch das Collaborative Demand Planning, die Abstimmung eines gemeinsamen Absatzplans. Erst wenige Unternehmen vernetzen sich mit Organisationen, die von ihnen aus im Supply-Chain-Netzwerk weiter entfernt liegen, oder gar mit Mitbewerbern, wie es etwa in den Initiativen Efficient Consumer Response, Collaborative Planning, Forecasting and Replenishment sowie im Supply Chain Council beschrieben ist.

Der Einsatz des SOA-Paradigmas in Logistiknetzwerken muss daher von zwei unterschiedlichen Ebenen aus betrachtet werden. Einerseits kann mittels einer SOA die Integration der einzelnen Systeme unternehmensübergreifend vorangetrieben werden. Andererseits können die an der Supply Chain beteiligten Unternehmen die notwendigen Funktionen in Services kapseln, standardisiert beschreiben und in einem Repository veröffentlichen. Daraus ergibt sich ein Serviceraum, der den einzelnen Unternehmen und damit implizit der gesamten Kette zur Verfügung steht.

Metamodell für SCM-Services

Basis dieses Serviceraums ist ein standardisiertes Metamodell für die fachliche Funktionsbeschreibung der einzelnen Services oder organisatorischen Anforderungen im Rahmen des SCM. Dieses Modell ist im Falle eines Unternehmensverbunds denkbar. Dieser tritt nach außen allerdings wieder nur als eine große Organisation auf. Im Falle eines SCM mit unterschiedlichen Unternehmen ist das Errichten eines solchen geschlossenen Metamodells ungleich schwieriger.

Gleiches gilt für das Nutzen eines Servicemarktplatzes im Internet: Solange der Marktplatz nur Services bereithält, die dem geschlossenen fachlichen Metamodell der SCM-Teilnehmer entsprechen, kann dieser genutzt werden. Services, die dem Modell nicht entsprechen, lassen sich aber auch nicht im Rahmen eines solchen Marktplatzes betriebswirtschaftlich sinnvoll nutzen.

Die Services werden gemäß einem zu definierenden Supply-Chain-Prozess orchestriert. Durch die SOA-Plattform können nun Altsysteme leichter in den Prozess integriert beziehungsweise die Services bei Bedarf neu orchestriert werden. Um eine SOA in diesem Bereich zu etablieren, muss das Projektteam diverse Herausforderungen im Vorfeld meistern:

• Definieren eines unternehmensübergreifenden SCM-Prozesses auf abstrakter organisatorischer Ebene unter Berücksichtigung der einschlägigen Geschäftsszenarien oder Prozessalternativen

• Zuschneiden der Services entsprechend der Definition des Ablaufprozesses und unter Berücksichtigung größtmöglicher Wiederverwendungsmöglichkeiten

• Standardisiertes Beschreiben der betriebswirtschaftlichen Funktionen der Services.

Diese Aufgaben fallen in erster Linie dem in einer Lieferkette dominierenden Unternehmen zu. Sinnvollerweise übergibt das Management diese Aufgaben einem SOA-Provider, der die Supply Chain sowohl auf der Prozess- als auch der IT-Ebene steuert. Hierbei wird nicht nur die Lieferkette zwischen dem führenden Unternehmen und den einzelnen Zulieferern betrachtet, sondern das gesamte Netz der davon abhängigen weiteren Supply Chains. Im weiteren Verlauf gilt es, die Services regelmäßig zu warten und auf ihre betriebswirtschaftliche Konsistenz hin zu prüfen.

Hürden nach der Einführung

Nach dem Einführen einer SOA in der Lieferantenkette ergeben sich weitere Herausforderungen. Dazu gehören unter anderem:

• Abhängigkeitsmanagement - wie kann das führende Unternehmen den Lieferkettenprozess ändern; welche Auswirkungen hat eine Neuorchestrierung auf die Services der Teilnehmer?

• Welche Governance-Richtlinien im Bereich SOA sind zu berücksichtigen?

• Updates von Services - wie lässt sich sicherstellen, dass nach einem Service-Update die betriebswirtschaftlich funktionalen Eigenschaften des Services gewährleistet sind beziehungsweise die Beschreibungen der Services noch konsistent sind?

• Wie können neue Services, die von externen Anbietern oder öffentlichen Servicemarktplätzen bezogen werden, hinsichtlich ihrer betriebswirtschaftlich funktionalen Integration in die bestehenden Prozessketten so überprüft werden, dass der Prüfaufwand in einem günstigen Verhältnis zu möglichen Prozessverbesserungen durch die Nutzung der Services steht?

• Wie lässt sich ein Wildwuchs von eigenentwickelten Services und Individuallösungen verhindern?

Das Ausformen einer SOA-Governance, die sich etwa auf Authentifizierung, Autorisierung und Konsistenzprüfung der erstellten Services mit dem fachlichen Meta-Modell erstreckt, reicht hier nicht weit genug. Vielmehr müssen Unternehmen auch die jeweils von den Services unterstützten Prozesse validieren. Das erfordert eine Verbindung zwischen Governance und organisatorischen Fähigkeiten. Das Validieren innerhalb der Fachabteilungen führt zu einem Mehraufwand. Externe Experten können dabei helfen.

Die Einführung einer SOA in die Lieferantenkette will aufgrund dieser Herausforderungen gut bedacht sein. Die möglichen Vorteile der SOA rechtfertigen nicht in jedem Fall den zusätzlichen Aufwand. Deshalb sollten IT- und Prozessverantwortliche auch in der unternehmensübergreifenden Aufgabenstellung der Lieferantenkette das SOA-Phänomen nüchtern betrachten. Prozessverbesserungen werden immer den oben genannten Restriktionen unterliegen.

Was bringt SOA-Outsourcing?

Eine Option für Unternehmen ist das auslagern der SOA-Plattform an einen Lead-Logistics-Provider. Dieser übernimmt die jeweiligen Standards der Partner für die Servicebeschreibung, die mögliche Serviceabrechnung und den Zuschnitt der Services. Damit werden diese Standards verbindlich für die Teilnehmer der Wertschöpfungskette. Aus Sicht des Zulieferers kann indes von einer leichteren Ausweitung des Geschäftes durch Teilnahme an der SOA-gestützen Supply Chain nicht die Rede sein. Eine Integration in andere Zulieferketten mag technisch aufgrund einer einheitlichen Schnittstellenbeschreibung möglich sein. Vor allem wegen fehlender semantischer Standards für die Servicebeschreibung ist sie aber betriebswirtschaftlich kaum sinnvoll realisierbar. Die bereits bestehenden Standards zum Datenaustausch (beispielsweise EDIFACT) können dieses Dilemma nicht lösen. Sie dienen in erster Linie zur Beschreibung einer übermittelten Nachricht sowie der benutzten Daten; fachliche Funktionen lassen sich damit nicht darstellen.

Der potenzielle Vorteil des dominierenden Unternehmens, einen Zulieferer beliebig auszutauschen, spielt in der Praxis kaum eine Rolle. Denn der externe Zulieferer müsste dafür seine technischen Services analog zu den in der Supply Chain verwendeten Taxonomien und Ontologien beschreiben; und die Services müssten die gesuchten Funktionen tatsächlich präzise erfüllen. Immerhin erlaubt die SOA innerhalb einer Supply Chain eine leichtere Integration von Altsystemen aufgrund von standardisierten Schnittstellenbeschreibungen. Die viel zitierte steigende Flexibilität unternehmensübergreifender Geschäftsprozesse scheitert im Moment aber noch an diversen praktischen und unternehmenspolitischen Hindernissen.

Fazit

Um SOA erfolgreich in einer Lieferkette einzuführen, müssen Unternehmen diverse Vorbedingungen erfüllen. Dringend angezeigt ist dabei eine nüchterne Betrachtung der möglichen Vorteile und Aufwendungen für alle Teilnehmer der Supply Chain (siehe auch: Wie sich SOA-Projekte rechnen). Vor diesem Hintergrund erscheint es vorteilhaft, analog zur Auswahl von ERP- oder SCM-Anbietern einen Partner mit der Konfiguration und Entwicklung der SOA zu beauftragen. Dieser sollte vor allem Branchen-Know-how und möglichst einen bereits vorhandenen Pool mit Best-of-Breed-Services vorweisen können.

Der SOA-Markt ist derzeit noch sehr heterogen. Verschiedene Philosophien, technische Reifegrade und Ansätze erschweren die Auswahl des passenden Anbieters für ein Anwendungsunternehmen zusätzlich erschwert. Die Universität Würzburg untersucht in einer Studie die verschiedenen SOA-Anbieter und deren Philosophie, Produkte und Implementierungsansätze. vorstellt. Die Studie wird im Sommer 2008 veröffentlicht. (wh)

Literatur

• Baresi, L.; di Nitto, E. (Hrsg.): Test and Analysis of Web Services. 1. Auflage, Springer Verlag, Berlin, 2008.

• Lübke, D.: Unit Testing BPEL Composition, in: Test and Analysis of Web Services, 1. Auflage, Springer Verlag.

• Schelp, J.; Stutz, M.: SOA-Governance. In: HMD Reihe: "Praxis der Wirtschaftsinformatik”, Heft 253. Dpunkt.verlag, Heidelberg 2007.