Integration und Verbesserung von geschäftsübergreifenden Prozessen

Fallstudie in der Energiewirtschaft auf Basis der Prozessintegrationslösung SAP XI 3.0


Diplomarbeit, 2005

218 Seiten, Note: 1,0


Leseprobe


Inhaltsverzeichnis

Verzeichnis der Abkürzungen und Akronyme

Abbildungsverzeichnis

Tabellenverzeichnis

1 Motivation und Zielsetzung

2 Grundlagen
2.1 Integration
2.1.1 Integrationsmerkmale
2.1.2 Integrationsziel
2.2 Integrationskonzepte
2.2.1 Punkt zu Punkt Integration
2.2.2 Middleware – Integration
2.3 Enterprise Application Integration (EAI)
2.3.1 Architektur
2.3.2 Funktionale Bestandteile von EAI - Lösungen
2.3.3 Kritische Punkte

3 Serviceorientierter EAI - Integrationsansatz
3.1 Betriebswirtschaftliche Herausforderungen
3.2 Anforderungen an überbetriebliche IV - Systeme
3.3 Serviceorientierte Architektur (SOA)
3.3.1 Anatomie eines Service
3.3.2 Klärung des Begriffs SOA
3.3.3 Komposition von Services
3.3.3.1 Koordination
3.3.3.2 Enterprise Service Bus (ESB)
3.4 Prozessintegration mit SAP Netweaver
3.4.1 Netweaver
3.4.2 Exchange Infrastructure XI 3.0
3.4.2.1 Komponenten XI
3.4.2.2 Umsetzung der SOA in XI
3.4.2.3 Komposition von Services
3.4.2.4 Gegenüberstellung XI und ESB
3.4.2.5 Gesamtbewertung

4 Prozesse in der Energiewirtschaft
4.1 Energiewirtschaft in Deutschland
4.2 Auswirkung der Liberalisierung auf die Prozesse der EVUs
4.2.1 Unbundling- Maßnahmen
4.2.2 Wachstumsstrategien
4.3 Konsequenzen auf die IV - Systeme
4.4 Vorstellung eines neuen Geschäftsprozesses
4.4.1 Motivation
4.4.2 Ausgangssituation
4.4.3 Lieferantenwechselprozess (Sollzustand)
4.5 Fazit

5 Implementierung des Lieferantenwechselprozesses
5.1 DV Konzept
5.1.1 Einschränkungen
5.2 Implementierung
5.2.1 Servicelandschaft
5.2.2 Designphase
5.2.2.1 Beispiel sendeNeuNetzKunde_sync_abs
5.2.2.2 Beispiel ZAPI_ISU_PARTNER_CREATEFROMDATA
5.2.2.3 Business Szenario lwp_szenario_111004
5.2.3 Konfigurationsphase
5.2.4 Implementierung der Schnittstellen
5.2.4.1 ABAP Proxy – Implementierung der Schnittstelle empfangKuendigung des Service Kündigung
5.2.4.2 Java Proxy Implementierung der Schnittstelle generateKundenId_sync_in des Service Datenservice
5.3 Prozessdurchführung
5.4 Fazit

6 Bewertung der implementierten Lösung
6.1 Methode Nutzwertanalyse (NWA)
6.2 Ermittlung der Zielerträge der IST- Situation
6.2.1 Kurzbeschreibung der IT – gestützten Durchführung des Prozesses
6.2.2 Ermittlung der Kriterienwerte
6.3 Ermittlung der Zielerträge der XI - Lösung
6.3.1 Ermittlung der Kriterienwerte
6.4 Ergebnisse der Analyse

7 Zusammenfassung und Ausblick

Anhang

A Theorie
a Nutzeffekte von Integration
b Gegenüberstellung Fachkomponente und Web -Services
c SAP Produkte Entwicklung
d Bewertungskriterien für einen ESB

B Programmcode
a ABAP Programm
b Java Programm

C XI - Business Process
a Nachrichtentypen
b Ausschnitt des Business Process
c Business Process in BPEL4WS
d Übersicht über alle Message Interfaces
e IE Protokoll

D Nutzwertanalyse
a Zielhierarchie
b Beschreibung des bisherigen LWP

Glossar

Literaturverzeichnis

Verzeichnis der Abkürzungen und Akronyme

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 2-1 Integrationsmerkmale

Abbildung 2-2 Dreischichtige Anwendungsarchitektur

Abbildung 2-3 Punkt zu Punkt Verbindung

Abbildung 2-4 EAI zur Daten-, Programme- und Prozessintegration

Abbildung 2-5 Nabe & Speiche Architektur

Abbildung 2-6 Bus Architektur

Abbildung 2-7 EAI Bestandteile

Abbildung 3-1 Die Evolution von Unternehmensorganisation

Abbildung 3-2Veränderung der Reaktionszeit im Zeitverlauf

Abbildung 3-3 Accidental Architecture

Abbildung 3-4 Services, Komponenten und Objekte

Abbildung 3-5 Find Bind Execute Paradigma (die Basis SOA)

Abbildung 3-6 Einordnung SOA

Abbildung 3-7 Koordinationsebenen und Koordinationsinstrumente

Abbildung 3-8 Einordnung ESB, Bus, Hub

Abbildung 3-9 Architektur einer SOA auf Basis eines ESB

Abbildung 3-10 Allgemeiner Aufbau eines ESB

Abbildung 3-11 Netweaver Architektur

Abbildung 3-12 Komponenten der XI 3.0

Abbildung 3-13 Objektmodell des Softwarekatalogs im CIM Standard

Abbildung 3-14 Konzepte des IR

Abbildung 3-15 Zusammenhang der Objekte aus dem Integration Directory

Abbildung 3-16 Proxy Laufzeit

Abbildung 3-17 Übertragung einer Nachricht mit dem IS

Abbildung 3-18 Spinnendiagramm

Abbildung 4-1 Wertschöpfungskette in der Energiewirtschaft

Abbildung 4-2 Des- und Reintegration der Wertschöpfungskette

Abbildung 4-3 Beziehungsgeflecht zwischen den Marktteilnehmern

Abbildung 4-4 Drei Datenmodelle zur Realisierung des Informatorischen Unbundlings

Abbildung 4-5 Use Case Model zum Lieferantenwechselprozess

Abbildung 4-6 UML Aktivitätsdiagramm zum Lieferantenwechselprozess

Abbildung 5-1 Systemarchitektur

Abbildung 5-2 Sequenzdiagramm zum Prozess des Lieferantenwechsels

Abbildung 5-3 Eintrag im SLD für das Business System ASN_206 (Mandant 206)

Abbildung 5-4 Business Process in XI

Abbildung 5-5 MI sendeNeuNetzkunde_sync_abs

Abbildung 5-6 Nachrichtentyp neuerNetzkunde_msg

Abbildung 5-7 ZAPI_ISU_PARTNER_CREATEFROMDATA

Abbildung 5-8 Business Szenario LWP

Abbildung 5-9 Verbindung zwischen zwei Actions

Abbildung 5-10 Definition Interface- Mapping

Abbildung 5-11Nachrichten - Mapping durch das Programm zapiisu1

Abbildung 5-12 Dynamische Empfängerermittlung für den alten Lieferanten

Abbildung 5-13 Interface Ermittlung für die Kündigung beim alten Lieferanten

Abbildung 5-14 ABAP Development Workbench Sicht auf die Proxy Datenstrukturen

Abbildung 5-15 ABAP Datenstruktur Repräsentation der Nachricht kündigung_ms g

Abbildung 5-16 Schnittstellenimplementierung von generateKundenId_sync_in

Abbildung 5-17 Nachricht neuerNetzKunde_msg; Message-ID: D28C4C75CE77EB419796F10EA5700D97

Abbildung 5-18 Nachricht ZAPI_ISU_PARTNER_CREATEFROMDATA; Message-ID: D28C4C75CE77EB419796F10EA5700D97

Abbildung 5-19 Antwort der BAPI Methode, Message-ID: 377620A03D6511D9A8FF000EA6482A98

Abbildung 5-20 Ergebnis des Aufrufs sendeNeuNetzkunde_sync_abs

Abbildung A-1 Entwicklung von SAP R/3

Abbildung A-2 SAP Web Application Server

Abbildung C-3 energieVertragAntrag_msg; ID:0037983A-631D-3945-AEFF-1C14B60DEFAC

Abbildung C-4 neueKundenIdReq_msg; ID:FBE0FBFA-0FC3-AA4D-B052-390C44770B4E

Abbildung C-5 kundenIdResponse_msg;ID:4D750980-3D64-11D9-B02D-000EA6482A98

Abbildung C-6 neueKundenIDRes_msg; ID:4D750980-3D64-11D9-B02D-000EA6482A98

Abbildung C-7 kuendigung_msg;ID:E831E77F-2AE4-394D-BBDA-A7BFFB8CF6EB

Abbildung C-8 kuendigung_msg;ID:A380C0B5-5FCD-434B-805B-E0C7EA3E5160

Abbildung C-9 kuendigungDaten_msg;ID:5CE05F6B-5B31-8F45-A841-7C59C23F1918

Abbildung C-10 kuendigungOutput;ID:503DED80-3D64-11D9-B7DC-000EA6482A98

Abbildung C-11 rueckAntwortKuendigungsPruefung_msg;ID:D6BB10BB-C95A-9746-A6B5-605A3310D91C

Abbildung C-12 abMeldungAltenLieferanten_msg;ID:A5025AF6-E93F-2A49-9EDE-FBE92D844BD0

Abbildung C-13 antwortKuendigung_msg;ID:816D5D2F-279E-2C45-B91B-00BEABD15D63

Abbildung C-14 neuerNetzKunde_msg;ID:D28C4C75-CE77-EB41-9796-F10EA5700D97

Abbildung C-15 ZAPI_ISUPARTNER_CREATEFROMDATA;ID:D28C4C75-CE77-EB41-9796-F10EA5700D97 in RFC transformiert

Abbildung C-16 neuerNetzKundeRes_msg;ID:377620A0-3D65-11D9-A8FF-000EA6482A98

Abbildung C-17 neuerLieferKunde_msg;ID:CB2812F0-1DAB-4D4E-970F-37A1988F0F47

Abbildung C-18 neuerLieferKundeRes_msg;ID:385D7360-3D65-11D9-94AC-000EA6482A98

Abbildung C-19 antwortAufAntrag;ID:FF3AA25C-5EF1-5F4D-AE69-1C254A00172

Abbildung C-20 Ausschnitt aus dem Business Process LWP_durchführen

Abbildung C-21 Lokale Prozessvariablen

Tabellenverzeichnis

Tabelle 3-1 Eigenschaften einer SOA

Tabelle 3-2 Funktionale Bestanteile von EAI im ESB

Tabelle 3-3 Bewertung XI bzgl. SOA Eigenschaften

Tabelle 4-1 Übersicht über die betriebswirtschaftlichen Anforderungen und den daraus erwachsenen Konsequenzen für die IT

Tabelle 4-2Übersicht Nachrichten beim LWP

Tabelle 5-1Übersicht Service und Schnittstellen

Tabelle 5-2 Zuordnung Softwarekomponenten zu Service

Tabelle 5-3 Abbildung der Services auf die XI Services

Tabelle 5-4 Ausschnitt aus dem Gesamtprozess LWP, Erstellung des Kundenobjektes im IS-U

Tabelle 6-1Notwendige Schritte zur Erstellung einer NWA

Tabelle 6-2 Prozessschritte

Tabelle 6-3 Zielertragsmatrix

Tabelle 6-4 Zielwertmatrix

Tabelle 6-5 Ergebnis der Nutzwertberechnung

Tabelle A-1 Nutzeffekte

Tabelle A-2 Gegenüberstellung Fachkomponente und Web- Services

Tabelle C-1 Übersicht über alle ein und - ausgehenden Schnittstellen des LWP Prozesses

Tabelle C-2 Protokoll der empfangenen Nachrichten durch die IE

Tabelle D-1 Beschreibung der Ziele aus der Zielhierarchie

1 Motivation und Zielsetzung

Die Beschleunigung im Geschäftsleben erfordert, dass IV[1] – Systeme in Bezug auf Flexibilität und Interoperabilität zunehmend leistungsfähiger werden. Heute müssen sich Unternehmensprozesse flexibel an veränderte Rahmenbedingungen wie z.B. den globalen Wettbewerb und immer kürzer werdenden Produktlebenszyklen anpassen. Neben dieser Entwicklung ist es für Unternehmen erforderlich geworden, stärker als bisher auf horizontaler Ebene entlang der Wertschöpfungskette zu kooperieren, um auf diese Weise ihre Wertschöpfungstiefe zu senken und damit eine bessere Kosteneffizienz sowie eine bessere Wettbewerbsfähigkeit zu erzielen. Diese Entwicklung kann man momentan am Beispiel des Lean Manufacturing[2] aus der Automobilindustrie verfolgen.

Im besonderen Maße kann man diese Entwicklungen auch in der Energiewirtschaft beobachten. In diesem Wirtschaftssektor haben sich die Unternehmensprozesse aufgrund der Liberalisierung des Energiemarktes seit 1998 und der damit vom Gesetzesgeber eingeleiteten Maßnahmen stark verändert. Die Prozesse der in diesem Sektor tätigen Energieversorgungsunternehmen unterliegen auch einem Anpassungsdruck, der nicht nur aus den sich ändernden gesetzlichen Reglementierungen resultiert, sondern auch in der Tatsache begründet liegt, dass die Unternehmen auf einem durch ein Netzmonopol gekennzeichneten Markt im Wettbewerb stehen, für den andere Wachstumsstrategien gelten bzw. erst neu entwickelt werden müssen. Die integrierten Energieversorger, die bisher die gesamte Wertschöpfungskette der Energieversorgung abdeckten, beginnen sich zu entflechten und auf bestimmte Stufen der Wertschöpfungskette zu konzentrieren. Hieraus entsteht ein Koordinationsbedarf zwischen den durch diese Entwicklung neu entstandenen Akteuren entlang der Wertschöpfungskette. Die Durchführung der teilweise neuen internen wie auch unternehmensübergreifenden Prozesse muss durch die von den jeweiligen Akteuren eingesetzten IV – Systeme unterstützt werden.

Bisherige Ansätze, die das Ziel einer inner- oder zwischenbetrieblichen Anwendungsintegration (EAI) zur Durchführung eines unternehmensübergreifenden Prozesses verfolgten, haben nur selten den gewünschten Erfolg erbracht, da sie die vorgenannten Anforderungen nach Flexibilität und Interoperabilität nur unzureichend unterstützen konnten. Diese Diplomarbeit stellt einen neuen Ansatz vor, der auf einer serviceorientierten Architektur (SOA) basiert und der verspricht, die Schwächen der traditionellen Ansätze zu überwinden und damit eine verbesserte Durchführung der Prozesse ermöglicht. Um diese Verbesserung empirisch zeigen zu können, wird exemplarisch ein unternehmensübergreifender Prozess aus der Energiewirtschaft betrachtet, um daran das Verbesserungspotential nachzuweisen.

