Konzeption eines Integrationsmodells auf Basis der SAP Exchange Infrastructure, dargestellt am Beispiel der Tankdatenintegration bei den Berliner Stadtreinigungsbetrieben

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1 Einleitung und Überblick
1.1 Motivation
1.1.1 Vorstellung der Geschäftseinheit Informationstechnologie der BSR
1.1.2 Anwendungsportfolio der Berliner Stadtreinigungsbetriebe
1.1.3 Trends, die den Integrationsbedarf bei den BSR wecken
1.2 Zielstellung
1.3 Methodik

2 Grundlagen der Enterprise Application Integration
2.1 Definition und Abgrenzung der Enterprise Application Integration
2.2 Integrationsansätze
2.2.1 Punkt-zu-Punkt-Verbindung
2.2.2 Der Middleware-orientierte Integrationsansatz
2.2.3 Der ERP-basierte Integrationsansatz
2.3 Funktionale Bestandteile einer EAI-Lösung
2.3.1 Middleware
2.3.2 Adapter
2.3.3 Nachrichtenmanagement
2.3.4 Prozessmanagement
2.4 Kommunikationsmodelle
2.4.1 Synchrone Kommunikation
2.4.2 Asynchrone Kommunikation
2.5 Integrationsmodelle
2.5.1 Orientierung anhand des Ebenenmodells
2.5.2 Klassifizierung nach Integrationsmethoden
2.5.3 Klassifizierung nach EAI-Architekturen
2.6 Abgrenzung der EAI-Architektur von klassischer Middleware

3 Kommunikationstechnologien
3.1 Business Application Programming Interface (BAPI)
3.2 Kommunikationsdienste der SAP
3.2.1 Remote Function Call (RFC)
3.2.2 Intermediate Document (IDoc)
3.3 Webservices

4 Die SAP Exchange Infrastructure
4.1 Vorstellung der SAP Exchange Infrastructure
4.1.1 SAP NetWeaver
4.1.2 SAP Exchange Infrastructure
4.2 Komponenten der SAP Exchange Infrastructure
4.3 Architektur der SAP Exchange Infrastructure
4.3.1 Design-Zeit
4.3.2 Konfigurations-Zeit
4.3.3 Laufzeit
4.4 Möglichkeiten der Einbindung von Systemen
4.4.1 Proxy-Generierung
4.4.2 Adapter
4.5 Message-Austausch aus Anwendungssicht

5 Konzeption der Tankdatenintegration auf Basis der SAP XI
5.1 Betriebswirtschaftlicher Hintergrund
5.2 Ist–Stand
5.2.1 Grafische Darstellung der Ist-Architektur
5.2.2 Verbale Beschreibung der Ist-Architektur
5.2.3 Probleme
5.3 Projekt: Redesign der Tankdatenintegration
5.4 Fachlicher Projektkontext
5.4.1 Motivation für das Redesign
5.4.2 Phase 1: Software-Redesign
5.4.3 Phase 2: Redesign der technischen Architektur
5.4.4 Phase 3: Einführung der SAP Exchange Infrastructure
5.5 Redesign der technischen Architektur
5.5.1 Grafische Darstellung der Soll-Architektur
5.5.2 Verbale Beschreibung der Soll-Architektur
5.5.3 Spezifikation der Tank-Datei (CSV)
5.6 Entwicklung des Integrationsmodells für die Tankdatenanbindung
5.6.1 Vorgehensweise
5.6.2 Grafische Darstellung des Integrationsmodells
5.6.3 Grafische Darstellung des Integrationsablaufs
5.6.4 Verbale Beschreibung des Integrationsablaufs

6 Fazit
6.1 Überprüfung des Integrationsmodells
6.2 Nutzen des Integrationsmodells
6.3 Darstellung des Mehrwerts durch den Einsatz der SAP XI
6.3.1 Technischer Mehrwert
6.3.2 Betriebswirtschaftlicher Mehrwert
6.4 Ausblick
6.4.1 Zukünftige Anwendungsbereiche der SAP Exchange Infrastructure
6.4.2 Neue organisatorische Anforderungen
6.4.3 Zentrales Monitoring

Literaturverzeichnis

Internetverzeichnis

Anhang A: Implementierung

Anhang B: Das allgemeingültige Integrationsmodell

Anhang C: Die BSR-Systemlandschaft

Anhang D: Das OSI-Referenzmodell

Anhang E: Glossar

Ehrenwörtliche Erklärung

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Das Anwendungsportfolio der BSR

Abbildung 2: Bei den BSR eingesetzte SAP-Branchenmodule

Abbildung 3: Bei den BSR eingesetzte SAP-Standardmodule

Abbildung 4: Punkt-zu-Punkt-Verbindungen

Abbildung 5: Synchrone Kommunikation

Abbildung 6: Asynchrone Kommunikation

Abbildung 7: Semantische Integration und Nutzen der drei Integrationsebenen

Abbildung 8: Die drei Ebenen der semantischen Integration

Abbildung 9: Technologie-Hierarchie der SAP

Abbildung 10: Remote Function Call

