Ausgangspunkt ist der Wandel in der Diskussion über das Thema Service Oriented Architecture (SOA). Wurde SOA in diversen Publikationen der letzten Jahre technisch definiert und erläutert, beobachtet man in jüngster Vergangenheit einen Wandel hin zu einer Verknüpfung von SOA mit Geschäftsprozessmanagement (GPM). Das Thema Wissensmanagement wird in der aktuellen Diskussion nicht in den Zusammenhang SOA – GPM eingebracht.
Ausgangspunkt ist der Wandel in der Diskussion über das Thema Service Oriented Architecture (SOA). Wurde SOA in diversen Publikationen der letzten Jahre technisch definiert und erläutert, beobachtet man in jüngster Vergangenheit einen Wandel hin zu einer Verknüpfung von SOA mit Geschäftsprozessmanagement (GPM). Das Thema Wissensmanagement wird in der aktuellen Diskussion nicht in den Zusammenhang SOA – GPM eingebracht.
Voraussetzung für die Zusammenführung der drei Managementansätze ist hierbei folgende These: wenn Geschäftsprozessmanagement und Wissensmanagement zusammenzuführen sind, bedeutet das für die Zusammenführung von GPM und SOA zwingend, daß die Komponente Wissensmanagement im Bereich SOA ebenfalls zu beachten ist.
1. SOA
Unter einer SOA wird allgemein eine Systemarchitektur verstanden, die unterschiedliche Methoden und Anwendungen als wiederverwendbare und auch offen zugreifbare Dienste (Services) repräsentiert [MELZ07, S. 11]. Die SOA soll eine Unternehmung in die Lage versetzen, auf veränderte Geschäftsbedingungen kurzfristig und kostengünstig durch den (Wieder)Einsatz und die Kopplung von (Web)Services zu reagieren [KRAF05, S. 1]. Hierbei können die Services atomatisiert sein und für die jeweiligen Aktivitäten in einem Geschäftsprozess zur Verfügung stehen. Daneben können auch Alt-Systeme (sog. Legacy-Systeme) zu Services gekapselt und gekoppelt werden. Die Kapselung von Legacy-Systemen scheint zwar in bestimmten Situationen richtig zu sein. Eine alleinige Konzentration darauf führt aber nicht zu den o.g. Zielen einer SOA. Erst die Unterstützung einzelner Aktivitäten bzw. Aktivitätsbündel in einem (Geschäfts)prozess durch verschiedene, flexibel austausch- und orchestrierbare Services kommt dem Anspruch einer SOA nahe, jeglichen betriebswirtschaftlich sinnvollen (Geschäfts)prozess unterstützen zu können.
Um diese Unterstützung zu gewährleisten, ist es notwendig, Kenntnisse über die zu unterstützenden (Geschäfts)prozesse zu generieren [MELZ07, S. 18] und zu nutzen. Diese können im Rahmen eines GPM-Ansatzes erworben werden.
Informationen über die und Definitionen der einzelnen Services können in der Funktion einer Registry [WEBM06, S. 7] im sog. Repository abgelegt werden [KRAF05, S. 60]. Dadurch fällt dem Repository eine Schlüsselrolle in der Architektur zu [WOOD06, S. 193]. Hierbei ist zwischen einem Repository, das die Daten für eine Firma verwaltet, und einem Repository, auf das verschiedene Firmen zugreifen können (gerade rechtliche Aspekte rücken hier in den Mittelpunkt), zu unterscheiden [KRAF05, S. 61].
Allgemein gilt, daß neben den Beschreibungen von möglichen Anwendungsszenarien in dem Repository weiterführende Daten abgelegt werden können. Diese ergänzen die Daten der sog. Service Level Agreements, die ebenfalls im Repository hinterlegt werden können. Ein Service Level Agreement stellt hierbei eine Übereinkunft über die Serviceleistung zwischen dem Anbieter des Services und dem Kunden dar [MELZ07, S. 290] und garantiert Dienstgüteeigenschaften des Services [BERB05, S. 269]. Unter Dienstgüteeigenschaften können Verfügbarkeit, Leistungsfähigkeit, Fehlerhäufigkeit und Sicherheit zusammengefaßt werden [BERB05, S. 269]. Darüber hinaus wären hier Daten des jeweiligen Service-Anbieters, Aufrufgebühren, Sicherheitsfeatures und Informationen über die Dienstgüte des jeweiligen Service [KRAF05, S. 61] denkbar.
Zusammenfassend stellt das Repository eine Informationsbasis für die elektronische Ausführung bzw. Unterstützung der Geschäftsprozesse der jeweiligen Unternehmung dar. Nur die Services werden berücksichtigt, die für die Unternehmung nutzstiftend sind. Die Auswahl dieser Services kann nur auf Basis eines Geschäftsprozessmanagementansatzes von statten gehen. Dieses wird umso deutlicher, wenn die erste Definition der SOA berücksichtigt wird. Somit ist das Repository das Herzstück des SOA-Ansatzes und sollte einer kontinuierlichen Pflege und Verbesserung unterliegen.
Literaturverzeichnis
- [BERB05, S. 269]. Berbner, R., Heckmann O. et al.: Eine Dienstgüte unterstützende Webservice-Architektur für flexible Geschäftsprozesse. In: Wirtschaftsinformatik 4 (2005) 47, S. 268-277.
- [KRAF06, S. 1] Krafzig, D., Banke K. et: Enterprise SOA. Service Oriented Architect- ure. Best practices, 6. Auflage, Prentice Hall, Upper Saddle River, 2006.
- [MELZ07, S. 11]. Melzer, I.: Service-orientierte Architekturen mit Web-Services, Konzepte-Standards-Praxis, 2. Auflage, München, Spektrum, 2007.
- [WEBM06, S. 7] webMethods: SOA Reference Architecture. Defining the key elements of a successful SOA technology framework. In http://www1.webmethods.com/PDF/whitepapers/SOA_Reference_Architecture.pdf, Erstellungsdatum 31.05.2006, Informationsabfrage am 12.07.2007.
- [WOOD06, S. 193] Woods, D.: Enterprise SOA. Designing IT for Business Innovation. 1. Auflage, Cambridge, O`Reilly, 2006.