Dieser Nachweis, welcher das wissenschaftliche Ziel dieser Arbeit darstellt, erfolgt am Ende durch eine Nutzwertanalyse, in der die Durchführung des bisherigen Prozesses mit der Durchführung einer auf SOA basierenden EAI- Lösung verglichen wird.

Die vorliegende Diplomarbeit ist wie folgt aufgebaut.

Im Anschluss an dieses Kapitel wird das grundlegende Konzept der Integration vorgestellt und in diesem Zusammenhang Begriffe und Architekturen eingeführt, auf die im weiteren Verlauf der Arbeit zurückgegriffen wird. Das Kapitel endet mit einer Vorstellung der traditionellen Integrationsansätze zur Durchführung der Prozessintegration (EAI) sowie einer kritische Diskussion ihrer Schwächen.

Im Kapitel 3 werden die betriebswirtschaftlichen Herausforderungen identifiziert, aus denen sich neue Anforderungen an die im Unternehmen eingesetzten IV – Systeme ergeben. Es wird dabei insbesondere auf die Notwendigkeit zur Integration der vorhandenen Systeme eingegangen. Im direkten Anschluss folgt eine Vorstellung des Konzeptes der SOA. Hierzu wird ein Servicebegriff hergeleitet und aufbauend auf diesem die Architektur beschrieben. Nachfolgend erfolgt die Einführung des Enterprise Service Bus (ESB) - Konzeptes, das einer SOA - Implementierung zur Erreichung der Ziele von EAI zugrunde liegt. Nach diesen theoretischen Darlegungen wird das Produkt SAP Exchange Infrastructure (XI) 3.0 hinsichtlich der Umsetzungen der vorgestellten theoretischen Konzepte untersucht. Dabei werden zu Beginn die Komponenten der Lösung präsentiert, um im Anschluss daran nachzuweisen, bis zu welchen Grad die SAP XI 3.0 als Umsetzung einer EAI – Lösung auf Basis einer SOA zu betrachten ist.

Als Einleitung für die empirische Untersuchung, inwieweit eine verbesserte Durchführung der Prozesse durch den Einsatz einer auf SOA basierenden EAI - Lösung ermöglicht wird, erfolgt im 4. Kapitel eine Beschreibung des Sektors der Energiewirtschaft. Anschließend folgt eine Begründung, weshalb gerade in diesem Bereich ein starker Prozessintegrationsbedarf zwischen den Akteuren besteht. Im Anschluss wird ein Geschäftsprozess, der Lieferantenwechselprozess, vorgestellt, der aus den zuvor skizzierten veränderten Rahmenbedingungen heraus entstanden ist und spezifische Anforderungen an eine zwischenbetriebliche Prozessintegration stellt.

Im 5. Kapitel wird schließlich die Implementierung dieses Prozesses in einer typischen SAP - Systemlandschaft eines Energieversorgungsunternehmens auf Basis der EAI- Lösung SAP XI 3.0 dargestellt. Hierzu werden zu Beginn die vorhandenen IV- Systeme der an dem Prozess beteiligten Akteure beschrieben und im Anschluss daran gezeigt, wie mit Hilfe der SAP XI 3.0 eine Kopplung der Systeme zum Zwecke der Prozessintegration für die Durchführung des Lieferantenwechselprozesses erreicht wird.

Der Nachweis für den mit dieser Implementierung erreichten Effizienzgewinn aufgrund der verbesserten Prozessdurchführung wird anhand der Methode der Nutzwertanalyse im 6. Kapitel geführt. Hierfür wird zu Beginn die Methode kurz erläutert und im Anschluss die bisherige Prozessdurchführung beschrieben und mittels der Methode bewertet. Das Kapitel schließt mit der Gegenüberstellung der Nutzwerte, der ursprünglichen Prozessdurchführung und der neuen Implementierung, basierend auf der SAP XI 3.0. Anhand dieser berechneten Kennzahlen erfolgt eine abschließende Bewertung der SOA basierten EAI - Lösung hinsichtlich der Frage nach der Vorteilhaftigkeit dieser Lösung für das Energieversorgungsunternehmen.

2 Grundlagen

Ziel dieses Kapitels ist es, die grundlegenden Konzepte der Anwendungsintegration darzustellen. Hierzu wird eingangs der Begriff Integration erklärt und auf das Gebiet der Wirtschaftsinformatik abgegrenzt. Die verfolgten Ziele der Anwendungsintegration können mit der Beantwortung der Frage nach den Ausprägungen bestimmter Integrationsmerkmale erfolgen. Im Anschluss werden Integrationskonzepte sowie die davon zu unterscheidenden pragmatischen Integrationsansätze beschrieben. Am Ende des Kapitels wird der Integrationsansatz Enterprise Application Integration (EAI) vorgestellt sowie die wichtigsten funktionalen Bestandteile dieser Lösung dargestellt. Abschließend werden die Schwächen von bisherigen EAI – Lösungen zusammengefasst.

2.1 Integration

Entsprechend dem Duden[3] bedeutet Integration „Wiederherstellung eines Ganzen“, d.h. das Verbinden oder Vereinigen von logisch zusammengehörigen Teilen mit dem Ziel, einen Zustand zu erreichen, der einen höheren Nutzen verspricht als der durch die Summe der einzelnen Teile.

Übertragen auf die Wirtschaftsinformatik entsprechen die logisch zusammengehörenden Teile den im Unternehmen befindlichen betrieblichen Anwendungssystemen[4]. Durch eine Integration dieser Teile wird das Abbild der betrieblichen Realität wiederhergestellt, die aufgrund von Abteilungs-, Funktions- und Prozessgrenzen, im Verständnis von künstlichen Grenzen in Folge von Taylorismus oder Spezialisierung entstanden sind.[5] Das Integrationsziel ist demnach das wiederzusammenführen einer gewachsenen Aufgabenzerlegung, repräsentiert durch diverse betriebliche Anwendungssysteme, zu einem integrierten Anwendungssystem.[6]

Nach (LINß 1995) unterscheidet man im Allgemeinen den Integrationszustand vom Integrationsvorgang. Der Integrationszustand eines IV – Systems[7] gibt an, ob und wie betriebliche Anwendungssysteme mit einer Organisation oder anderen Systemen verknüpft sind. Zur Klassifizierung des Integrationszustandes dient der Integrationsgrad[8], der bei (KAIB 2002) auch als Integrationsform bezeichnet wird.[9] Dieser Klassifizierungsmaßstab setzt sich aus einem Tupel von Integrationsmerkmalen zusammen, auf die nachfolgend näher eingegangen wird.[10] Durch einen Integrationsvorgang werden mit Hilfe einer bestimmten Methode, dem so genannten Integrationsansatz (siehe Abschnitt 2.2, S.10), betriebliche Anwendungssysteme zusammengeführt, und es wird ein neuer Integrationszustand erreicht.

2.1.1 Integrationsmerkmale

Wie eingangs erwähnt, beschreiben Integrationsmerkmale die Integrationsform bzw. den Integrationsgrad, die damit die Attribute des Integrationszustands bilden. In der folgenden Abbildung findet sich eine Zusammenstellung der Integrationsmerkmale nach (KAIB 2002, S.15). Die dort dargestellten Dimensionen Integrationsgegenstand, Integrationsreichweite sowie Integrationsrichtung gehen auf (LINß 1995) zurück.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: KAIB 2002, S.15

Abbildung 2-1 Integrationsmerkmale

Der Gegenstand der Integration kann sich nach (KAIB 2002) auf Daten, Funktionen und Programme erstrecken.[11] Hierbei versteht man unter der Datenintegration eine Konsolidierung der anwendungsspezifischen Datenhaltungskomponenten zu einer Datenbasis, die allen integrierten Anwendungssystemen zur Verfügung gestellt wird.[12] Nach (SCHEER 1990) unterscheidet man die vier in der Abbildung dargestellten Integrationsgrade für die Datenintegration.

Bei der Funktionsintegration[13] unterscheidet man zwischen einer aufgabenträgerorientierten sowie einer aufgabenorientierten Funktionsintegration. Bei der aufgabenorientierten Funktionsintegration werden Aufgaben verschiedener aufbauorganisatorischer Instanzen wie z.B. Arbeitsplätze oder Abteilungen gleicher Ebene zusammengezogen.[14] Man kann an dieser Stelle auch von einer Vorgangs- oder Prozessintegration sprechen.[15] Im Unterschied hierzu werden bei der aufgabenträgerorientierten Funktionsintegration Teilaufgaben an einem Arbeitsplatz zusammengeführt.[16] (Rautenstrauch et al. 2003, S. 220) differenziert an dieser Stelle zwischen einer Aufwärts- und Abwärtsintegration, wonach die Richtung die Zunahme bzw. die Abnahme von der für die Durchführung der Aufgaben notwendigen Qualifizierung der ausführenden Mitarbeiter beschreibt.

Mit der Programmintegration ist die Abstimmung einzelner Programme eines Anwendungssystems oder mehrerer Systeme gemeint. Unter Programme werden an dieser Stelle Softwarebausteine verstanden, die die Komponenten auf der Ebene der Funktionsintegration IV- technisch realisieren.[17] Dieser Argumentation folgend ist eine Programmintegration eine notwendige Bedingung zur Realisierung der Funktionsintegration.

Die Integrationsrichtung wird der Aufbauorganisation eines Unternehmens folgend in Form einer Pyramide dargestellt.[18] Hierbei wird mit der horizontalen Integration die Verbindung von Teilsystemen in der betrieblichen Wertschöpfungskette verstanden, während unter der vertikalen Integration in erster Linie die Datenversorgung der Planungs- und Kontrollsysteme aus den Administrations- und Dispositionssystemen heraus verstanden wird.[19]

Mit der Integrationsreichweite wird die Unterscheidung zwischen der innerbetrieblichen und zwischenbetrieblichen Integration vorgenommen.[20] Hierbei bezeichnet ersteres die Integration innerhalb eines rechtlich selbstständigen Unternehmens und letzteres die Integration zwischen selbstständigen Unternehmen. Bei der zwischenbetrieblichen Integration lassen sich Integrationsgrade nach den Abhängigkeiten zwischen den Unternehmen beschreiben.[21] Die zwischenbetriebliche Integration reicht vom elektronischen Datenaustausch über die Nutzung gemeinsamer Datenbestände und von dem Zusammenfassen und Verlagern gemeinsamer Aufgaben bis hin zur automatisierten Abwicklung zwischenbetrieblicher Vorgänge.[22]

2.1.2 Integrationsziel

Das durch eine Integration der betrieblichen Anwendungssysteme angestrebte Ziel ist nach (FISCHER 1999)[23]:

„Ziel der Integration ist es letztlich, durch ganzheitliche, ungehinderte und inhaltliche konsistente Informationsflüsse die Effektivität und die Effizienz der Unternehmung zu steigern“

Demnach gilt es, durch die Integration die im Unternehmen bestehenden künstlichen Grenzen[24] zu überwinden, um auf diese Weise Geschäftsprozesse im Unternehmen natürlich abbilden zu können.[25]

(KAIB 2002) unterscheidet zwischen operationalen und strategischen Nutzeffekten, die durch einen optimalen Integrationsgrad des genutzten IV – Systems erzielt werden können, welches auch als das formale Integrationsziel bezeichnet wird. Der optimale Integrationsgrad dieses Systems besteht nach (KAIB 2002) allerdings nicht in der Maximierung der einzelnen Integrationsmerkmale[26], sondern ergibt sich vielmehr aus einer Abstimmung der mit einem bestimmten Integrationsgrad verbundenen Nutzeffekte auf die Unternehmensziele. Die wesentlichen operativen und strategischen Nutzeffekte einer überbetrieblichen Integration in Anlehnung an (KAIB 2002) und (Aier et al. 2004) finden sich im Anhang A.a.

Zusammenfassend lässt sich die Aussage treffen, dass es das Integrationsziel ist, die Bestimmung und die Realisierung des optimalen Integrationsgrades eines betrieblichen IV - Systems zu erzielen, wodurch ein Beitrag zur Erreichung der strategischen Unternehmensziele geleistet wird.

2.2 Integrationskonzepte

Für die Umsetzung des Integrationsvorganges, vgl. Abschnitt 2.1, als Mittel zur Erreichung eines für die Unternehmung besseren Integrationszustandes existieren bestimmte Integrationskonzepte. Hierunter sind nach (KAIB 2002) unterschiedliche, grundlegende Methoden zu verstehen, die auf unterschiedlichen Ebenen eines Anwendungssystems angesetzt werden können, um ein Integrationsziel zu erreichen. Generell unterscheidet man die Präsentations-, die Daten- oder die Funktionsebene eines Anwendungssystems. Diese Ebenen sind in der folgenden Abbildung 2-2 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: KAIB 2002, S.61

Abbildung 2-2 Dreischichtige Anwendungsarchitektur

Dementsprechend lassen sich die Präsentationsintegration, die Datenintegration und die Funktionsintegration als häufig genutzte Integrationskonzepte unterscheiden. Aufgrund der Mehrdeutigkeit der Begriffe wird an dieser Stelle kurz auf die Unterscheidung der Daten- und Funktionsintegration im Zusammenhang mit der Darstellung verschiedener Integrationsgegenstände (siehe Abschnitt 2.1.1) und der Bedeutung als Integrationskonzepte eingegangen.

Die Integrationsgegenstände konkretisieren den Integrationszustand, während sich die Integrationskonzepte auf die Beschreibung des Integrationsvorgangs beziehen. Eine Datenintegration im Sinne eines Integrationskonzeptes betrifft dabei auch die Daten als Integrationsgegenstand. Aber auch das Konzept der Funktionsintegration kann eine Integration von Daten als primäres Ziel haben. Insofern besteht eine Abhängigkeit zwischen den Sachverhalten, der Fokus ist jedoch ein anderer.[27]

Präsentationsintegration

Dieser Ansatz repräsentiert die einfachste Form der Integration, da er das, was bei einer Integration durch menschliches Handeln geschehen würde, einfach nachspielt. Die integrierende Anwendung greift hierzu auf die Präsentationsebene der Anwendung zu. Sie simuliert quasi den menschlichen Benutzer der zu integrierenden Anwendungen. Werkzeuge, die diese Aufgabe übernehmen, werden auch als Screen Scraper (dt. Bildschirmabkratzer) bezeichnet.[28] Zurzeit wird dieses Integrationskonzept im Umfeld von Großrechnern genutzt, die über keine sonstigen geeigneten Schnittstellen verfügen.[29] Kritik an diesem Verfahren ergibt sich aufgrund von Sicherheits- und Performance- Aspekten.[30] Insofern kann dieses Konzept nur als Notlösung bezeichnet werden.

Datenintegration