Abbildung 11: Kernbereiche von SAP Netweaver `04

Abbildung 12: Fachbegriffmodell der SAP Exchange Infrastructure

Abbildung 13: Architektur der SAP Exchange Infrastructure

Abbildung 14: Beispiel einer Proxy-Proxy-Kommunikation

Abbildung 15: Kommunikation über Interfaces

Abbildung 16: Tankautomaten auf dem Regionalzentrum RF2

Abbildung 17: SAP-Tank -Architektur (Ist-Stand)

Abbildung 18: SAP-Tank -Architektur (Soll-Stand)

Abbildung 19: Auszug aus einer Tank-Datei

Abbildung 20: Integrationsmodell der Tankdatenintegration auf Basis der SAP XI

Abbildung 21: Integrationsablauf (Teil I)

Abbildung 22: Integrationsablauf (Teil II)

1 Einleitung und Überblick

Die Berliner Stadtreinigungsbetriebe (BSR) sind ein Unternehmen im stetigen Wandel. Die Umwandlung in eine Anstalt öffentlichen Rechts im Jahr 1994 machte den Weg frei für eine kontinuierliche Ausrichtung des Unternehmens an den sozialen, umweltorientierten und wirtschaftlichen Erfordernissen des Marktes.^[1]

1.1 Motivation

Dieser Wandel macht auch vor der Informationstechnologie nicht halt. Der folgende Abschnitt stellt die Geschäftseinheit Informationstechnologie der BSR sowie das aktuelle Anwendungsportfolio der Berliner Stadtreinigungsbetriebe vor. Im Anschluss werden konkrete Trends aufgezeigt, die den Integrationsbedarf bei den Berliner Stadtreinigungsbetrieben verdeutlichen.

1.1.1 Vorstellung der Geschäftseinheit Informationstechnologie der BSR

Die Geschäftseinheit Informationstechnologie ist der unternehmensinterne IT-Dienstleister für die gesamte Unternehmensgruppe der Berliner Stadtreinigungsbetriebe.

Sie stellt für nahezu 2.000 IT-Arbeitsplätze an über 40 Standorten in Berlin und Umgebung Netzwerk- und Kommunikationsdienste bereit. Darüber hinaus betreibt sie die zentralen

IT-Anlagen der BSR. Zur Unterstützung der Geschäftsprozesse ist das ERP-System SAP R/3 im Einsatz. Es wird zunehmend durch prozess- und dienstorientierte Unternehmenslösungen wie Supply Chain Management (SCM) und Customer Relationship Management (CRM) ergänzt.

Im Fokus der Geschäftseinheit steht neben der kontinuierlichen Verbesserung des ERP-Systems das wettbewerbsfähige Angebot von IT-Leistungen sowohl für die Geschäftseinheiten als auch für die Tochterunternehmen der BSR.^[2]

1.1.2 Anwendungsportfolio der Berliner Stadtreinigungsbetriebe

Das Anwendungsportfolio der BSR ist durch das ERP-System SAP/R3 Release 4.7 geprägt. Es umfasst AWision-Komponenten für die operativen Bereiche sowie SAP-Standardmodule für die dienstleistenden Bereiche. Mit AWision nutzen die Berliner Stadtreinigungsbetriebe eine eigenentwickelte Branchenlösung für die Entsorgungswirtschaft, die auf Standard-SAP/R3-Modulen aufsetzt. Für statistische Zwecke steht das Business Information Warehouse (SAP BW) zur Verfügung. Derzeit wird das Anwendungsportfolio durch ein CRM–System (SAP CRM) ergänzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Das Anwendungsportfolio der BSR

Quelle: Eigene Darstellung.

Kernanwendungen

In den operativen Bereichen sind vorwiegend Komponenten der eigenentwickelten Branchenlösung für die Entsorgungswirtschaft, AWision, im Einsatz. AWision steht für Applications for Waste-Management Integrated Solutions. Es setzt auf SAP R/3 auf und besteht aus mehreren Modulen, die der untenstehenden Grafik zu entnehmen sind.

An dieser Stelle sei auf das Modul SAP-Tank verwiesen. Das Modul SAP-Tank wird in Kapitel 5 dieser Arbeit zur praktischen Illustration des Integrationsmodells verwendet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Bei den BSR eingesetzte SAP-Branchenmodule

Quelle: Geschäftseinheit Informationstechnologie der BSR (2005 c), (siehe Internetverzeichnis).

Im Zuge eines gegenwärtig stattfindenden Restrukturierungsprojektes werden die bestehenden Kernanwendungen umstrukturiert.

Die bestehende Branchenlösung AWision bleibt in Teilen erhalten, wird jedoch nicht mehr weiterentwickelt. Statt dessen wird sie durch Standardkomponenten von SAP Waste and Recycling, der SAP-Branchenlösung für die Entsorgungswirtschaft, ergänzt.

Sekundäre Prozesse

Für die dienstleistenden Bereiche wie Buchhaltung oder Personalverwaltung werden die dargestellten SAP-Standardmodule eingesetzt.

Auch hier sind die Module SAP FI (Finanzwesen), SAP MM (Materialwirtschaft) und SAP PM (Instandhaltung) hervorzuheben. In ihnen werden die Tankdaten aus dem AWision-Modul SAP-Tank letztlich verbucht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Bei den BSR eingesetzte SAP-Standardmodule

Quelle: Geschäftseinheit Informationstechnologie der BSR (2005 b), (siehe Internetverzeichnis).

Statistikanwendungen

Neben den AWision-Komponenten für die operativen Bereiche und den SAP-Standardmodulen für die dienstleistenden Bereiche steht für statistische Zwecke das Business Information Warehouse (SAP BW) zur Verfügung. Das SAP BW schafft die notwendige Infrastruktur, um auf Basis einer SAP R/3-Lösung die betriebliche Controlling-Konzeption IT-technisch umzusetzen.

Verkauf- und Vertriebsanwendungen

Der Verkauf von Dienstleistungen funktioniert am besten, wenn beim Verkaufen das Wissen über den Kunden eingesetzt werden kann. So wird in Zukunft die Akquisition, Kundenbindung und Kundenrückgewinnung bei den BSR durch ein Customer Relationship Management (CRM) unterstützt. In Verbindung mit dem SAP Waste Management soll das CRM-System zukünftig den Verkaufsprozess im Hinblick auf integrierte Kundeninformationen optimieren.

1.1.3 Trends, die den Integrationsbedarf bei den BSR wecken

Die im Anhang C dargestellte IT-Systemlandschaft gibt einen Gesamtüberblick der zahlreichen Anwendungen und Schnittstellen der BSR. Dadurch wird deutlich, dass die Integration der Unternehmensanwendungen bei den BSR eine hohe Relevanz hat. Im Folgenden werden weitere Indikatoren aufgezeigt, die den Integrationsbedarf bei den Berliner Stadtreinigungsbetrieben unterstreichen.

Trend 1: Wandel der Geschäftsprozesse

Die IT-unterstützten Geschäftsprozesse wandeln sich häufig. Die daraus resultierenden funktionalen Anforderungen an die einzusetzende Software und die Integration in andere Systeme steigen. Die zeitnahe Realisierung der IT-Unterstützung eines geänderten Prozesses wird durch EAI-Lösungen erleichtert und kann einen wichtigen Wettbewerbsvorteil darstellen.^[3]

Bei den Berliner Stadtreinigungsbetrieben werden derzeit sowohl unternehmensweit als auch in zahlreichen Organisationseinheiten Restrukturierungsprojekte durchgeführt. Sie verfolgen hauptsächlich das Ziel, Geschäftsprozesse zu optimieren. Diese Restrukturierungsprojekte erfordern ein Geschäftsprozessmanagement, das durch eine auf die Prozesse abgestimmte IT-Landschaft unterstützt wird.

Trend 2: Kombination alter und neuer Software

Auch die Kombination alter und neuer Software weckt den Integrationsbedarf bei den Berliner Stadtreinigungsbetrieben.

- Weiterbetrieb von Legacy-Systemen

Im Zuge des y2k-Problems wurden teilweise beträchtliche Mittel in die Anpassung bestehender Legacy-Systeme (Altsysteme) investiert. Durch EAI-Lösungen können diese Altsysteme mit neu eingeführten Anwendungen verbunden werden und dadurch die heutigen Anforderungen erfüllen. Das beste Beispiel innerhalb der BSR bietet die Kombination des bestehenden AWision-Systems mit der neu einzuführenden Standardsoftware SAP Waste and Recycling.

- Einsatz neuer Standardsoftware

Das bisher umfassendste Restrukturierungsprojekt zielt auf die strategische Neuausrichtung des Verkaufsprozesses ab. In diesem Zusammenhang wird auch neue Standardsoftware eingeführt. Dazu zählen vor allem das bereits angesprochenen CRM-System sowie SAP Waste and Recycling. Die Verknüpfung von neuer Standardsoftware mit den bestehenden Systemen kann ein Grund für den für den Einsatz von EAI-Software sein.

Trend 3: Internet

Ein weiterer Treiber für den Einsatz von EAI-Software sind Projekte im Umfeld von

Business-To-Business (B2B) und Business-To-Consumer (B2C).

- Business-To-Consumer (B2C)

Unter Business-To-Consumer (B2C) sind elektronische Kommunikationsbeziehungen zwischen Unternehmen und Privatpersonen zu verstehen. So betreibt die Berlin Recycling GmbH, Tochterunternehmen der Berliner Stadtreinigungsbetriebe, ein Kundenportal. Über die URL http://www.berlin-recycling.de gelangen die Kunden der Berlin Recycling GmbH zu diesem Kundenportal. Dort können sie ihre Rechnungs- und Stammdaten 24 Stunden am Tag einsehen und Änderungen vornehmen.

- Business-To-Business (B2B)

Eine weitere Variante der Neugestaltung von Geschäftsprozessen ist das Business-To-Business (B2B). Die Berliner Stadtreinigungsbetriebe verfolgen das Ziel, Mitte diesen Jahres ihren zentralen Einkauf durch eine Lösung im Bereich des E-Procurement zu unterstützen. Durch die Beschaffung per Internet können die Kosten beim Einkauf deutlich reduziert und die Wettbewerbsfähigkeit gesteigert werden.

Trend 4: Verstärkte Zusammenarbeit mit den eigenen Töchtern

Der Mutterkonzern der BSR-Gruppe arbeitet auch in Bezug auf die Informationstechnologie verstärkt mit seinen Tochterunternehmen zusammen. Das zeigt sich beispielsweise in einem Application Service Providing (ASP) für Tochterunternehmen wie der Berlin Recycling GmbH oder Fuhrpark Business Service GmbH (FBS). Eine integrierte Systemlandschaft wird sich somit auch in Form von positiven Synergieeffekten auf die Tochterunternehmen auswirken.

Trend 5: Neue Standards

Neben den BSR-spezifischen Trends motivieren neue Standards wie Webservices, über den Einsatz einer EAI-Lösung nachzudenken. Die neuen Standards erleichtern den Datenaustausch und sind dadurch Katalysatoren für eine IT-Landschaft, die aus einer Vielzahl von integrierten Systemen besteht. EAI-Produkte stellen Funktionen zur Systemzusammenarbeit bereit und erlauben neue technologische Trends effizient in bestehende Architekturen zu integrieren.

1.2 Zielstellung

Die vorliegende Arbeit verfolgt das Ziel, ein allgemeingültiges Integrationsmodell für die Anwendungsintegration bei den Berliner Stadtreinigungsbetrieben zu entwickeln. Dieses Integrationsmodell basiert auf der konkreten EAI-Lösung SAP Exchange Infrastructure.

Das allgemeingültige Integrationsmodell wird auf den fachlichen Fall der Tankdatenanbindung bei den BSR abgeleitet.

Es bildet den konzeptionellen Rahmen zur Erstellung eines Prototypen für die Tankdatenanbindung. Damit wird das Integrationsmodell sowohl in einem fachlich repräsentativen Szenario als auch im technischem Kontext einer File/RFC-Verbindung eingesetzt.

1.3 Methodik

Problemstellung (Kapitel 1)

Das einleitende Kapitel motiviert die Auseinandersetzung mit dem Thema der Enterprise Application Integration. Dabei ist die Enterprise Application Integration als wesentlicher Bestandteil der IT-Strategie der Berliner Stadtreinigungsbetriebe anzusehen.

Das Kapitel 1 stellt die Geschäftseinheit Informationstechnologie der BSR sowie dessen aktuelles Anwendungsportfolio vor. Im Anschluss werden konkrete Trends aufgezeigt, die den Integrationsbedarf bei den Berliner Stadtreinigungsbetrieben verdeutlichen.

Die Erkenntnisse dieses Kapitels resultieren aus einer Recherche der BSR-Systemlandschaft, die von der Autorin in einer vorhergehenden Praxisphase aktualisiert wurde.

Analyse und Lösungsoptionen I: Enterprise Application Integration (Kapitel 2)

Die in Kapitel 2 dargestellten Inhalte basieren auf einer umfassenden Analyse des Themas der Enterprise Application Integration. In dieser Arbeit wurden dabei nur die Aspekte aufgenommen, die für das später entwickelte Integrationsmodell relevant sind. Diese Analyse dient als wesentliche Grundlage für die Vollständigkeit sowie für eine ausreichende Detailliertheit des Integrationsmodells.

Das Kapitel 2 geht auf die Basismodule einer EAI-Architektur näher ein. Es werden die wesentlichen Integrationsansätze der Enterprise Application Integration sowie die funktionalen Bestandteile einer EAI-Software erläutert. Darüber hinaus werden Kommunikations- und Integrationsmodelle beschrieben. Abschließend wird eine klare Abgrenzung zwischen der Enterprise Application Integration und traditioneller Middleware vorgenommen.

Diese Informationen sind hauptsächlich aktueller Fachliteratur sowie wissenschaftlichen Artikeln der Online-Datenbank Business Source Premier der Universität Freiburg entnommen. Business Source Premier ist die weltweit umfangreichste Volltext-Datenbank für den Bereich Wirtschaft. Sie enthält Volltext-Beiträge aus über 350 bedeutenden Wirtschaftszeitschriften.

Analyse und Lösungsoptionen II: Konkrete Technologien (Kapitel 3)

Die Beschäftigung mit konkreten Kommunikationstechnologien sorgt für die Übereinstimmung des nachfolgend entwickelten Integrationsmodells mit den bei den BSR aktuell eingesetzten Technologien.

Das Kapitel 3 gibt einen Überblick über die etablierten SAP-Kommunikationstechnologien für eine systemübergreifende Integration. Zum anderen geht es auf Webservices ein, die in der SAP Exchange Infrastructure eine wesentliche Rolle spielen.

Synthese: Verbindung aus Lösungsoption I (EAI) und Lösungsoption II (Technologien) in der konkreten Ausprägung der SAP Exchange Infrastructure (Kapitel 4)

Das Kapitel 4 stellt die SAP Exchange Infrastructure (SAP XI) mit seinen Hauptkomponenten, wesentlichen Funktionalitäten und seiner Architektur vor. Grundlage dieser Darstellung bilden die Erkenntnisse aus den Kapiteln 2 und 3. Sie stellen die SAP Exchange Infrastructure als konkrete Lösungsoption hinsichtlich einer BSR-adäquaten EAI-Strategie und der konkreten BSR-Kommunikationstechnologien dar.

Die Erkenntnisse der Architektur und Funktionsweise der SAP Exchange Infrastructure beruhen auf internen SAP-Schulungsunterlagen der XI-Zertifzierung, aktuellster Fachliteratur, der Online-Hilfe der SAP sowie der praktischen Anwendung der SAP XI im konkreten Anwendungsszenario des SAP-Tank-Prototypen.

Anwendung des Integrationsmodells als praktischer Vollständigkeits- und Korrektheits-nachweis (Kapitel 5)

Den Kern des 5. Kapitels bildet die Entwicklung eines Integrationsmodells und dessen praktische Anwendung am Beispiel der Tankdatenintegration auf Basis der SAP Exchange Infrastructure.

Das Integrationsmodell wird aufbauend auf den gewonnen Erkenntnissen der Kapitel zwei bis vier entwickelt. Mit diesem Schritt soll der praktische Nachweis geführt werden, dass

- die Gewichtung und Fokussierung in den Analyse-Phasen
- als Grundlage der Erstellung des Integrationsmodells sowie
- dessen Anwendung im gewählten Kontext auf Grundlage der SAP XI

ein praktikables Ergebnis mit Mehrwert für die BSR erbracht hat.

Fazit und Ausblick (Kapitel 6)

Das sechste Kapitel gibt ein Fazit der Arbeit sowie einen Ausblick auf die weitere Vorgehens-weise. In Kapitel 6 wird der technische und betriebswirtschaftliche Mehrwert des Einsatzes der SAP Exchange Infrastructure herausgearbeitet. Abgerundet wird die Arbeit durch einen Ausblick, der Ansatzpunkte für die weitere Vorgehensweise gibt.

2 Grundlagen der Enterprise Application Integration

Der Aufbau einer EAI-Architektur beinhaltet unterschiedlichste Technologien. Diese lassen sich in folgende Basismodule einteilen:

- Kommunikationsmodell,
- Integrationsmodell und
- Middleware.^[4]

Um das Verständnis der später vorgestellten SAP Exchange Infrastructure zu fördern, wird im folgenden Kapitel auf diese Basismodule einer EAI-Architektur näher eingegangen. Sämtliche Basismodule sind in einer EAI-Architektur strukturiert und integriert wieder zu finden.

Nach einer kurzen Begriffsdefinition werden die wesentlichen Integrationsansätze der Enterprise Application Integration dargestellt. Im Anschluss werden die funktionalen Bestandteile einer EAI-Software mit Fokus auf die Middleware erläutert. Daraufhin werden die Kommunikationsmodelle vorgestellt, um die grundlegenden Formen des Informationsaustauschs über die Middleware zu verdeutlichen. Die im Folgenden vorgestellten Integrationsmodelle beschreiben Möglichkeiten, wie die zu integrierenden Systeme klassifiziert werden können. Abschließend wird nochmals eine klare Abgrenzung zwischen der Enterprise Application Integration und traditioneller Middleware vorgenommen.

2.1 Definition und Abgrenzung der Enterprise Application Integration

Enterprise Application Integration (EAI) bezeichnet die Integration von Anwendungssystemen und Daten in heterogenen IT-Anwendungsarchitekturen auf Daten-, Applikations- und Geschäfts-prozessebene. Die Integration kann dabei sowohl innerhalb eines Unternehmens, als auch über Unternehmensgrenzen hinweg zu Geschäftspartnern und Kunden erfolgen.^[5]

Der Lösungsansatz einer EAI-basierten Systemlandschaft baut darauf auf, die Kommunikation zwischen verschiedenen Systemen und Anwendungen innerhalb einer Systemlandschaft durch Standardisierung der Schnittstellenkonzeption zu vereinfachen und zu beschleunigen.^[6] Dabei handelt es sich um die Konvertierung von Daten und Befehlen aus dem Format einer Anwendung in das einer anderen, um den Datenaustausch zwischen inkompatiblen Anwendungen zu ermöglichen.^[7]

2.2 Integrationsansätze

Seit Jahren werden immer neue Formen entwickelt, um interne Anwendungen zu integrieren. Der folgende Abschnitt stellt drei Grundtypen der Anwendungsintegration vor. Sie spielen im Zusammenhang mit den EAI-Diskussionen eine wesentliche Rolle. In der Praxis sind vor allem Mischformen dieser Grundtypen anzutreffen.

2.2.1 Punkt-zu-Punkt-Verbindung

Als Punkt-zu-Punkt-Verbindung wird eine dedizierte Verbindung zwischen zwei gleich-berechtigten Systemen bzw. Anwendungen bezeichnet. Zur Integration mehrerer Systeme bzw. Anwendungen besteht also jeweils eine eigene Verbindung.^[8]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Punkt-zu-Punkt-Verbindungen

Quelle: Eigene Darstellung.

Die Architektur der Punkt-zu-Punkt-Verbindung stellt das Resultat von gewachsenen Strukturen dar. Neu entwickelte oder erworbene Anwendungen werden nach und nach in die bestehende Systemlandschaft integriert.^[9]

Bei dieser Architektur erfolgt ein Mapping Punkt-zu-Punkt. Unter Mapping wird die Konvertierung von Daten vom Ausgabeformat der einen Anwendung in das Eingabeformat der anderen Anwendungen verstanden. Da dieses Mapping im aufrufenden Code der Quellanwendung programmiert werden muss, ist sowohl der Eigenentwicklungsbedarf als auch die Wartung der Schnittstellen sehr hoch.^[10] Das durch Punkt-zu-Punkt-Verbindungen häufig entstehende „Spaghettisystem“ macht eine nahtlose Integration teilweise unmöglich. Darüber hinaus kommt es zu Reibungsverlusten durch inhomogene und inkonsistente Daten sowie eine zeitliche Verzögerung bei der Datenbereitstellung.^[11]

2.2.2 Der Middleware-orientierte Integrationsansatz

Beim Middleware-orientierten Integrationsansatz wird zwischen zwei oder mehreren Systemen eine vermittelnde Softwareschicht, die Middleware, geschaltet. Sie ermöglicht Systemen und Anwendungen unterschiedlicher Hersteller plattformunabhängig zu kommunizieren und Daten auszutauschen.^[12] Auf diese Weise erfolgt die Integration in einer stärker standardisierten Weise als bei Punkt-zu-Punkt-Verbindungen.

Auf die Bedeutung und Funktionsweise der Middleware wird in Punkt 2.3.1 noch näher eingegangen.

2.2.3 Der ERP-basierte Integrationsansatz

Fortschritte bei der Anwendungsintegration haben viele Unternehmen mit der Einführung von ERP-Systemen gemacht, in denen alle geschäftskritischen Prozesse abgebildet werden. Das ERP-System übernimmt dabei die Rolle einer zentralen EAI-Plattform, die durch branchen- oder unternehmensspezifische Anforderungen anderer Anbieter ergänzt wird.^[13] Diese Systeme und Anwendungen werden über die Standardschnittstellen des ERP-Systems angeschlossen. Für diese Schnittstellen gibt es verschiedene Integrationsmechanismen, die vom simplen Datenimport über Remote Procedure Calls (RPC) bis hin zur Integration über Application Programming Interfaces (API) reichen.^[14]

ERP-Systeme kommen dem Anspruch der Anwendungsintegration weitestgehend nach, doch gehen EAI-Systeme noch weiter. Bei der ERP-basierten Integration besteht jedoch die Gefahr der Entwicklung einer komplexen Schnittstellenlandschaft ähnlich der Punkt-zu-Punkt-Verbindungen.^[15]

2.3 Funktionale Bestandteile einer EAI-Lösung

Zu den wesentlichen funktionalen Bestandteilen einer EAI-Lösung gehören

- Middleware,
- Adapter,
- Nachrichtenmanagement und
- Prozessmanagement.

2.3.1 Middleware

Der zentrale Bestandteil von EAI-Lösungen ist die Middleware. Sie unterstützt die Integration auf Datenebene, indem sie den Austausch von Informationen zwischen mehreren Anwendungs-systemen in einer heterogenen IT-Landschaft ermöglicht. Im Rahmen des OSI-Referenzmodells ist Middleware daher den anwendungsorientierten Protokollen der Ebenen 5-7 zuzuordnen. Eine Abbildung des OSI-Referenzmodells ist dem Anhang D zu entnehmen.^[16]

Allgemein bezeichnet Middleware jede Art von Software, die eine Vermittlerrolle zwischen zwei oder mehreren über ein Netzwerk kommunizierenden Softwarekomponenten übernimmt. Die Middleware nimmt Nachrichten entgegen und stellt sie einem Empfänger zu. Neben dieser Nachrichtenverteilung übernimmt die Middleware weitere Aufgaben wie:

- die Konvertierung der Nachrichten zwischen den Formaten des Senders und des Empfängers,
- die zeitversetzte Auslieferung einer Nachricht, wenn Sender und Empfänger verschiedene Arbeitsgeschwindigkeiten haben,
- die Ansteuerung und Überwachung von Automatisierungs- und Workflowdiensten,
- die Bereitstellung von offenen Kommunikationsschnittstellen für verteilte Anwendungskomponenten sowie
- den Zugriff auf unterschiedliche, verteilte Datenquellen.^[17]

In den letzten Jahren hat sich die Middleware immer weiterentwickelt. Derzeit lässt sie sich in bis zu fünf verschiedene Gruppen einteilen.

Die Funktionsaufruforientierte Middleware

In der modularen Programmierung werden logisch zusammengehörende Programmteile in Funktionen zusammengefasst. Soll eine bestimmte Funktion ausgeführt werden, wird sie mit ihrem Namen und den Parametern aufgerufen.

Bei verteilten Anwendungen befinden sich die einzelnen Funktionen auf mehreren Systemen. Der Aufruf einer auf einem entfernten System installierten Funktion über ein Netzwerk wird Remote Procedure Call (RPC) genannt. Diese Technologie bildet die Grundlage aller Client/Server-Systeme.^[18]

Die Kommunikation über RPCs findet synchron statt. Das hat den Nachteil, dass das Clientprogramm während des Prozeduraufrufs so lange blockiert ist, bis das Serverprogramm geantwortet hat. Ein weiterer Nachteil besteht in dem erhöhten Wartungsaufwand in Folge der Aktualisierung einer Komponente. Da die Definition des Funktionsaufrufs fester Bestandteil des Programmcodes ist, muss dieser bei allen abhängigen Systemen angepasst werden.^[19]

Die Datenzugriffsorientierte Middleware

Bei der Datenzugriffsorientierten Middleware handelt es sich um die klassische Middleware. Sie liegt dem Ansatz föderativer Datenbanken zugrunde.

Die datenzugriffsorientierten Middleware ermöglicht den transparenten Zugriff auf heterogene Daten über eine einheitliche Schnittstelle.^[20] Zu den bekanntesten Verfahren datenzugriffs-orientierter Middleware zählen Application Programming Interfaces (API) und Call Level Interfaces wie ODBC oder JDBC.

Durch die Definition zusätzlicher Softwareschnittstellen reduziert sich der Wartungsaufwand bei komplexeren Systemen im Vergleich zu Remote Procedure Calls. Nachteilig ist jedoch zu beurteilen, dass bei dieser Form von Middleware nur die Datenintegration angesprochen wird.^[21]

Die Messageorientierte Middleware

Die Messageorientierte Middleware (MOM) unterstützt die Kommunikation zwischen verteilten Systemkomponenten über den Austausch von Nachrichten.

Der Client sendet eine Nachricht an den Server, um einen Dienst auszuführen. Der Server schickt das Ergebnis dann wieder als Nachricht zurück an den Client.

Dabei werden ankommende Nachrichten in einer Warteschlange (Queue) aufbewahrt. Die Kommunikation über die Messageorientierte Middleware findet hauptsächlich asynchron statt.^[22]

Durch den Einsatz der Message Queue hat die Messageorientierte Middleware den Vorteil, dass bei einem Netzwerkausfall keine Nachricht verloren gehen. Darüber hinaus kann ein Rechner jederzeit Nachrichten empfangen, ohne diese sofort bearbeiten zu müssen.^[23]

Die Transaktionsorientierte Middleware

Bei einer Transaktion handelt es sich um eine Folge von Operationen, die entweder erfolgreich abgeschlossen wird oder im Fehlerfall zu einer Wiederherstellung des Ausgangszustandes führt. Dabei unterliegt die Transaktion dem ACID-Kriterium (Atomicity, Consistency, Isolation, Durability), das eine zuverlässige Informationsverarbeitung gewährleistet. Transaktionsorientierte Middleware zielt ähnlich wie die RPCs auf den Zugriff auf andere Programmsysteme über ein Netzwerk ab. Der Unterschied zu RPCs liegt darin, dass dabei vollständige Transaktionen und nicht mehr einzelne Funktionen betrachtet werden. Der Vorteil Transaktionsorientierter Middleware liegt demnach in der zuverlässigen Verarbeitung von Transaktionen durch Einhaltung der ACID-Kriterien.^[24]

Die Komponentenorientierte Middleware

Die Komponentenorientierte Middleware basiert auf einer besonderen Kommunikationsschicht, dem Object Request Broker (ORB). Dieser überträgt das Konzept des Remote Procedure Call auf die Objektorientierung.

Das Grundprinzip funktioniert ähnlich wie ein RPC-Call, jedoch objektorientiert. Existieren verschiedene Objekte in einem Netzwerk, bedeutet das Senden von Nachrichten nichts anderes als das Aufrufen einer Methode eines Objektes. Dabei werden die Nachrichten über den Object Request Broker übertragen. Dieser baut die Kommunikation zwischen zwei Komponenten nach dem Client/Server-Prinzip auf. Der Client ruft dabei eine Methode des Serverobjekts auf. Der bekannteste Object Request Broker ist der Common Object Request Broker (CORBA).^[25]

Der wesentliche Vorteil der Komponentenorientierten Middleware besteht in der zusätzlichen Kommunikationsschicht. Sie stellt unter anderem Dienste zur Koordination der Transaktionen, Ereignisse und Sicherheit der Übertragung zur Verfügung.^[26]

2.3.2 Adapter

Adapter sind vorgefertigte Softwarebausteine, die auf physischer Ebene die Kommunikation zwischen verschiedenen Systemen unterstützen. Dazu werden sie zwischen die zu integrierenden Anwendungen geschaltet.^[27]

Typischerweise unterstützen Adapter lediglich die technische Kopplung von Systemen durch eine standardisierte Verständigung („thin adapters“). Zunehmend werden aber auch „thick adapters“ angeboten, die zusätzlich Anpassungen zwischen den Anwendungen auf semantischer Ebene, wie etwa der Transformation von Daten zwischen Quell- und Zielsystem, übernehmen.

Zudem können Adapter nach ihrem Verhalten unterschieden werden. Normalerweise sind Adapter statisch, d.h. Informationen bezüglich der zu integrierenden Anwendung werden im Zuge einer Konfiguration eingetragen. Dynamische Adapter besitzen zusätzlich Mechanismen, diese Konfiguration automatisch zu aktualisieren, etwa wenn sich das Schema einer angebundenen Datenbank verändert.^[28]

2.3.3 Nachrichtenmanagement

Ein weiterer Bestandteil einer EAI-Lösung ist das Nachrichtenmanagement. Es dient der Programmintegration und stellt damit die Verbindung zwischen den angebundenen Systemen auf semantischer Ebene her.

Wesentliche Bestandteile des Nachrichtenmanagements sind die Bereitstellung von Transformations- und Synchronisationsdiensten sowie die Gewährleistung der Transaktionalität der EAI-Lösung.^[29]

2.3.4 Prozessmanagement

Durch die Prozessmanagementfunktion heben sich EAI-Systeme wesentlich von der traditionellen Middleware ab. Das Prozessmanagement erlaubt es, das Zusammenspiel komplexer Transaktionen basierend auf den entsprechenden Geschäftsprozessen zu definieren und zu steuern. Dadurch können Workflows umgesetzt werden, die über verschiedene Systeme und Organisationen reichen können. Das Prozessmanagement umfasst die Prozessmodellierung, Prozesssteuerung und Prozesskontrolle.^[30]

2.4 Kommunikationsmodelle

Ein Kommunikationsmodell legt fest, auf welche Art und Weise Informationen ausgetauscht werden. Die Kommunikation zwischen zwei Systemen lässt sich grundsätzlich zwischen synchroner und die asynchroner Kommunikation unterscheiden. Dieser Abschnitt stellt beide Kommunikationsmodelle mit ihren möglichen Realisierungsformen vor. Dabei werden die spezifischen Vor- und Nachteile kurz angerissen.

2.4.1 Synchrone Kommunikation

Bei synchroner Kommunikation wird nach dem Versenden eines Request eine Response-Message vom Empfänger erwartet. Nach dem Versenden der Request-Message ist daher der sendende Prozess so lange blockiert, bis die Antwort zum Request beim Sender eingegangen ist.^[31]

Die synchrone Kommunikation arbeitet mit einem einmaligen Funktionsaufruf. Dies setzt voraus, dass zum Zeitpunkt des Aufrufs (bzw. der Nachrichtenversendung) auch das Empfängersystem aktiv ist und den Aufruf sofort entgegennehmen und gegebenenfalls weiterverarbeiten kann. Andernfalls kann es zu schwerwiegenden Störungen der Prozessabläufe kommen.^[32]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Synchrone Kommunikation

Quelle: Eigene Darstellung.

Die synchrone Kommunikation kann vorteilhaft bei Funktionsaufrufen eingesetzt werden, die die sofortige Rückgabe von Daten an das Sendersystem erfordern. Die synchrone Kommunikation kann über Request/Reply, One-Way und Polling realisiert werden.^[33]

Tabelle 1: Realisierungsvarianten synchroner Kommunikation

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

2.4.2 Asynchrone Kommunikation

Bei asynchroner Kommunikation wird keine (direkte) Antwort erwartet. Ein sendender Prozess kann mehrere Messages gebündelt an einen Empfänger schicken und mit der Ausführung des Prozesses fortfahren. Ist das Empfängersystem nicht ansprechbar, wird der Funktionsaufruf in die Ausgangsqueue des Sendersystems gestellt. In regelmäßigen Abständen wird der Aufruf von hier wiederholt, bis er vom Empfängersystem verarbeitet werden kann.^[35]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Asynchrone Kommunikation

Quelle: Eigene Darstellung.

Bei der asynchronen Kommunikation muss das Empfängersystem nicht unbedingt verfügbar sein, wenn ein Funktionsaufruf vom Sendersystem abgesetzt wird. Ist das System z.B. wegen eines Upgrade längere Zeit nicht aktiv, kann es die zwischenzeitlich gesendeten Daten auch zu einem späteren Zeitpunkt verarbeiten, ohne dass die Prozesse im Sendersystem gestört werden.^[36]

Als nachteilig ist zu betrachten, dass Prozesse, die eine sofortige Rückantwort an das Sendersystem verlangen, mit dieser Methode nicht durchgeführt werden können.^[37]

Tabelle 2: Realisierungsvarianten asynchroner Kommunikation

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung.

2.5 Integrationsmodelle

Eine EAI-Lösung kann als eine prozessorientierte Integrationsplattform angesehen werden, die im Wesentlichen aus drei Ebenen besteht. Das in Abschnitt 2.5.1 dargestellte Ebenenmodell stellt eine erste grobe Einteilung der EAI-Problematik vor. Dabei ist zu berücksichtigen, dass EAI-Tool-Hersteller oftmals eine andere Einteilung wählen oder nicht alle Ebenen abdecken.^[39] Aus diesem Grund werden in den folgenden Abschnitten weitere mögliche Klassifizierungen kurz vorgestellt.

[...]

---

^[1] Vgl. Berliner Stadtreinigungsbetriebe (2005), (siehe Internetverzeichnis).

^[2] Vgl. Geschäftseinheit Informationstechnologie der BSR (2005 a), (siehe Internetverzeichnis).

^[3] Vgl. Winkeler, Thomas et al. (2001), S. 10.

^[4] Vgl. Meyer, Matthias (Hrsg.), Weingärtner, Stefan (2002), S. 212.

^[5] Vgl. BearingPoint Inc. (2005), (siehe Internetverzeichnis).

^[6] Vgl. Winkeler, Thomas et al. (2000), S. 20.

^[7] Vgl. Hofmeyer, Sibylle (2004), (siehe Internetverzeichnis).

^[8] Vgl. Kaib, Michael (2002) S. 68 f.

^[9] Vgl. Winkeler, Thomas et al. (2000), S. 12.

^[10] Vgl. Cavelti, Seraina (2004), S. 21.

^[11] Vgl. Winkeler, Thomas et al. (2000), S. 12.

^[12] Vgl. Cavelti, Seraina (2004), S. 21.

^[13] Vgl. Winkeler, Thomas et al. (2000), S. 14.

^[14] Vgl. Cavelti, Seraina (2004), S. 21.

^[15] Vgl. Kaib, Michael (2004), S. 70.

^[16] Vgl. Ebenda, S. 102 f.

^[17] Vgl. Angeli, Axel (2003), S. 27.

^[18] Vgl. Keller, Wolfgang (2002), S. 66 f.

^[19] Vgl. Schelp, Joachim, Winter, Robert (2002), S. 12.

^[20] Vgl. Keller, Wolfgang (2002), S. 67.

^[21] Vgl. Kaib, Michael (2004), S. 107.

^[22] Vgl. Kaib, Michael (2004), S. 109.

^[23] Vgl. Schelp, Joachim, Winter, Robert (2002), S. 13.

^[24] Vgl. Kaib, Michael (2004), S. 111 f.

^[25] Vgl. Keller, Wolfgang (2002), S. 68 f.

^[26] Vgl. Schelp, Joachim, Winter, Robert (2002), S. 13.

^[27] Vgl. Schneider-Neureither, Andreas et al. (2004 b), S. 480.

^[28] Vgl. Kaib, Michael (2004), S. 101.

^[29] Vgl. Ebenda S. 118 f.

^[30] Vgl. Kaib, Michael (2004), S. 119 f.

^[31] Vgl. Keller, Wolfgang (2002), S. 76.

^[32] Vgl. Meyer, Matthias (Hrsg.), Weingärtner, Stefan (2002), S. 213.

^[33] Vgl. Stumpe, Jens; Orb, Joachim (2005), S. 23.

^[34] Vgl. Keller, Wolfgang (2002), S. 80 ff.

^[35] Vgl. Meyer, Matthias (Hrsg.), Weingärtner, Stefan (2002), S. 215 f.

^[36] Vgl. Ebenda, S. 215 f.

^[37] Vgl. SAP AG (2005 a), (siehe Internetverzeichnis).

^[38] Vgl. Keller, Wolfgang (2002), S. 82 ff.

^[39] Vgl. Dangelmaier, Wilhelm et al. (2002), S. 65.