Bei der Integration über die Datenebene erfolgt ein direkter Zugriff auf die Daten des Anwendungssystems unter Umgehung der Präsentations- und Funktionsebene.[31] Die Datenintegration dient typischerweise dem gemeinsamen Gebrauch oder dem Abgleich redundanter Daten zwischen Anwendungen. Mit Hilfe dieses Ansatzes lässt sich in vielen Fällen auf einfache Weise ein spezifisches Integrationsproblem lösen, ohne dass Anpassungen an dem bestehenden Anwendungssystem vorgenommen werden müssen.[32] Das Spektrum an zu integrierenden Daten ist im Vergleich zur Präsentationsintegration größer. Problematisch kann die Datenintegration aufgrund von möglichen Integritätsproblemen sein, die durch die Umgehung der Anwendungslogik aus der Funktionsebene entstehen.[33] Insgesamt kann die Datenintegration aber als ein erprobtes und weit verbreitetes Integrationskonzept betrachtet werden.[34]

Funktionsintegration

Bei der Integration über die Funktionsebene werden die von dieser Ebene bereitgestellten Schnittstellen für die Integrationsaufgabe[35] genutzt.[36] Von den hier vorgestellten Konzepten handelt es sich hierbei um das weitestgehende. Es unterstützt ein breites Spektrum zu lösender Integrationsaufgaben, einschließlich der typischen Anwendungen der Präsentations- oder Datenintegration.[37] Nur im Falle einer nicht passenden Schnittstelle zur Erreichung des angestrebten Integrationsgrades muss auf ein anderes Konzept, in den meisten Fällen die Datenintegration, zurückgegriffen werden. Insgesamt wird durch diesen Ansatz eine hohe Wiederverwendbarkeit der auf der Funktionsebene bereitgestellten Funktionalität erreicht, welche flexibel und zur Entwurfszeit in noch nicht vorgesehener Weise genutzt werden kann. Nach (KAIB 2002) kann der Integrationszustand bei einer Funktionsintegration als ein Netzwerk von Teilsystemen betrachtet werden, die jeweils aus Datenspeichern und Funktionen bestehen. Eine Koordination dieses Systems wird entweder durch den Benutzer oder über Drittsysteme gesteuert. Ein Nachteil dieses Integrationskonzeptes liegt in der großen Komplexität, die einer Umsetzung dieses Konzeptes innewohnt, und den damit verbundenen Kosten, gerade im Falle der Modifikation von bereitgestellten Schnittstellen. Zur Zeit existiert eine Reihe von Standardmechanismen zur Durchführung einer Funktionsintegration, beispielsweise Common Object Request Broker Architecture (CORBA), Javas Remote Method Invocation (RMI) oder Microsofts Distributes Component Object Model (DCOM).[38]

Die diesen drei Integrationskonzepten zugrunde liegenden technischen Konzepte zur Umsetzung sind vielfältig und werden an dieser Stelle deswegen nicht näher erläutert. Eine Übersicht hierüber findet sich bei (Bussler 2003) oder bei (HOHPE et al. 2003).

Von den hier vorgestellten Integrationskonzepten als grundlegende modellhafte Methoden der Anwendungsintegration wird ein pragmatischer Integrationsansatz nach (KAIB 2002) unterschieden. Im Folgenden werden zwei traditionelle Ansätze vorgestellt, um anhand von diesen die Vorzüge des im Abschnittes 1.3 vorgestellten Ansatzes EAI darzustellen.

2.2.1 Punkt zu Punkt Integration

Bei einer Punkt zu Punkt Integration (P2P - Integration) werden die Anwendungssysteme über dezidierte Verbindungen miteinander verknüpft. In der Konsequenz bedeutet dieses, dass man theoretisch eine Ordnung von O(n²) Schnittstellen haben kann, wie die folgende Abbildung 2-3 verdeutlicht. Aus diesem Grund ist der P2P - Integrationsansatz nur für kleine n sinnvoll.[39] Aus dieser Darstellung leitet sich auch das Synonym dieses Integrationsansatzes, die sogenannte Spaghetti - Integration ab.[40] Typischerweise ist dieser Ansatz die Folge eines Zusammenwachsens von Anwendungssystemen über die Zeit hinweg.[41] Häufig wurde keine stringente ganzheitliche Strategie und Planung für die sich im Einsatz befindenden IV – Systeme entwickelt, sondern nach Bedarf eine Kommunikationsverbindung zwischen Anwendungssystemen geschaffen. Im besonderen Maße wird dieser Integrationsansatz bei der Zusammenführung von unterschiedlichen IV – Systemen im Rahmen eines M&A verwendet, um in möglichst kurzer Zeit die Prozesse zwischen den fusionierten Unternehmensteilen zu koppeln und damit erste Ergebnisse zu liefern, die die Fusion rechtfertigen können.[42] Hieraus leiten sich das dargestellte Schnittstellenchaos ab und die sich daraus ergebenden hohen Betriebskosten für die Wartung der Schnittstellen.[43] Die Integration weiterer Anwendungssysteme gestaltet sich schwierig, da im Regelfall individuelle Kommunikationsverbindungen über die spezifischen Schnittstellen der integrierenden AWS erstellt werden müssen.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung

Abbildung 2-3 Punkt zu Punkt Verbindung

2.2.2 Middleware – Integration

Bei einem Middleware - basierten Integrationsansatz wird zur Lösung des Integrationsproblems eine vermittelnde Softwareschicht, die sogenannte Middleware, zwischen zwei oder mehrere Systeme geschaltet.[44] Ziel ist es, dass die über diese Schicht angebundenen Systeme hersteller- und ggf. plattformunabhängig Daten austauschen können. Hierbei werden Implementierungsdetails, die bei der P2P – Integration für die Etablierung der Verbindungen notwendig waren, in dieser Softwareschicht versteckt, wodurch die Integrationskosten geringer ausfallen. Middleware ermöglicht die Konnektivität zwischen verschiedenen Anwendungen und unterstützt somit die Integration auf Datenebene.[45] Die semantische Abstimmung zwischen den Anwendungen oder ein Prozessmanagement leistet Middleware nach (KAIB 2002) ausdrücklich nicht.

Ein spezieller Middleware – Ansatz ist der sogenannte MOM (Message Oriented Middleware), ein nachrichtenorientierter Ansatz. Dieser ist speziell für den Zweck konzipiert worden, in einer verteilten Umgebung die Zustellung von Nachrichten zu einem Anwendungssystem zu garantieren.[46] Aus diesem Grund unterstützt er einen konsistenten, zuverlässigen und sicheren Transportmechanismus. Generell unterscheidet man an dieser Stelle zwei Arten des Transportes einer Nachricht zwischen Anwendungssystemen, die von einer MOM unterstützt werden: die asynchrone und die synchrone.

Die synchrone Kommunikation entspricht der typischen Client-Server Kommunikation, bei der der Sender eine Nachricht an den Empfänger sendet und der wiederum nach der Bearbeitung der Anfrage eine Antwort an den Sender zurücksendet. Während dieses Interaktionsvorganges wartet die sendende Anwendung auf die Antwort und ist dadurch in ihrem weiteren Programmablauf blockiert.

Die asynchrone Kommunikation unterscheidet sich dagegen von der synchronen wie folgt. Auch hier wird eine Nachricht vom Sender an den Empfänger geschickt, allerdings unterbricht der Sender dabei nicht seine Programmausführung. Er blockiert somit nicht, sondern führt die Bearbeitung des nächsten Programmschrittes fort.

2.3 Enterprise Application Integration (EAI)

EAI ist ein noch recht junger Begriff für den zurzeit noch keine einheitliche Definition existiert.[47] Nach (KAIB 2002) stellt EAI einen „umfassenden Ansatz für die operative Integration von Geschäftsprozessen durch die kontrollierte, flexible und rasch ausbaubare inner- oder zwischenbetriebliche Integration multipler Anwendungen“ dar. Entsprechend den vorgestellten Integrationsmerkmalen handelt es sich demnach um einen Ansatz, welchem als Integrationsgegenstand Daten, Programme und Prozesse zugrunde liegen.[48] Die folgenden Abbildung 2-4 trägt diesem Umstand Rechnung.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: KAIB 2002, S. 79

Abbildung 2-4 EAI zur Daten-, Programme- und Prozessintegration

Als Integrationsreichweite dieses Ansatzes lässt sich sowohl die innerbetriebliche als auch zwischenbetriebliche Integration ausmachen. Zu der Integrationsrichtung kann keine allgemeine Aussage getroffen werden. Es erscheint allerdings notwendig, dass entsprechend der obigen Beschreibung immer eine horizontale Integration entlang der Wertschöpfungskette zur Unterstützung des Geschäftsprozesses erfolgt.

Gemäß der vorliegenden Abbildung baut der Integrationsansatz EAI auf einer Middleware Technologie (siehe Abschnitt 2.2.2) zur Lösung des Integrationsproblems auf.[49] Im Unterschied zu den bisher genannten Integrationsansätzen stellt die EAI einen Ansatz zur semantischen Integration über Daten-, Programm- und Prozessebene dar[50] (vgl. Abbildung 2-4), indem diese Funktionalität für das Prozessmanagement sowie zur zentralen Koordination von Transaktionen bereitsteht.

Im Folgenden werden zur technischen Realisierung dieses Integrationsansatzes zwei unterschiedliche Architekturen vorgestellt.

2.3.1 Architektur

Nach (KAIB 2002, S.86) existieren grundsätzlich zwei Architekturansätze bzw. Netzwerktopologien. Zum einen die so genannte Nabe- und Speiche- Architektur und zum anderen die Bus- Architektur.

Bei der Nabe- und Speiche- Architektur (engl. Hub & Spoke) agiert die EAI – Lösung als zentrale Instanz („Nabe“) zwischen den zu verbindenden Anwendungssystemen vgl.Abbildung 2-5. Eine Interaktion zwischen den Anwendungen findet nur über diese Stelle statt. Auf diese Weise müssen die zu integrierenden Anwendungen lediglich eine Schnittstelle verwenden, um zum Zwecke der Integration mit anderen Anwendungen in Interaktion treten zu können. Die Verbindung zwischen der zu integrierenden Anwendung und der „Nabe“ wird als „Speiche“ bezeichnet.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung

Abbildung 2-5 Nabe & Speiche Architektur

Die „Nabe“ und „Speiche“ Architektur wird nach (KAIB 2002) in der Praxis am häufigsten verwendet. Ein Nachteil der vorgestellten Lösung liegt in dem zentralen Ansatz begründet. Dieser kann damit als single point of failure identifiziert werden.[51]

Von der Nabe- und Speicher- Architektur ist die Bus- Architektur zu unterscheiden, siehe folgende Abbildung 2-6.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung

Abbildung 2-6 Bus Architektur

Bei der Bus– Architektur wird der Nachteil der Nabe- und Speiche- Architektur aufgehoben, indem dieser Ansatz die Funktionalitäten, die bisher von einer zentralen Instanz bereitgestellt wurden, auf verschiedene Netzwerkknoten aufteilt und dezentral verwalten lässt.[52] Aufgrund dessen spricht man bei der Bus- Architektur auch von einer verteilten Architektur. Die Nachrichten werden über den „Bus“ an alle angeschlossenen Softwarekomponenten versendet. Charakteristisch für eine Bus – Architektur ist die höhere Performance[53] sowie der niedrigere Aufwand für die Anbindung einzelner Systeme.

Letztlich ist die Entscheidung, welche Architektur für die Umsetzung einer EAI – Lösung gewählt wird, aus Sicht der zu integrierenden Anwendungen irrelevant, da für diese eine Interaktion immer über eine Form von Speiche erfolgt. Eine Unterscheidung zwischen den Architekturformen findet im Rahmen dieser Arbeit anhand der unterschiedlichen Netztopologien statt.

2.3.2 Funktionale Bestandteile von EAI - Lösungen

Aus der uneinheitlichen Begriffsdefinition folgt eine ebenso nicht klare Definition der funktionalen Bestandteile einer EAI– Lösung. Die im Folgenden dargestellten Komponenten orientieren sich maßgeblich an (KAIB 2002). Der Abbildung 2-7 entsprechend ergeben sich fünf zentrale Bestandteile einer EAI– Lösung:

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung, in Anlehnung an KAIB, 2002, S.100

Abbildung 2-7 EAI Bestandteile

Adapter

Adapter werden benötigt, um die zu integrierende Anwendung mit der EAI– Lösung zu koppeln. Hierzu wird die Exportschnittstelle der Anwendung nicht geändert (non- invasiv). Um dieses zu ermöglichen, werden Adapter im Sinne von Softwaresteckern verwendet, die anwendungs- und technologiespezifisch eingesetzt werden. Zu unterscheiden sind die Thin– von den Thick- Adaptern, die sich in dem Grad der jeweils gekapselten Logik des Adapters unterscheiden. Zum Beispiel kann der Adapter die Transformation von Daten zwischen dem Quell- und Zielsystem unterstützen.

Middleware

Der Begriff Middleware wurde im Abschnitt 2.2.2 bereits kurz vorgestellt. Im Kontext dieses Abschnittes ist keine Präzisierung dieses Begriffes notwendig. (KAIB 2002) fasst unter dem Begriff Middleware die Summe der zur Interaktion von Anwendungen eingesetzten Technologien, bestehend aus RPC, datenzugriffsorientierter Middleware, MOM, transaktionsorientierter Middleware, komponentenorientierter Middleware, zusammen.[54] Diesen Technologien ist gemein, dass sie nach (KAIB 2002) die Datenintegration ohne eine semantische Abstimmung leisten.

Nachrichtenmanagement

Unter dem Begriff Nachrichtenmanagement wird die Funktionalität zur Realisierung der Programmintegration verstanden. Im Unterschied zur Middleware wird mit Hilfe des Nachrichtenmanagements eine Abstimmung auf der semantischen Ebene zwischen zu integrierenden Anwendungen getroffen.[55] Die Funktionalität umfasst die Bereiche der Datentransformation, Synchronisation des zeitlichen Ablaufs von AWS sowie die Möglichkeit zur Durchführung von Transaktionen.[56]

Prozessmanagement

Gemäß der obigen Definition von EAI wird hierunter eine Funktionalitätskomponente verstanden, die die auf oberste Ebene lang laufenden, unterbrechbaren, verteilten Geschäftsprozesse, die auch personenunterstützte Schritte beinhalten können, unterstützt.[57] Dieses geschieht dadurch, dass mit Hilfe des Prozessmanagements Abarbeitungsfolgen von Funktionen als Teilprozess des Geschäftsprozesses festgelegt werden können.[58] Diese Abarbeitungsfolgen werden im Folgenden auch als Workflow verstanden. Das Prozessmanagement umfasst nach (KAIB 2002, S. 120) drei wesentliche Funktionalitäten: die Prozessmodellierung, die Prozesssteuerung und die Prozesskontrolle. Während der Prozessmodellierung wird ein Prozessmodell erstellt, in dem Ressourcen, d.h. Anwendungen und Personen, zugeordnet werden sowie die Sequenzen und Informationsflüsse zwischen diesen definiert wird. Die Ausführung des Modells erfolgt mittels der bereitgestellten Funktionalität durch die Prozesssteuerung. Über Schnittstellen zu den anderen EAI– Komponenten wird die Ausführung des Workflows gesteuert. Die Prozesskontrolle übernimmt die Aufgaben der Überwachung des Ablaufs (Monitoring) anhand festgelegter Metriken und umfasst die Möglichkeit zur entsprechenden Optimierung der Prozesse.

Metadienste und Zusatzdienste

Die für die Gestaltung der EAI – Lösung notwendigen Informationen werden in einer Metadatenbank gehalten, dem so genannten Repository. In diesem befinden sich Informationen über die Integrationsbeziehungen sowie über die zu integrierenden Komponenten selbst. Die für eine EAI– Lösung elementare Informationen wie Nachrichtenschemata, die Verteilung von Komponenten, sowie Transformationsinformationen werden in dieser Datenhaltungskomponente gespeichert.[59]

Neben diesen Daten selbst werden unter diesem Punkt auch Zusatzdienste subsumiert. Vor allem Dienste, die die Funktionalität für das Systemmanagement sowie für den Entwicklungsprozess gewährleisten, müssen an dieser Stelle genannt werden.[60] Das zentrale Element des Systemmanagement ist ein Verzeichnis (engl.: directory), in welchem eine eindeutige und konsistente Bezeichnung aller Komponenten des verteilten Systems, d.h. deren Ortung, Identifikation und Gebrauch sowie die Zuordnung von Systemressourcen zu diesen Komponenten, hinterlegt sind.[61] Eine Administration der EAI – Lösung wird mit Hilfe der unter diesem Punkt zusammengefassten Funktionalität ermöglicht.

2.3.3 Kritische Punkte

Im Vergleich zu den im Abschnitt 2.2 vorgestellten Integrationsansätzen wurde mit EAI ein Integrationsansatz präsentiert, mit dem Verbesserungen in Bezug auf die Bewältigung der Integrationsaufgabe erzielt werden können.

Dennoch ergeben sich bei der bisherigen Umsetzung dieses Ansatzes Probleme. Zwar löst EAI grundsätzlich das Schnittstellenproblem, welches bei der P2P-Integration dargestellt wurde, allerdings müssen für die Integration von so genannten Legacy - Anwendungen[62] meistens individuell Schnittstellen entwickelt werden. Bezogen auf die Ebene der Datenintegration kann nach (EICKER et al. 1992) die Verwendung von individuell zu erstellenden Schnittstellen mit Hilfe des selektiven integrationsorientierten Reengineering verhindert werden. Auf diese Weise kann zumindest auf der Datenebene die Schnittstellenproblematik reduziert werden. Aufgrund der Tatsache, dass diese Methodik aber nur unter bestimmten Umständen wirtschaftlich eingesetzt werden kann, wie die Autoren EICKER et al. 1992 herausstellen, und zurzeit keine entsprechende Toolunterstützung existiert, wird im Folgenden davon ausgegangen, dass im Allgemeinen ein großer Aufwand bei der Erstellung von Schnittstellen bestehen bleibt.

Neben dieser Schnittstellenproblematik darf nach (Aier et al. 2004) nicht der Aufwand unterschätzt werden, der durch die Einführung einer EAI- Lösung entsteht. Dieser resultiert maßgeblich aus der Komplexität der Integrationsbeziehungen, die aus dem Geschäftsprozess entstehen. Deshalb schlagen (Aier et al. 2004) vor, dass eine EAI– Einführung mit einer vollständigen Prozessüberarbeitung[63] einhergehen muss. (Hofmann 2003) betont, dass eines der Kernprobleme der EAI in der fehlenden Standardisierung liegt, wodurch u.a. die Verbindung unterschiedlicher EAI - Werkzeuge in einer integrierten Umgebung, z.B. für die Überwachung des Prozesses (engl. Monitoring), verhindert wird. Gerade diese Schwachstelle ist gravierend, da eine EAI – Lösung per Definition, wie im Abschnitt 2.3 dargestellt, die Interoperabilität zwischen Anwendungssystemen leisten muss.

Im nächsten Kapitel wird ein neues Technologiekonzept vorgestellt auf dessen Basis der EAI – Integrationsansatz umgesetzt werden kann.

3 Serviceorientierter EAI - Integrationsansatz

In diesem Kapitel wird die serviceorientierte Architektur (SOA) als ein Konzept vorgestellt, auf dessen Basis eine EAI- Lösung zur inner – und überbetrieblichen Prozessintegration ermöglicht wird. Außerdem soll gezeigt werden, dass die SAP Exchange Infrastructure (XI) 3.0 als eine Implementierung dieses Konzeptes zur Realisierung einer EAI - Lösung zu betrachten ist.

Einleitend wird kurz dargestellt, wo die betriebswirtschaftlichen Problemstellungen liegen, die eine SOA notwendig erscheinen lassen, und abgeleitet, welche Anforderungen sich aus diesen für die im Unternehmen eingesetzten IV - Systeme ergeben. Im Anschluss erfolgt eine detaillierte Vorstellung des SOA - Ansatzes sowie eines Koordinierungsinstruments von Services, dem Enterprise Service Bus (ESB). Abschließend wird die SAP XI 3.0 vorgestellt und gezeigt, dass es sich hierbei um eine EAI – Lösung, basierend auf dem SOA – Prinzip und vergleichbar dem ESB– Konzept, handelt.

Aufgrund der Tatsache, dass für viele in diesem Text verwendete Begriffe aus Sicht des Autors keine adäquate deutsche Übersetzung existiert bzw. die deutsche Übersetzung im jeweiligen Kontext irreführend ist[64], werden in diesem Fall englische Begriffe verwendet. Der Plural dieser Begriffe orientiert sich ebenfalls an der englischen Grammatik.

3.1 Betriebswirtschaftliche Herausforderungen

Unternehmen müssen sich gegenwärtig neuen Herausforderungen stellen als noch vor einigen Jahren. Heute sind Unternehmen einem stärkeren Wettbewerb ausgesetzt, der nicht mehr nur lokal stattfindet, sondern mittlerweile verstärkt auch global.[65] Insbesondere durch die Marktliberalisierungen und technologischen Innovationen in den 80er und 90er Jahren[66] wurde der Wettbewerb in vielen Branchen verschärft.[67]

Die Unternehmen sind in ihren Bemühungen um die Kunden gezwungen, schnell und flexibel auf Marktveränderungen zu reagieren. Gleichzeitig müssen Unternehmen in der Lage sein, die sich ständig verkürzenden Produktlebenszyklen und zunehmende Innovationsdynamik zu bewältigen.[68] (MULHOLLAND 2003) fordert dementsprechend das adaptive Unternehmen, welches dieser Fähigkeit gerecht wird.[69]

Die Notwendigkeit von flexiblen Geschäftsprozessen[70] ist demzufolge kritisch für den Unternehmenserfolg, die Wertsteigerung. Zum einen deswegen, weil die Unternehmen versuchen durch eine Optimierung ihrer Prozesse[71] entlang der Wertschöpfungskette ihren Gewinn durch Kostenreduktionen zu steigern. Dieses impliziert eine verstärkte Abstimmung/ Integration mit den Geschäftspartnern und Kunden, mit dem Ziel einen möglichst hohen Automatisierungsgrad in der Koordination zu erreichen. (CHAPPEL 2004) führt dieser Entwicklung entsprechend den Begriff extended Enterprise[72](zu dt. Erweiterte Unternehmung) ein. Beispiele für diese Entwicklung sind u.a. das vom Unternehmen WalMart[73] eingeführte VMI (Vendor-Managed-Inventory)[74] oder die vom Unternehmen DHL online angebotene Funktionalität der Nachverfolgung von Paketen für Kunden.

Zum anderen versuchen die Unternehmen den Gewinn durch ein Umsatzwachstum zu realisieren, welches ebenfalls nach einem hohen Maß an flexiblen Geschäftsprozessen verlangt, da nach (HAGEL 2002, S. 5) ein organisches Wachstum in diesem Marktumfeld nur noch durch neue Produkte, neue Verkaufskanäle und neue Kundensegmente stattfindet.

Diese neuen Herausforderungen antizipieren die Unternehmen durch eine Veränderung der Unternehmensorganisation, vgl. Abbildung 3-1. Die aus den 80er Jahren stammenden vertikal isolierten Abteilungen (in der Abbildung als Stovepipe/ Offenrohr bezeichnet) wurden in den 90ern durch horizontale, geschäftsprozessfokussierte Strukturen (Tunnels) abgelöst. Heutzutage hingegen muss auf Basis von effizienten internen Prozessen die Integration mit den an der Wertschöpfung beteiligten Akteuren erfolgen.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: BUTLER GROUP (1999), S. 10

Abbildung 3-1 Die Evolution von Unternehmensorganisationen

Auf Grundlage von derart flexiblen Geschäftsprozessen ist es möglich, dass sich Unternehmen stärker auf ihre Kernkompetenzen[75] zurückziehen und beginnen, Randaktivitäten entweder zu verlagern (vgl. Glossar: Outsourcing) oder komplette Prozesse durch das BPO (vgl. Glossar: Business Process Outsourcing) abzugeben. Erreichbar wird dies dadurch, dass eine flexible Gestaltung von Prozessen die Integration von Geschäftspartnern in die Wertschöpfungskette auf einfache Weise ermöglicht. Bei weitergehenden Standardisierungen in den Abläufen der unternehmensübergreifenden Koordination wird es zudem möglich werden, eine bisher eher starke Kopplung der Akteure in den Geschäftsprozessen[76] durch eine lose Kopplung zu ersetzen. Auf diese Weise können Akteure in der Wertschöpfungskette leichter ausgetauscht werden, wodurch der Kundennutzen durch eine höhere Produktqualität gesteigert und somit die Wettbewerbsfähigkeit insgesamt verbessert wird.[77]

Zusammenfassend lässt sich demnach ein allgemeiner Trend in der Wirtschaft feststellen, wonach die Unternehmen verstärkt Elemente ihrer bisherigen Wertschöpfungskette an ihre Partner abgeben (geringere Wertschöpfungstiefe), um auf diesem Wege flexibler und mit geringeren Kosten den veränderten Anforderungen des Marktes und vor allem dem stärkeren Wettbewerb global gerecht zu werden. Dieses hat unter der Annahme einer starken IT - gestützten Durchführung der Prozesse Auswirkungen auf die sich im Einsatz befindenden IV - Systeme. Parallel zu den steigenden Anforderungen an das Design und die Ausführung von Geschäftsprozessen sinkt die Reaktionszeit, die maximal verstreichen darf bis auf Veränderungen im Markt reagiert werden kann, ohne dass dadurch nachhaltige Auswirkungen auf das Unternehmen entstehen.[78] Diese Problematik ist in der folgenden Abbildung zum Ausdruck gebracht.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Aier et al. 2004, S. 6

Abbildung 3-2Veränderung der Reaktionszeit im Zeitverlauf

3.2 Anforderungen an überbetriebliche IV - Systeme

Entsprechend den Ausführungen aus dem Abschnitt 3.1 haben die neuen Herausforderungen Konsequenzen auf die sich momentan im Einsatz befindenden IV - Systeme. (CHAPPEL 2004) stellt in dem Buch Enterprise Service Bus fest, dass in den meisten Unternehmen zurzeit eine wie er sie bezeichnet Accidental Architecture existiert. Diese Architektur zeichnet sich dadurch aus, dass sie, weil sie historisch gewachsen ist, Anwendungen als Silos von Informationen[79] behandelt, die über die unterschiedlichsten Mechanismen miteinander verknüpft sind. Es fehlt eine konsistente und leicht zu wartende Infrastruktur (vgl. Abbildung 3-3). Aufgrund dessen sehen sich viele Unternehmen den folgenden Problemen[80] ausgesetzt:

- Heterogenität der Systemlandschaft[81] sowohl im Unternehmen als auch in Bezug auf die vom Geschäftspartner eingesetzten Anwendungssysteme, die über einen zwischenbetrieblichen Geschäftsprozess in Abhängigkeit zueinander stehen. Insgesamt herrscht bei den an der Wertschöpfungskette beteiligten Akteuren eingesetzten Anwendungssystemen eine große Komplexität an genutzten Anwendungssystemen sowie eine enorme Kompliziertheit in deren Beziehungen.
- Teure inflexible Integrationstechniken[82], die ein nicht akzeptables Risiko für das Unternehmen darstellen, vgl. (HAGEL 2002 S. 23): Swivel Chair Integration[83].
- Monolithische Geschäftsanwendungen, die ein hohes Maß an teurem Customizing[84] und Wartung erfordern[85]
- Locked in[86]Problematik beim Hersteller der eingesetzten Standardsoftware;
- Mangelnde Möglichkeit der automatisierten Prozessausführungen mit Geschäftspartnern und dadurch Effizienzeinbußen, möglicherweise sogar konkrete Nachteile aufgrund der fehlenden Fähigkeit an automatisierten Prozessen teilnehmen zu können.[87] Die Forderung nach loser Kopplung in den Beziehungen zwischen den Akteuren kann nicht erfüllt werden.

Abbildung in dieser Leseprobe nicht enthalten

Quelle : CHAPPEL 2004, S. 29

Abbildung 3-3 Accidental Architecture

Zur Überwindung der skizzierten Probleme und um den neuen Herausforderungen begegnen zu können, schlägt (HAGEL 2002, S.25) vier Prinzipien vor, nach denen eine neue Integrationsarchitektur zur Realisierung einer Funktionsintegration entwickelt werden muss. Auf diese Weise kann die Forderung nach Flexibilität der Prozesse auf IT – Ebene gewährleistet werden.

1. Einfachheit

Mit diesem Prinzip wird verlangt, dass der Aufruf einer Funktion[88], gekapselt in einem betrieblichen Anwendungssystem, auf einfache Art erfolgt. Die Komplexität bei der Funktionsintegration (vgl. Kapitel 2.2) soll auf die für die Integration notwendige Middleware[89] verlagert werden. Durch diese „Zentralisierung“ der Komplexität und der einfachen Bereitstellung der Funktionalität zum Verwalten und Herstellen von Kommunikationsverbindungen durch diese Middleware wird die Abhängigkeit zwischen den Endpunkten[90] gesenkt. Endpunkte sollen keine für eine spezifische Interaktion mit anderen Endpunkten notwendige Funktionalität implementieren.

2. Lose Kopplung

Das IV– System soll auf einer modularen Architektur basieren. Jedes Modul besitzt eine begrenzte Anzahl von öffentlichen Schnittstellen und unterstützt Standards für die Interaktion. Auf dieser Grundlage können die Module lose gekoppelt werden. Der Vorteil der losen Kopplung besteht zum einen in der einfacheren Herstellung der Kommunikation im Vergleich zu dem Punkt- zu- Punkt- Integrationsansatz (vgl. Kapitel 2.2.1) und zum anderen in der gestiegenen Flexibilität, die Kommunikationsverbindungen zu anderen Modulen leichter zu substituieren. Bisherigen Ansätzen zur Realisierung dieses Prinzips, darunter CORBA (Common Object Request Broker), ist die Umsetzung nicht gelungen, da nicht im ausreichenden Maße Standards für die Modulinteraktionen etabliert wurden, sowie aufgrund der hohen Komplexität bei der Definition von Schnittstellen (vgl. Kapitel 2.2.3 Kritische Punkte).

3. Heterogenität

Eine moderne Integrationsarchitektur zeichnet sich dadurch aus, dass sie die Unternehmensrealität einer heterogenen Systemlandschaft berücksichtigt. Existierende betriebliche Anwendungssysteme werden nicht ausgesondert, sondern stattdessen werden Mittel bereitgestellt, wodurch die in diesen gekapselten Funktionalitäten, auch im Sinne des Investitionsschutzes, wieder verwendet werden können.[91] Das erklärte Ziel ist eine Evolution der bestehenden Systeme durchzuführen, im Unterschied zu einer Revolution wie es (ULLMANN 2004) ausdrückt. Als Mittel zur Integration dieser Anwendungssysteme wird eine zusätzliche Softwareschicht benötigt, die die Kommunikation und Koordinierung mit anderen Systemen unterstützt.[92] Es dürfen keine Annahmen bzgl. der einzusetzenden Basissysteme[93] getroffen werden, um somit eine Plattformunabhängigkeit zu gewähren.

4. Offenheit

Eine Integrationsarchitektur muss auf weit verbreitete und akzeptierte Standards aufgebaut sein. Auf diese Weise kann der Locked-in Problematik entgegengewirkt werden. Durch die Verwendung von erweiterbaren Standards kann zu Beginn das Prinzip der Einfachheit realisiert werden, bei gleichzeitiger Wahrung der Möglichkeit zu einem späteren Zeitpunkt spezifische Anpassungen durchführen zu können. Für einen solchen Standard bietet sich als Datenaustauschformat XML an. Eine Integrationsarchitektur soll zudem die Chancen des Internets nutzen können, zum Beispiel durch die Möglichkeit der Integration von Funktionen, die nur im Internet bereitgestellt sind.

Diese vier Prinzipien definieren die Anforderungen, die an eine neue Architektur gestellt werden müssen. Im folgenden Abschnitt wird die SOA vorgestellt, die auf diesen Prinzipien basiert.

3.3 Serviceorientierte Architektur (SOA)

Eine SOA ist ein noch recht junger Begriff in der Softwaretechnik, für den momentan noch keine allgemein anerkannte Definition existiert.[94] Im Allgemeinen ist eine SOA ein Ansatz, um eine Integrationsarchitektur[95] auf Basis des Konzeptes Service zu realisieren wie es die IBM beschreibt.[96] Elementar für eine SOA ist demzufolge der Servicebegriff, der im nächsten Abschnitt erläutert wird. Im Anschluss daran folgt die Definition und Klärung des Begriffs SOA.

3.3.1 Anatomie eines Service

Ein Service ist nicht etwas grundsätzlich Neues in Bezug auf die Art und Weise wie Software zur Lösung von betrieblichen Aufgaben konzipiert wird, sondern baut auf schon bewährten Konzepten der Informatik auf.[97] Insofern kann der Service zunächst als eine Fortentwicklung dessen betrachtet werden. Die Konzepte im Einzelnen sind:

1. Objektorientierte Analyse und Design: Objekte sind nach (JACOBSEN 1994) dadurch gekennzeichnet, dass sie einerseits aus einer Menge von Operationen bestehen und andererseits aus einem Zustand, der die Effekte der Ausführung der Operationen speichert. In der Objektorientierten Analyse stammen diese Objekte aus der Fachdomäne (engl.: problem domain[98]), und werden zur Designzeit in logische Softwareobjekte transformiert. Im Anschluss werden diese Objekte in einer objektorientierten Programmiersprache implementiert. In objektorientierten Programmen bilden Objekte die Einheiten der Datenkapselung.
2. Komponentenbasiertes Design: das komponentenbasierte Design leitet sich nach (Rautenstrauch et al. 2003, S. 276) aus dem Objekt - Paradigma ab und stellt insofern eine Weiterentwicklung von diesem dar. Eine Komponente ist ein wieder verwendbares, für sich selbst stehendes, abgeschlossenes Stück Software, das unabhängig von bestimmten Anwendungssystemen ist.[99] Der Unterschied zu Objekten liegt sowohl in der Systemunabhängigkeit, in der unvorhersehbaren Einsetzbarkeit, in der unabhängigen Vermarktbarkeit als auch in der unterschiedlichen Granularität der gekapselten Funktionalität[100]. Grob-körnigere Komponenten bieten wohl definierte Funktionalität, die sich aus einer kohäsiven Menge fein granularer Objekte zusammensetzt.

Aufbauend auf diesen vorgestellten Konzepten versteht das serviceorientierte Design, einen Service als eine grobkörnige, auffindbare Software-Entität, welche in einer einzigen Instanz[101] existiert, die mit anderen Anwendungen oder Services über ein lose gekoppeltes, nachrichtenbasiertes Kommunikationsmodel interagiert.[102] Dabei wird der Service, bestehend aus einer zusammenhängenden Menge von vermarktbaren Diensten[103], über Computernetze einem autorisierten Nutzerkreis mit Hilfe von standardisierten Kommunikationsprotokollen über wohldefinierte Schnittstellenbeschreibungen angeboten.[104]

Ein Service erfüllt durch seine Dienste eine diskrete betriebswirtschaftliche Aufgabe im Rahmen eines Geschäftsprozesses.[105] Er stellt eine zusätzliche Ebene dar, die auf die im System gekapselte Funktionalität in Form von Anwendungssystemen (Legacy Anwendungen) oder Komponenten gelegt wird, und auf diese Weise nach innen wie auch nach außen hin exponiert werden kann, und somit Geschäftspartner für eine Geschäftsprozessintegration zur Verfügung gestellt wird.[106] In Abbildung 3-4 sind die den Service konstituierenden Ebenen dargestellt. Ziel der Modellierung in klar abgegrenzte Ebenen ist die Entkoppelung der Ebenen, um z.B. rein technische Veränderungen auf der Objektschicht unabhängig von der Servicedefinition durchführen zu können.[107] Damit kann der Service ebenso wie die Komponente eine Implementierungsunabhängigkeit für sich in Anspruch nehmen. Es besteht demnach keine invasive Anpassungsnotwendigkeit.[108]

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung in Anlehnung an IBM 2004c, S. 22

Abbildung 3-4 Services, Komponenten und Objekte

Der Service - Begriff ist technologieneutral; eine Möglichkeit einen Service zu implementieren kann auf Basis von Web - Services geschehen. Nach (Krammer et al. 2002) können für Web - Services und damit im Verständnis dieser Diplomarbeit[109] auch Services drei voneinander zu unterscheidender Spezialisierungen[110] identifiziert werden, die im Zusammenhang von EAI auf Basis einer SOA eine Rolle spielen.

- Typ 1: Publikation von Information

Dieser Typ stellt Informationen bereit. Dabei gilt für die gewählte Granularität der Information das kleinstmögliche noch betriebswirtschaftlich sinnvolle Maß. Der Service ist zustandslos und speichert dementsprechend keine Daten, die über die Zeit der Anfrage hinausgehen. Ein Beispiel für einen solchen Service wäre die Bereitstellung von Börsenkursinformationen.
- Typ 2: Funktionsbibliothek
Services von diesem Typ bieten eine Menge von einzelnen Diensten eines betrieblichen Aufgabenbereiches an. Der Service ist zustandsbehaftet und speichert die vom Nutzer angegebenen Daten oder das Ergebnis der Verarbeitung in einer eigenen Datenhaltungskomponente. Die vom Service bereitgestellte Funktionalität kann durch das Zusammenspiel mit lokalen oder anderen Services gebildet werden. Diese Abhängigkeiten machen eine feste Verknüpfung des Services mit den Teilen des Anwendungssystems nötig.

Ein Beispiel für einen solchen Service wäre die Lohnbuchhaltung. Hierfür verfügt der Service über eine eigene Datenhaltung, um die Angaben des Mitarbeiters zu speichern wie beispielsweise Familienstand und Steuerklasse. Aufgrund einer engen Verflechtung der Lohnbuchhaltung mit anderen Systemen der betrieblichen Anwendungslandschaft, wie dem Inkasso-/ Exkassosystem zur Buchung auf Kontokorrentkonten des Unternehmens, ist eine feste Verknüpfung mit anderen Services notwendig.

- Typ 3: Prozessbündel

Der Service in Form eines Prozessbündels entspricht der Bündelung mehrerer Einzelleistungen, die bei anderen Services nachgefragt werden. Auf diese Weise können Services erstellt werden, die eine komplexe Gesamtleistung bereitstellen, aber als ein einziger Service nachgefragt werden. Im Unterschied zur Funktionsbibliothek muss keine feste Verknüpfung zwischen den Services existieren, da eine Kopplung zwischen Services ad hoc erfolgen kann.

Für das Prozessbündel gilt, dass es sowohl zustandslos als auch zustandsbehaftet mit einer eigenen Datenhaltungskomponente existieren kann.

Ein Beispiel für diesen Typ ist die Auftragsabwicklung. Einzelprozessschritte entsprechen Diensten, die von unterschiedlichen Services erbracht werden können. Hierbei kann eine ad hoc Verknüpfung mit einem anderen Service notwendig sein, um dynamisch zur Laufzeit mit dem für die spezifische Situation günstigsten Logistikpartner in Kontakt zu treten.

Anhand der drei vorgestellten Typen von Services wird deutlich, dass von keinem einheitlichen Bild und auch keinem einheitlichen Verständnis vom Service - Begriff ausgegangen werden kann.[111] Im weiteren Verlauf dieser Diplomarbeit wird der Service - Begriff als ein Obergriff für die drei obigen Typen von Services verstanden. Für den Nutzer (Service - Konsument) sind die Implementierung und der Typ eines Services unerheblich; dieser betrachtet den Service lediglich als Endpunkt, welcher einen für den Aufrufer wichtigen Dienst bereitstellt.

Durchgängiges Prinzip und Voraussetzung für die Umsetzung des Servicekonzeptes ist die Verwendung von verbreiteten und akzeptierten Standards.[112] Diese Aussage bezieht sich zum einen auf die Definition der Schnittstellen eines Services, die die Voraussetzung für das dynamische Binden (engl. Dynamic Binding) darstellen und zum anderen auf die Service – Interaktion als solche, in Bezug auf den Transport von Nachrichten. Hierfür hat das W3C eine Vielzahl an XML - basierten Standards[113] definiert, die im Zusammenhang mit Web Services genutzt werden. Dieser Punkt wird bei der Diskussion über die Ebenen der Koordinierung von Services näher untersucht.

3.3.2 Klärung des Begriffs SOA

Nachdem der Begriff Service geklärt wurde, wird nun die Antwort auf die Frage gesucht, was sich hinter einer SOA verbirgt. Hier zunächst einige mögliche Definitionen:

“A service oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting to each other is needed.”[114]

SOA ist die Kunst, die derzeit verfügbaren Technologien und Standards so ins Zusammenspiel zu bringen, dass die Entwicklung und das Management von Diensten optimal unterstützt wird.“[115]

„Service-oriented Solutions […] Applications must be developed as independent sets of interacting services offering well-defined interfaces to their potential users. Similarly, supporting technology must be available to allow applications to browse collections of services, select those of interest, and assemble them to create the desired functionality.[116]

Diese Aussagen sind für den Zweck der Diplomarbeit zu allgemein und zu unkonkret. Aus diesem Grund spiegelt die folgende Definition nach Meinung des Autors die wesentlichen Attribute der SOA am besten wieder. Auf diese wird sich im Laufe der Arbeit ausschließlich bezogen, wenn die Rede von einer SOA ist:

„Der Kernansatz der SOA ist es, Services herzustellen, die plattformunabhängig, lose gekoppelt und auf einer Ebene der Geschäftsprozesse modelliert sind. Bei einem Vorgehen nach der SOA wird ein so genannter Servicearchitekturbus implementiert, der die Implementierungsdetails nach außen versteckt.“[117]

Die zentralen Elemente einer SOA sind demnach autonome Services (vgl. Abschnitt 3.3.1 Anatomie eines Service) deren Zwecke durch einen Geschäftsprozess bestimmt sind. Zur Implementierung dieser Architektur wird ein Servicearchitekturbus benötigt. (vgl. Abschnitt 3.3.3.2). Zur stärkeren Konkretisierung des Begriffs SOA stellt die folgende Tabelle eine Zusammenfassung der wichtigsten Eigenschaften einer SOA dar.[118]

Tabelle 3-1 Eigenschaften einer SOA

Abbildung in dieser Leseprobe nicht enthalten

Nach (PAPAZOGLOU 2003) ist in der folgenden Abbildung 3-5 die einfachste Variante einer SOA dargestellt. Sie wird auch als SOA Paradigma bezeichnet.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung in Anlehnung an IBM 2004c, S. 26 und mcgovern et al. 2003, S. 37

Abbildung 3-5 Find Bind Execute Paradigma (die Basis SOA)

Es besteht aus den folgenden Elementen, die in einer SOA miteinander kollaborieren.

· Service - Anbieter: Software-Entität, welche die Service- Spezifikation implementiert und im Netzwerk adressierbar ist. Diese führt die Anfragen des Service- Konsumenten aus (invoke Operation). Des Weiteren veröffentlicht der Service- Anbieter seinen Service beim Service- Verzeichnis (publish Operation).

- Service - Konsument: Software-Entität, die den Service- Anbieter mittels einer Serviceanfrage (invoke Operation) aufruft. Dies kann beispielsweise eine Endanwendung oder ein anderer Service sein. Der Service- Konsument findet einen Service durch eine Anfrage an das Verzeichnis über die Operation find. Im Anschluss findet der Aufruf dieses Services beim Service - Anbieter statt; die Festlegung auf das zu nutzende Transportprotokoll erfolgt durch den Binding Schritt.
- Service - Verzeichnis: Repräsentiert einen speziellen Dienst, auch als Maklerdienst bezeichnet, der das Nachschlagen eines Service ermöglicht (find). Es beinhaltet ein Verzeichnis aller veröffentlichten Services und ermöglicht die Suche innerhalb des Verzeichnisses.
- Contract[125]: Ein Contract (dt.: Vertrag) ist eine Spezifikation der Kommunikation zwischen Service - Konsument und Service - Anbieter. Er legt das Format der Anfrage und der Antwort fest. Zusätzlich können Vor – und Nachbedingungen an dieser Stelle definiert werden, die vor dem Aufruf des Services gelten sollen.[126] Des Weiteren können hier auch Angaben über die Dienstgüte (engl. Quality of Service) hinterlegt werden, welche dann im Rahmen eines Service Level Agreements[127] verwendet werden könnten.

Der Begriff Service im Verständnis eines „Software Service“ ist nicht neu.[128] Beispielsweise führte das Unternehmen Sun diesen Begriff bereits Ende der neunziger Jahre mit ihrer Technologie JINI ein.[129] Dies bedeutet, dass unter einer SOA nicht eine konkrete Technologie wie JINI oder wie die zurzeit häufig diskutierten Web – Services, und schon gar nicht eine Gleichsetzung von SOA und Web - Service[130] verstanden werden darf.

Vielmehr besteht der Zusammenhang zwischen SOA und einer dieser implementierenden Technologien darin, dass die Frage nach dem Einsatz einer SOA und damit einer Durchführung der Geschäftsprozesse auf Basis von Services eine strategische ist, während die konkrete Implementierung der Services mittels einer ausgewählten Technologie eher eine taktische Fragestellung ist.

Das Konzept SOA ist unabhängig von der Technologie. Abbildung 3-6 soll diesem Umstand Rechnung tragen und verdeutlichen, dass es sich bei einer SOA um eine Softwarearchitektur[131] handelt, welche mit Hilfe verschiedener Technologien realisiert werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung in Anlehnung an mcgovern et al. 2003, S. 37

Abbildung 3-6 Einordnung SOA

Zusammenfassend ist festzustellen, dass mit Hilfe einer SOA inner- wie überbetriebliche Geschäftsprozesse unter Nutzung der Vorteile, die sich aus der losen Kopplung sowie der Kapselung von Funktionalität zur Durchführung von betrieblichen Aufgaben in Services ergeben, einfacher und flexibler durchgeführt werden können. Diese Möglichkeiten bilden die Voraussetzung zur Bewältigung der in Abschnitt 3.1 genannten Herausforderungen.

3.3.3 Komposition von Services

Bis zu diesem Abschnitt wurde die SOA und deren Eigenschaften sowie der Service - Begriff geklärt. In dem nun folgenden Teil wird beschrieben wie Services kombiniert[132] werden können, um betriebliche Aufgaben im Sinne der im Abschnitt 3.2 vorgestellten Anforderungen an IV – Systeme zu bewerkstelligen.

3.3.3.1 Koordination

Die einzelnen Techniken oder Koordinierungsinstrumente, die im Rahmen der Komposition notwendig sind, damit Services arbeitsteilig eine bestimmte betriebliche Aufgabe bewältigen, lassen sich ausgehend von der zu unterstützenden betrieblichen Aufgabe und in Anlehnung an (ROHDE 1999, S. 106 -112) mit Hilfe des vorgeschlagenen Modells zur computergestützten Koordination in Wertschöpfungskooperationen systematisieren. So setzt die arbeitsteilige Bewältigung einer betrieblichen Aufgabe eine zielgerichtete Kooperation der jeweiligen Services voraus, die sowohl in zeitlicher als auch inhaltlicher Beziehung abgestimmt sein muss. Diese Aussage wurde von (TUROWSKI 2003) in Bezug auf die Komposition von Fachkomponenten getroffen. Nach Meinung des Autors kann diese aber auch auf den Service - Begriff angewandt werden.[133]

In Abbildung 3-7 sind die verschiedenen Ebenen, auf denen eine Koordinierung nach (TUROWSKI 2003) erzielt werden muss, wiedergegeben. Erst nachdem auf jeder der Ebenen eine Koordinierung durch Koordinierungsinstrumente gewährleistet ist, kann eine Servicekomposition umgesetzt werden. Diese formale Aussage deckt sich mit den Festlegungen der IBM zu einer SOA.[134]

Abbildung in dieser Leseprobe nicht enthalten

Quelle: TUROWSKI 2003, S. 154

Abbildung 3-7 Koordinationsebenen und Koordinationsinstrumente

Inhaltliche Abstimmung

Nach (TUROWSKI 2003) wird auf der Koordinationsebene Inhaltliche Abstimmung bestimmt, welcher Service zur Ausführung gebracht wird, wenn mehrere zur Bewältigung der nachgefragten Aufgabe zur Verfügung stehen oder wenn die Services eine sich überlappende Funktionalität bereitstellen.

Zur Erinnerung: Funktionalität wird wie in Abschnitt 3.3.1 beschrieben in Form von Schnittstellen angeboten. Ein fachlicher Konflikt im Sinne von sich überlappender Funktionalität bestünde dann, wenn sich zwei Services aus einem verwandten betriebswirtschaftlichen Problembereich in mindestens einer angebotenen Funktion, die durch einen Dienst über seine Schnittstelle bereitgestellt wird, gleichen. Zur Aufhebung dieses fachlichen Konfliktes existieren zwei Ansätze. Zum einen kann eine sich überlappende Funktionalität per Definition ausgeschlossen werden[135] und zum anderen existiert ein Konzept, welches auf atomare Services aufbaut. Diese atomaren Services sind die Bausteine[136] zur Komposition weiterer grob granularer Services. Kommt es nun zu einem fachlichen Konflikt, wird dieser über ein so genanntes Linkobjekt gelöst, indem über einen Indirektionsmechanismus entschieden wird, welcher Service aufgerufen wird.

Zeitliche Abstimmung

Mit der zeitlichen Abstimmung ist die Ausführungsreihenfolge von Services gemeint, um einen Workflow[137] zu realisieren. IBM hat hierfür den Begriff des Business Service Choreograph[138] (BSC) eingeführt. Im allgemeinen Sinn versteht man unter der zeitlichen Abstimmung ein Workflowmanagementsystem (WFMS).[139]

Pragmatik + Semantik + Syntax

Zur Realisierung der Kooperation ist eine Kommunikationsfähigkeit zwischen den Services grundlegend. Kommunikation zwischen Services findet auf Basis von ausgetauschten Nachrichten statt (vgl. Abschnitt 3.3.1). Hierfür muss zwischen den Kommunikationspartnern Klarheit über Semantik und Syntax der Nachricht herrschen. Zudem muss deutlich werden, was der Service - Konsument mit dem Aufruf des Services beim Service – Anbieter bewirken möchte (Pragmatik). Dies kann beispielsweise über SLAs[140] erfolgen.

Um das Ziel der Interoperabilität von Services in einem heterogenen Umfeld zu gewährleisten, müssen Standards definiert werden, um das syntaktische Verständnis von Nachrichten sicherzustellen.[141] Zurzeit existieren für Web – Services Standards, die einen syntaktischen Rahmen vorgeben wie Services beschrieben (WSDL), gefunden (UDDI) und Daten ausgetauscht werden (SOAP).[142] Für das Verständnis der Semantik eines Services müssen ebenfalls Standards etabliert werden, um sicherstellen zu können, dass der Service - Konsument und der Service - Anbieter das gleiche Verständnis über die ausgetauschten Nachrichten besitzen. Zurzeit existieren hierfür erste Ansätze im Rahmen von UDDI, in dem Services in Taxonomien eingeteilt werden können. Weitergehende Konzepte wie das Semantic Web mit dem die Semantik von Services beschrieben werden könnte, werden zurzeit noch nicht von UDDI unterstützt.[143] Zur Realisierung von Interoperabilität ist es grundlegend, dass für die Umsetzung dieser Ebenen weit verbreitete und akzeptierte Standards eingesetzt werden. Insbesondere für die Koordinierung von Web – Services hinsichtlich der Zeitlichen Abstimmung existieren Standards wie das WS – Transaction und WS – Coordination, welche als Ergänzung zu dem Business Process Execution Language For Web - Services (BPEL4WS)[144] Standard betrachtet werden.[145]

Kommunikationskanal

Nachrichten werden innerhalb einer SOA über Kommunikationskanäle vom Service - Konsumenten an einen Service - Anbieter verschickt. Nach (TUROWSKI 2003) basiert ein Kommunikationskanal, aus der technischen Perspektive heraus, auf einer Kommunikationstechnik, die auf die Schichten eins bis sechs des OSI- (Open Systems Interconnection) Referenzmodells aufbaut. Der Kommunikationskanal ist ein Koordinierungsinstrument für die Umsetzung des SOA Prinzips der losen Kopplung (vgl. Tabelle 3-1 Eigenschaften einer SOA) in der Weise, dass der Service - Konsument weniger Annahmen über den Aufruf des Service - Anbieters treffen muss. Er muss lediglich noch eine Kompositionstechnik zur Realisierung des Kommunikationskanals kennen, um den Service aufzurufen, anstatt für jeden Service – Anbieter, der den nachgefragten Dienst anbietet, unter Umständen eine speziellen auszuwählen (vgl. Kapitel 2: Punkt zu Punkt Verbindungen). Damit wird der Aufruf flexibel und unabhängig von der jeweiligen Service - Implementierung und der damit verbundenen jeweiligen Aufrufart. Es ist möglich Service - Anbieter zu substituieren, ohne dass dadurch die Art des Aufrufs von Seiten des Service - Konsumenten tangiert wird.[146]

3.3.3.2 Enterprise Service Bus (ESB)

Ein Koordinierungsinstrument zur Realisierung der Komposition von Services stellt der ESB dar. Ein ESB ist nach Darstellung von IBM zunächst als eine Erweiterung des bisherigen Bus - Konzepts zu verstehen.[147]

Das Bus– Konzept wurde im Kapitel 2 vorgestellt. Es wurde darauf hingewiesen, dass die Unterschiede zwischen Bus und Nabe & Speiche Architektur im Rahmen dieser Diplomarbeit auf der Ebene der Netztopologie zu betrachten sind. Im Verständnis der IBM zeichnet sich der Bus gegenüber der Nabe & Speiche Architektur bzgl. der Möglichkeit zur Kombination von mehreren Naben (Hubs) zu einem Bus aus,[148] wodurch eine verteilte Architektur von Hubs entsteht. Diese können im Bus – Konzept zentral administriert werden. Ein ESB besitzt die Eigenschaft, dass er innerhalb einer SOA, die Services, die an die Hubs gekoppelt sind, managen kann. Dieser Zusammenhang ist in der Abbildung 3-8 dargestellt. Das ESB – Konzept dient der Implementierung einer SOA, um eine EAI zu realisieren.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung in Anlehnung an IBM 2004b, S. 79

Abbildung 3-8 Einordnung ESB, Bus, Hub

Die elementare Aufgabe eines ESB, wie es die IBM definiert und in der Koordinierungsebene Kommunikationskanal (vgl. Abbildung 3-7) bereits vorgestellt wurde, besteht darin, eine Infrastruktur bereitzustellen, die es ermöglicht, die Serviceanfrage eines Service - Konsumenten an den Anbieter weiterzuleiten.[149] Hierbei soll der Nachrichtenaustausch[150] auf Standards basieren.[151] Damit können die Anforderungen zur Koordinierung auf Ebene von Pragmatik, Semantik und Syntax erfüllt werden. Weiterhin soll der ESB diese Fähigkeit innerhalb eines heterogenen Systemumfeldes sicherstellen.[152] Dabei soll der ESB gleichzeitig einfach zu administrieren sein, um Services schnell und unkompliziert an den ESB koppeln zu können. Auf diese Weise kann Funktionalität zur Erfüllung von betrieblichen Aufgaben „on demand“ zur Verfügung gestellt und die IT – gestützte Durchführung von Geschäftsprozessen flexibel an Veränderungen angepasst werden.[153]

Nach (buckley et al. 2004 und IBM 2004b, S. 76) soll der ESB ein ereignisgesteuertes[154] und dokumentenorientiertes[155] Verarbeitungsmodell besitzen. Als Basistechnologie greift der ESB nach (CHAPPEL 2004, S. 77 und S. 146) auf eine Message Oriented Middleware (MOM)[156] zurück. In Abbildung 3-9 sind die Infrastrukturkomponente ESB sowie die weiteren Softwarekomponenten, die zur Realisierung eines SOA notwendig sind, dargestellt.[157] Die Softwarekomponente Business Service Choreograph übernimmt als Koordinierungsinstrument in Anlehnung an (TUROWSKI 2003) die zeitliche Abstimmung zwischen den Services. Der ESB leistet durch die Realisierung des inhaltsbasierten Weiterleitens (Content Based Routing)[158] die inhaltliche Abstimmung von Services. Um Serviceanfragen an einen Service - Anbieter weiterleiten zu können, bedarf es Informationen (Routing informations). Die Bereitstellung dieser Informationen leistet das ESB Namensraum - Verzeichnis,[159] das einen Bestandteil der Implementierung des ESB darstellt. Von diesem Verzeichnis ist das Business Service Verzeichnis zu unterscheiden, welches auf einem anderen Abstraktionsniveau die Services in Taxonomien verwaltet und weitere Informationen zu der von den Services gekapselten Funktionalität zur Lösung von betrieblichen Aufgaben bereithält. Dieses Verzeichnis kann beispielsweise mittels UDDI realisiert sein.[160]

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung in Anlehnung an IBM 2004b, S. 81

Abbildung 3-9 Architektur einer SOA auf Basis eines ESB

Der ESB ist die Infrastrukturkomponente, die weder Geschäftslogik besitzt noch ausführt. Dieser Sachverhalt stellt einen Unterschied zu den Service - Konsumenten und Anbietern sowie dem Business Service Choreograph dar, welche innerhalb einer SOA basierten EAI - Lösung die Geschäftslogik implementieren und zur Ausführung bringen sollen.[161]

Nachdem die allgemeine Architektur eines ESB vorgestellt wurde, wird an dieser Stelle der schematische Aufbau des ESB dargestellt und die Funktionsweise sowie die wichtigsten Prinzipien, die diesem Aufbau zugrunde liegen, beschrieben.

Der ESB operiert in einer Zone,[162] innerhalb derer er das Management von Serviceanfragen und Serviceaufrufen leistet.

Die Kommunikation zwischen den Service - Konsumenten und Service - Anbietern wird über Ports[163] (im Unterschied zu Adaptern)[164] geregelt. Zu unterscheiden sind die eingehenden Ports (inbound Ports) zur Anfrage eines Service von den ausgehenden Ports (outbound Ports) zur Ausführung eines Service. Ein Port ist somit einem Service eindeutig zugeordnet.[165] Die Zuordnung oder Registrierung erfolgt als Konfigurationsschritt im ESB Namensraum - Verzeichnis.

Das auf der Koordinationsebene Kommunikationskanal (vgl.Abbildung 3-7) geforderte lose Koppeln von Services wird durch dieses Port - Prinzip realisiert, indem Services, die über einen ausgehenden Port ihre Schnittstellen veröffentlichen, durch eine Konfiguration des Systems substituiert werden können. Es muss hierzu lediglich in dem ESB Namensraum - Verzeichnis eine Anpassung in Form von Änderungen in den dort definierten Weiterleitungsregeln vorgenommen werden.[166] Der Service - Konsument muss über diese Änderung nicht informiert werden, da sein eingehender Port von dieser Änderung nicht betroffen ist. Die Abhängigkeit zwischen Konsument und Anbieter ist diesbezüglich nicht vorhanden.[167] Der ESB kann durch die Installation weiterer Ports spezielle Altanwendungen (Legacy Anwendungen) integrieren.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung in Anlehnung an IBM 2004b, S. 98

Abbildung 3-10 Allgemeiner Aufbau eines ESB

Die in der Abbildung 3-10 dargestellte Ellipse zwischen dem Service - Konsumenten und dem Port stellt die Perspektive dar, die der Service - Konsument auf den ESB hat und die er kennen muss, um mit diesem zu interagieren. An dieser Stelle werden auch Vereinbarungen über die Details der Service – Interaktion, d.h. Sicherheit, Fehlerbehandlung usw. getroffen.[168] Eine Implementierung eines ESBs wird typischerweise Ports anbieten, die auf verbreiteten und standardisierten Protokollen, wie z.B. SOAP und http, beruhen. Für die korrekte Weiterleitung der Anfrage an den ausführenden Service durch den Hub wird das ESB Namensraum - Verzeichnis genutzt, in dem die Namensräume und Weiterleitungstabellen verwaltet werden. Beim Aufruf eines eingehenden Ports wird der Namensraum durch den Konsumenten spezifiziert und damit konkretisiert, welcher Service bzw. welche Schnittstelle gemeint ist. Dieser Namensraumkontext ist in Abbildung 3-10 als Ellipse zwischen Port und Hub dargestellt[169]. Der Hub ist die ausführende Einheit innerhalb des ESBs. An dieser Stelle findet die Nachrichtenverarbeitung durch Ausführung von Weiterleitungsregeln als auch Transformationsvorschriften statt, die entweder im ESB Namensraum - Verzeichnis hinterlegt sind oder durch die Nutzung der Administrations - Services konfiguriert wurden (vgl. Kapitel 2.3.2, Funktionale Bestandteile von EAI). Wesentlich für einen ESB ist, dass nicht programmiert sondern nach (CHAPPEL 2004, S. 5) konfiguriert wird.

Der in Abbildung 3-10 dargestellte Business Service Choreograph zur Realisierung der zeitlichen Abstimmung wird selbst als Service[170] über einen Port angebunden.

Bezogen auf die im Kapitel 2 vorgestellten funktionalen Bestandteile einer EAI – Lösung lässt sich feststellen, dass das ESB – Konzept die dort beschriebenen Aufgaben erfüllt. Der Inhalt der folgenden Tabelle trägt zur Verdeutlichung dieser Aussage bei.

Tabelle 3-2 Funktionale Bestanteile von EAI im ESB

Abbildung in dieser Leseprobe nicht enthalten

Zusammenfassend lässt sich feststellen, dass das ESB - Konzept eine robuste, verwaltbare und verteilte Integrationsinfrastruktur auf Basis einer MOM bietet, die konsistent zu den Anforderungen einer SOA ist (vgl. Tabelle 3-1: Eigenschaften einer SOA). Der ESB ermöglicht die Interaktion von Services, die als implementierungsunabhängige Schnittstellen registriert und lose koppelbar sind. Aufgerufen werden diese über standardisierte Kommunikationsprotokolle[171]. Auf diese Weise kann die Interaktion plattformübergreifend erfolgen und somit Interoperabilität sowohl inner- als auch zwischenbetrieblich gewährleisten werden. Insofern entsprechen die Eigenschaften des ESB den am Anfang des Kapitels genannten Anforderungen an IT – Systeme vollständig. Eine Konkretisierung dieser Anforderungen wurde von der IBM[172] definiert, um die Möglichkeiten des ESB zu beschreiben. In Anlehnung an diese wurde ein Evaluierungsschema für ESBs erstellt (vgl. Anhang A.d), anhand dessen das nun im Folgenden vorgestellte Produkt untersucht wurde.

3.4 Prozessintegration mit SAP Netweaver

Im folgenden Abschnitt wird kurz das Netweaver Konzept der SAP vorgestellt und im Anschluss die Prozessintegrationskomponente dieser Lösung, die SAP Exchange Infrastructure 3.0, hinsichtlich ihrer SOA Eigenschaften untersucht. Des Weiteren wird der Schwerpunkt dieses Abschnittes darauf gelegt, wie die XI die Koordinierung von Services ermöglicht und somit der Funktionalität eines ESB entspricht. Diese Untersuchung wird am Ende des Kapitels mit einer Gegenüberstellung von ESB und XI abgeschlossen. Das Ziel des Netweaver- Konzeptes ist es eine Enterprise Service Architecture (ESA) auf Basis einer SOA (vgl. Abschnitt 1.3.) zu realisieren.[173] Der in dieser Arbeit verwendete Begriff ESA orientiert sich an der Beschreibung von (WOODS 2004).

3.4.1 Netweaver

Netweaver ist eine Vision der SAP, die vom Vorstandsmitglied Shai Agassi Anfang 2003 vorgestellt wurde.[174] Netweaver soll den Änderungen in den Geschäftsprozessen, die sich aus den neuen Herausforderungen, dargestellt in Abschnitt 3.1, Rechnung tragen, indem es erlaubt, die Prozesse aus modularen Services zusammenzusetzen, um betriebswirtschaftliche Aufgaben zu lösen.[175]

Es soll eine umfassende Integrations- und Applikationsplattform für die Lösungen innerhalb und über Unternehmensgrenzen hinweg realisieren.[176] Der Begriff Integration wird im Sinne von Netweaver sehr weit verstanden und beinhaltet ebenso eine Integration im Sinne von Kollaboration auf Mitarbeiterebene und Geschäftspartnerebene.[177] Bezogen auf die Integrationskonzepte, die bereits in Kapitel 2 vorgestellt wurden, handelt es sich dabei auf der Ebene von IV - Systeme um eine Funktionsintegration der an der Durchführung der Geschäftsprozesse unterstützend verwendeten Anwendungssysteme. Netweaver besteht organisatorisch aus den in Abbildung 3-11 dargestellten vier Kernbereichen, um die zuvor beschriebene Integrationsleistung zu vollbringen.

Abbildung in dieser Leseprobe nicht enthalten

Quelle: SAP LIBRARY 2004

Abbildung 3-11 Netweaver Architektur

People Integration

Ziel der People Integration ist eine weitgehend einheitliche, personalisierbare Oberfläche rollenbasiert zu präsentieren. Primäres Softwareprodukt der SAP ist hierfür das Enterprise Portal (EP), unter dessen Dach alle die für einen Mitarbeiter individuell wichtigen Anwendungen über eine einheitliche Oberfläche webbasiert (Single Point of Entry) zur Verfügung gestellt werden.[178] Zusätzlich umfasst die People Integration Groupware[179] ähnliche Funktionalitäten (wie z.B. Instant Messaging), die die Kollaboration unterstützen und somit diese auch effektiver gestalten. Das Portal unterstützt neben der üblichen HTML - basierten Browserschnittstelle noch weitere Informationskanäle[180], wie zum Beispiel WAP. Ein weiterer Aspekt der People Integration ist die Integration von Lieferanten und Kunden in das Unternehmen, beispielsweise in Form eines Extranets.[181]

[...]


[1] IV : informationsverarbeitende

[2] Vgl. Glossar

[3] Vgl. DUDEN 1982

[4] Vgl. Glossar

[5] Vgl. KAIB 2002, S. 10; vgl. Rautenstrauch et al. 2003, S. 223

[6] Vgl. FERSTL et al 2001, S. 217

[7] (FERSTL et al.2001, S. 217) verwendet den Begriff Aufgabensystem. In dieser Diplomarbeit werden die Begriffe IV – System, Aufgabensystem und betriebliches Anwendungssystem synonym verwendet.

[8] Vgl. LINß 1995, S. 217

[9] Vgl. KAIB 2002, S.10

[10] siehe Abschnitt 2.1.1

[11] Im Unterschied zu MERTENS 2004, S.1-5. Für die Diplomarbeit ist die an dieser Stelle getroffene gröbere Einteilung zielführender.

[12] Vgl. Schmietendorf et al. 2004 S. 10

[13] Als Funktion wird hier eine Aufgabe verstanden, die computergestützt durchgeführt wird. Vgl. Rautenstrauch et al. 2003, S.221

[14] Vgl. Rautenstrauch et al. 2003, S. 220

[15] Vgl. Argumentation von KAIB 2002, S. 17; aus diesem Grund können die Begriffe Funktion und Prozess im Zusammenhang mit dem Integrationsgegenstand synonym verwendet werden.

[16] Vgl. KAIB 2002, S. 17

[17] Vgl. KAIB 2002, S. 17

[18] Vgl. MERTENS 2004, S. 6

[19] Vgl. Mertens 2004, s.5

[20] Vgl. MERTENS 2004, S. 19

[21] Vgl. LINß 95, S. 26

[22] Vgl. KAIB 2002, S.20

[23] Vgl. KAIB 2002, S. 23

[24] beispielsweise Abteilungsgrenzen

[25] Vgl. MERTENS 2004, S.9

[26] Entsprechend der Abbildung 2-1 wäre dies die letztgenannte Ausprägung dargestellt im äußeren Ring.

[27] Vgl. KAIB 2002, S. 61

[28] Vgl. KELLER 2002, S. 63 -65

[29] Vgl. Aier et al. 2004, S. 35: User Interface Integration

[30] Vgl. KAIB 2002, S. 63

[31] Vgl. Aier et al. 2004, S. 36

[32] Vgl. KAIB 2002, S. 64

[33] Vgl. KELLER 2002, S. 67

[34] Vgl. EDS 2003, S. 53

[35] Mit dem Begriff Integrationsaufgabe ist die Bewältigung der Probleme zur Erreichung eines mit einem höheren Nutzen verknüpften Integrationsgrades gemeint.

[36] Vgl. EDS 2003, S. 53

[37] Vgl. KAIB 2002, S. 65

[38] Vgl. KAIB 2002, S. 66 – 67

[39] Vgl. EICKER et al 1992, S. 140

[40] Vgl. Klostermeier 2002

[41] Vgl. Aier et al. 2004, S.12: Anwendungssysteme, die basierend auf einer Client / Server Technologie zumeist in Form einer Individualsoftware erstellt wurden, wurden aufgrund eines höheren Nutzens entsprechend dem Geschäftsprozesses über Abteilungsgrenzen hinweg verknüpft.

[42] Vgl. HENSEL 2002: unternehmensstrategische Probleme

[43] Vgl. DIETRICH 2004, S. 139

[44] Vgl. KAIB 2002, S. 72

[45] Vgl. KAIB 2002, S. 102

[46] Vgl. CHAPPEL 2004, S. 84ff

[47] Vgl. Aier et al. 2004, S. 15

[48] Vgl. KAIB 2002, S. 83

[49] Vgl. KAIB 2002, S.81

[50] Vgl. WINKeLER 2000, S. 38

[51] Vgl. SAINI 2003, S. 26

[52] Vgl. KAIB 2002, S. 87

[53] aufgrund der einfacheren Möglichkeit zu skalieren.

[54] Vgl. KAIB 2002, S.102 - 118

[55] Vgl. KAIB 2002, S. 118

[56]Transaktionsfähigkeit kann auch schon durch entsprechende Middleware geleistet werden. Beispielsweise im Falle von RPC muss die Transaktionsfähigkeit für eine Folge von RPC Aufrufen durch eine bestimmte Anwendung des funktionalen Bestandteiles Nachrichtenmanagement bereitgestellt werden.

[57] Vgl. KAIB 2002, S. 120

[58] Vgl. Rautenstrauch et al. 2003, S. 267

[59] nach KAIB 2002, S. 121 zählen des Weiteren noch die Sicherheitsparameter und Verantwortlichkeiten, technologische Infrastruktur, Regeln und Logik für die Verarbeitung von Nachrichten sowie Design und Architekturinformationen zu den im dem Repository gehaltenen Informationen

[60] Vgl. KAIB 2002, S. 121

[61] Vgl. KELLER 2002, S. 47 fasst diese Anforderung unter Namensdienst zusammen.

[62] Vgl. Glossar

[63] Prozessüberarbeitung im Sinne eines Business Process Reengineering nach (CHAMPY et al. 1995).

[64] Im Rahmen dieser Diplomarbeit existiert beispielsweise ein Unterschied zwischen Service und der deutschen Übersetzung „Dienst“. Dienst im Verständnis von TUROWSKI 2003 unterscheidet sich grundlegend von dem, was in dieser Arbeit mit Service gemeint ist.

[65] Vgl. FAZ 2002

[66] Vgl. HAGEL 2002, S. 3

[67] Als ein Indiz hierfür kann die sinkende durchschnittliche Dauer, die ein Unternehmen in dem populären amerikanischen Aktienindex S&P 500 bleibt, angeführt werden.

[68] Vgl. SCHUMACHER 2003: Wirtschaft in Echtzeit

[69] Vgl. WOODS 2004, Nachwort S.189

[70] Vgl. Glossar

[71] Falls im Text nicht anders gekennzeichnet wird der Begriff Prozess synonym für Geschäftsprozess benutzt.

[72] Vgl. Chappel 2004, S. 1; MERTENS 2004, S. 9

[73] Der größte international tätige Handelskonzern.

[74] Vgl. Glossar

[75] Vgl. ANDERSON 2004, Trends in der Automobilindustrie nach dem Lean Manufacturing (vgl. Glossar)

[76] Vgl. HAGEL 2002, S. 69 am Beispiel Dell. Bisher war der Austausch eines Lieferanten in der Lieferkette mit hohen Kosten verbunden. Diese entstanden u.a. dadurch, dass eine starke Abstimmung der auf beiden Seiten eingesetzten Unternehmenssoftware erfolgen musste, was meist in properitären Konnektoren oder einer Swivel-Chair Integration endete. In der Konsequenz waren solche Beziehungen schwierig zu etablieren und stellen demzufolge eine hohe Wechselbarriere dar.

[77] Vgl. HAGEL 2002, Kapitel 7: Unbundle to Rebundle

[78] Beispielsweise könnten diese Auswirkungen, unter der Annahme der erweiterten Unternehmung, Einbußen bei der Wettbewerbsfähigkeit eines Produktes bedeuten. Diese könnten aus Gründen wie einer mangelnden Umsetzungsmöglichkeit von Produktinnovationen oder in Bezug auf die Etablierung eines automatisierten Bestellsystems (VMI) entstehen.

[79] (HAGEL 2002) stellt hierzu fest: notion of functional silos, fragmenting the enterprise with barriers to coordination across functions like marketing and sales created by incompatible IT – Systems or organizational structures.

[80] Vgl. WIEHLER 2004

[81] Vgl. KAIB 2002, S. 13

[82] Eine Integration der im Unternehmen existenten Anwendungssysteme findet nach CHAPPEL 2004 bisher über diverse Techniken wie zum Beispiel FTP, Direkte Socket Connections, properietäre MOM und manchmal CORBA oder andere Arten von RPC statt; nur vereinzelt werden EAI Lösungen eingesetzt, Vgl. Abbildung 3-3.

[83] Vgl. Glossar

[84] Vgl. Glossar

[85] Vgl. brown et al. 2002 schreiben dazu: „Rather, a software architect’s task is commonly that of extending the life of an existing solution by describing new business logic that manipulates an existing repository of data, presenting existing data and transactions through new channels such as an Internet browser, or handheld devices, integrating previously disconnected systems supporting overlapping business activities, and so on.” Vgl. hierzu auch VOLLMER et al. 2004, S. 3

[86] Vgl. Glossar

[87] Vgl. HAGEL 2002, S. 73; Situation bei WalMart für einige Lieferanten nach Einführung des VMI – Projektes.

[88] Vgl. Glossar

[89] Vgl. das Middleware – Integrationskonzept Kapitel 2.2.2

[90] Vgl. Glossar

[91] Vgl. Gallas 2004, S.185 und Ullmann 2004

[92] Beispielsweise Wrapper (Vgl. Glossar)

[93]Basissysteme stellen die Grundlage für den Betrieb von Anwendungssoftware dar. (vgl. RAUTENSTRAUCH et al. 2003, S. 280)

[94] Vgl. mcgovernet al. 2003, S. 36

[95] Vgl. Hagen 2004: Die Integrationsarchitektur ist ein Teilgebiet der IT– Architektur. Sie definiert Prinzipien, Prozesse und technische Lösungen für das Management der Verteilung und Heterogenität moderner Applikationslandschaften und der zugrunde liegenden technischen Plattformen.

[96] Vgl. IBM 2004b, S.37

[97] Vgl. IBM 2004c, S. 20-24

[98] Im einfachsten Fall dienen sie dazu, Dinge aus der realen Welt zu modellieren und damit zu abstrahieren.

[99] Vgl. RAUTENSTRAUCH et al. 2003, S. 275

[100] Vgl. MCGOVERN et al. 2003, S. 51

[101] Nach (KRAMMER et al. 2002, S. 3) gilt diese Aussage in Bezug auf Web Services nicht uneingeschränkt. Für diese Diplomarbeit wird nach (IBM 2004a, S. 21) hingegen diese Eigenschaft als charakterisierend für einen Service verstanden.

[102] Vgl. brown et al. 2002, S. 4

[103] Vgl. Glossar

[104] in Anlehnung an die Web Service Definition von Krammer et al. 2002, S.2

[105] Vgl IBM 2004c, S. 28; GOLD-BERSTEIN 2004

[106] Vgl. brown et al. 2002, S. 7

[107] Vgl. AIER et al. 2003, S. 25

[108] Vgl. EDS 2003a: Invasion verstanden als erzwungene Anpassung oder sogar Neuzuschnitt der Komponente

[109] Im Verständnis dieser Diplomarbeit sind Web - Services eine Variante von Services.

[110] (KRAMER et al. 2002, S. 4) verwenden den Begriff Ausprägungen des Service anstatt Spezialisierung. Nach Meinung des Autors ist der Begriff Spezialisierung treffender.

[111] Vgl. LAURES et al. 2005, S.42; LAURES stellt das SOA Blueprint Projek der „The Middleware Company“ vor. Dieses Projekt nutzt eine von der in dieser Diplomarbeit zu unterscheidende Service – Kategorisierung. Dadurch wird ein weiteres Mal das unterschiedliche Service – Begriffsverständnis unterstrichen. Das SOA Blueprint Project verwendet u.a. die Unterteilung von Services in Worfklow – Service, Daten – Service oder Abonnement – Service.

[112] Vgl. SAINI 2004, S. 62

[113] die wichtigsten Standards sind bzgl. des SOA Paradigmas:

· WSDL: Schnittstellendefinition

· SOAP: Nachrichtenprotokoll

· UDDI: Zur Realisierung des Verzeichnisdienstes

[114]Vgl. O.V.2003

[115] Vgl. ULLMANN 2004

[116] Vgl. brown et al. 2002, S. 4

[117] Vgl. HERZIG 2003

[118] Die Auflistung dieser Eigenschaften stammt maßgeblich aus mcgovern et al. 2003, S.41

[119] Vgl. MEYER 1997, S. 39-48 definiert 5 Kriterien, die festlegen ob eine Komponente ausreichend modular ist. Dieselben Kriterien lassen sich auf die Frage nach ausreichender Servicemodularität ebenfalls anwenden

[120] Vgl. HOFFMANN 2003

[121] Vgl. mcgovernet al. 2003, S. 50; grob granulare Services können durch die Konsolidierung von Komponenten auf einem physischen System, die Inter - Komponenten Kommunikation durch lokale Aufrufe realisieren.

[122] im Unterschied zum Objekt-orientierten Design, bei dem lediglich die Implementierung von der Schnittstelle getrennt ist, während mit dieser Eigenschaft verlangt wird, dass noch nicht mal die Schnittstelle bekannt sein muss. Es müssen nur die Informationen über den Aufruf der Services in Form eines Verzeichnisses abrufbar sein. Vgl. mcgovern et al., S. 2003, S. 59. Dies ermöglicht eine weitere Reduzierung der Abhängigkeiten zwischen Konsument und Service - Anbieter im Sinne der losen Kopplung.

[123] Vgl. Ullmann 2004

[124] Vgl. HAGEL 2002, S. 25

[125] Vgl. mcgovern et al.2003, S. 38

[126] Diese Forderung findet sich in mcgovern et al. 2003, S. 37

[127] Service Level Agreements definieren die Einhaltung der vereinbarten Qualität von Service und Verfügbarkeit.

[128] Vgl. Gallas 2004, S. 194

[129] Vgl. DEARING 2003

[130] Vgl. BRADLEY 2003; der Autor betont, dass es schwierig möglich sein wird, alleine auf Basis von Web - Service Standards eine EAI Lösung zu realisieren, aufgrund der im Unternehmen vorherrschenden monolithischen Anwendungen (vgl. Kapitel 3.2). Diese Anwendungen müssten für die Konsumption von Web - Services in der Rolle des Service - Anbieters umgeschrieben werden. Um dieses zu vermeiden, müssen zum einen Wrapper/ Adapter eingesetzt werden und zum anderen verschiedene Infrastrukturen (nicht nur http-basierend) unterstützt werden.

[131] Vgl. Glossar

[132] siehe Tabelle 3-1 Eigenschaften einer SOA – Zusammensetzbar; Im direkten Zusammenhang mit dem Service - Begriff spricht man auch von einer Orchestrierung von Services (Vgl. EDS 2003b, S.12) oder auch Choreographie von Services (Vgl. LEymann 2003). Die Kombination von Services entstammt der Begriffswelt der Komponenten. (Vgl. TUROWSKI 2003, S. 151)

[133] Eine kurze Gegenüberstellung von Web - Services mit Fachkomponenten nach Krammer et al. 2002 findet sich im Anhang A.b. Aus dieser geht hervor, dass eine Kombinierbarkeit von Web – Services in Bezug auf die erbrachte Leistung möglich ist. Dementsprechend sind auch für Web – Services Koordinationsinstrumente notwendig um eine Kombinierbarkeit erzielen zu können. Aufgrund der bereits erwähnten Beziehung zwischen Web – Services und dem allgemeinen Service - Begriff kann diese Aussage auf die Services ausgedehnt werden.

[134] Vgl. IBM 2004b, S. 39ff: Coupling and decoupling aspects of service interactions. Und S. 80ff: The role of the ESB and other SOA Components;

[135] Vgl. TUROWSKI 2003, S. 82

[136] Der Begriff "Baustein" wird an dieser Stelle verwendet, um Strukturelemente jedweder Art und Granularität zu beschreiben; auf diese Weise wird der Begriff Komponente vermieden.

[137] Vgl. Glossar

[138] Vgl. IBM 2004b, S. 49

[139] Systeme, die auf Basis von Workflow-Modellen anwendungsübergreifend die funktional und zeitlich korrekte Ablauffolge von Aktivitäten steuern und überwachen. Vgl. RAUTENSTRAUCH et al. 2003, S. 267.

[140] Mittels SLA können qualitative Aspekte der Serviceausführung garantiert werden.

[141]Vgl. IBM 2004b, S. 40: die verwendeten Objekttypen des Aufrufers sind bei einem geschäftsübergreifenden Prozess von denen des Service - Anbieters verschieden. Der Objekttyp Kunde ist in beiden Systemen unterschiedlich modelliert. Dennoch muss auf Basis von entsprechenden Standards ein Austausch von Kundendaten möglich sein.

[142] Vgl. DOSTAL et al. 2004

[143] Vgl. DOSTAL et al. 2004

[144] Vgl. Glossar

[145] Vgl. Schmietendorf et al. 2004, S. 34

[146] Vgl. IBM 2004b, S. 41

[147] Vgl. IBM 2004b, S. 78

[148] Vgl. IBM 2004b, S. 78 und CHAPPEL 2004, S.12

[149] Vgl. IBM 2004b, S. 76

[150] im Unterschied zu CORBA, welches objekt-orientiert ist, d.h. die Interaktion zwischen Konsument und Anbieter erfolgt über den Austausch von Objekte während bei einer SOA auf Basis eines ESB die Interaktion über Nachrichten erfolgt. Vgl. Gokhale et al 2002

[151] Vgl. SAINI 2004, S. 62

[152] Vgl. Gallas 2004, S. 207. Der Autor verwendet nicht explizit den Begriff ESB in seiner Publikation, er umschreibt aber mit dem von ihm gewählten Begriff eines servicebasierten EAI - Frameworks dieses Konzept.

[153] Vgl. SAINI 2004, S. 63

[154] Ereignis verstanden als Nachricht eines Endbenutzers oder Applikation, die vom ESB über einen Endpunkt „empfangen“ wird und dabei in ein für die Weiterverarbeitung internes Format transformiert wird. Vgl. BUSSLER 2003, S. 35

[155] Dokumentorientiert im Unterschied zu RPC-orientiert

[156] Für eine Übersicht über verschiedene Typen von Middleware vgl. ALONSO et al. 2004, S. 34 bzgl. MOM vgl. Kapitel 2.2.2

[157] Vgl. IBM 2004, S. 80

[158] Vgl. CHAPPEL 2004 S. 67, abhängig vom Inhalt der Nachricht wird diese an einen Service - Anbieter weitergeleitet.

[159] Vgl. IBM 2004b, S. 81

[160] Vgl. IBM 2004b, S. 81

[161] Vgl. IBM 2004b, S. 88

[162] vgl. IBM 2004b, S.91

[163] Eingehende und ausgehende Ports werden definiert durch:

· Protokoll

· Eine oder mehrere Adressen

· Durch die spezifische Art des Umganges von Service - Interaktionen wie zum Beispiel Transaktionalität, Sicherheit usw.

Ein eingehender Port hört auf einer spezifischen Adresse über ein spezifisches Protokoll. Ein ausgehender Port kann aus einer Menge von Adressen bestehen, die spezifisch für den Service sind. Hierbei muss das verwendete Protokoll das gleiche sein. Vgl IBM 2004b S. 97. Aufgrund einer nicht vorhandenen adäquaten deutschen Übersetzung für diesen Begriff, wird im Folgenden dieser Begriff genutzt.

[164] benötigen nicht den Overhead, der durch das Portkonzept entsteht. Sie stellen eine direkte Verbindung zum ESB dar

[165] Vgl. IBM 2004b, S.97

[166] Vgl. IBM 2004b, S.81. Die Weiterleitungsregeln können im ESB Namensraum - Verzeichnis oder in einer speziellen Weiterleitungstabelle (Routing Table) gespeichert sein.

[167] Weiterhin existiert die Abhängigkeit in Form der angebotenen Funktionalität; von dieser ist der Service - Konsument abhängig. Allerdings kann diese auch von einem anderen Service bereitgestellt werden. Es existiert keine direkte Abhängigkeit zwischen zwei Services.

[168] Vgl. IBM 2004b, S. 104

[169] Mit Hilfe des Namensraumes sollen Services die konzeptuell/ logisch eng in Beziehung stehen gruppiert werden. Beispielsweise ist es möglich, dass über einen ESB verschiedene gleichnamige Services wie GetCustomerAddress verwaltet werden. Um die korrekte Zuordnung von Aufruf und Ausführung des im Kontext gemeinten Services zu realisieren, bietet sich das Namensraum- (engl. Namespace) Konzept an. (Vgl. auch Abschnitt zur inhaltlichen Abstimmung: Fachkonflikt)

[170] (CHAPPEL 2004, S.109) unterscheidet zwischen Integration Services und Business Services, die alle flexibel an den ESB gekoppelt werden können. Der BSC fällt unter die erste Kategorie.

[171] Ein solches Protokoll wäre beispielsweise SOAP über das http - Protokoll

[172] Vgl. IBM 2004b, S.83

[173] Vgl. Mattern 2003, S. 38

[174] Vgl. Computer Zeitung Nr. 3/4 vom 20. Januar 2003 Seite 1

[175] Vgl. Woods 2003, S.4; Mattern 2003

[176] Vgl. Schneider-neureither 2004, S. 25

[177] Vgl. Schneider-neureither 2004, S. 20

[178] Vgl. hierzu MERRILL LYNCH 1998, S. 11:A trend has already taken hold within many of the Enterprise Information Portal segments is creating packaged Applications that provide targeted content to specific industries or corparte functions.

[179] Eine deutsche Bezeichnung wäre Kollaborationssoftware und bezeichnet eine Softwarelösung zur Unterstützung von Kooperationen über zeitliche und räumliche Grenzen hinweg.

[180] Als Kanal im informationstheoretischen Sinne (auch Informationskanal, Übertragungskanal oder Übertragungsweg) bezeichnet man ein Gerät beziehungsweise eine Vorrichtung, das zum Übermitteln von Informationen über räumliche oder zeitliche Distanz geeignet ist.

[181] Vgl. SCHUMANN 2003, S.12

Ende der Leseprobe aus 218 Seiten

Details

Titel
Integration und Verbesserung von geschäftsübergreifenden Prozessen
Untertitel
Fallstudie in der Energiewirtschaft auf Basis der Prozessintegrationslösung SAP XI 3.0
Hochschule
Otto-von-Guericke-Universität Magdeburg  (Wirtschaftsinformatik)
Note
1,0
Autor
Jahr
2005
Seiten
218
Katalognummer
V69733
ISBN (eBook)
9783638607544
ISBN (Buch)
9783640860166
Dateigröße
4270 KB
Sprache
Deutsch
Schlagworte
Integration, Verbesserung, Prozessen, Fallstudie, Energiewirtschaft, Basis, Prozessintegrationslösung
Arbeit zitieren
Oliver Budde (Autor:in), 2005, Integration und Verbesserung von geschäftsübergreifenden Prozessen , München, GRIN Verlag, https://www.grin.com/document/69733

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Integration und Verbesserung von geschäftsübergreifenden Prozessen



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden