Konzeption  eines Integrationsmodells auf Basis der SAP Exchange Infrastructure  II

Inhaltsverzeichnis

Inhaltsverzeichnis   II

Abk  ürzungsverzeichnis  V

Abbildungsverzeichnis   VII

1  Einleitung und Überblick  1

1.1  Motivation  1

1.1.1  Vorstellung der Geschäftseinheit Informationstechnologie der BSR  1

1.1.2  Anwendungsportfolio der Berliner Stadtreinigungsbetriebe  1

1.1.3  Trends, die den Integrationsbedarf bei den BSR wecken  4

1.2  Zielstellung  5

1.3  Methodik  6

2  Grundlagen der Enterprise Application Integration  8

2.1  Definition und Abgrenzung der Enterprise Application Integration  8

2.2  Integrationsansätze  8

2.2.1  Punkt-zu-Punkt-Verbindung  9

2.2.2  Der Middleware-orientierte Integrationsansatz  9

2.2.3  Der ERP-basierte Integrationsansatz  10

2.3  Funktionale Bestandteile einer EAI-Lösung  10

2.3.1  Middleware  10

2.3.2  Adapter  13

2.3.3  Nachrichtenmanagement  13

2.3.4  Prozessmanagement  13

2.4  Kommunikationsmodelle  13

2.4.1  Synchrone Kommunikation  14

2.4.2  Asynchrone Kommunikation  15

2.5  Integrationsmodelle  16

2.5.1  Orientierung anhand des Ebenenmodells  16

2.5.2  Klassifizierung nach Integrationsmethoden  19

2.5.3  Klassifizierung nach EAI-Architekturen  19

2.6  Abgrenzung der EAI-Architektur von klassischer Middleware  20

Konzeption  eines Integrationsmodells auf Basis der SAP Exchange Infrastructure  III

3  Kommunikationstechnologien  21

3.1  Business Application Programming Interface (BAPI)  21

3.2  Kommunikationsdienste der SAP  22

3.2.1  Remote Function Call (RF)C  22

3.2.2  Intermediate Document (IDoc)  23

3.3  Webservices  23

4  Die SAP Exchange Infrastructure  25

4.1  Vorstellung der SAP Exchange Infrastructure  25

4.1.1  SAP NetWeaver  25

4.1.2  SAP Exchange Infrastructure  26

4.2  Komponenten der SAP Exchange Infrastructure  27

4.3  Architektur der SAP Exchange Infrastructure  29

4.3.1  Design-Zeit  29

4.3.2  Konfigurations-Zeit  29

4.3.3  Laufzeit  29

4.4  Möglichkeiten der Einbindung von Systemen  30

4.4.1  Proxy-Generierung  30

4.4.2  Adapter  31

4.5  Message-Austausch aus Anwendungssicht  31

5  Konzeption der Tankdatenintegration auf Basis der SAP XI  33

5.1  Betriebswirtschaftlicher Hintergrund  33

5.2  Ist-Stand  34

5.2.1  Grafische Darstellung der Ist-Architektur  35

5.2.2  Verbale Beschreibung der Ist-Architektur  36

5.2.3  Probleme  36

5.3  Projekt: Redesign der Tankdatenintegration  37

5.4  Fachlicher Projektkontext  37

5.4.1  Motivation für das Redesign  37

5.4.2  Phase 1: Software-Redesign  38

5.4.3  Phase 2: Redesign der technischen Architektur  38

5.4.4  Phase 3: Einführung der SAP Exchange Infrastructure  38

5.5  Redesign der technischen Architektur  39

5.5.1  Grafische Darstellung der Soll-Architektur  39

5.5.2  Verbale Beschreibung der Soll-Architektur  40

5.5.3  Spezifikation der Tank-Datei (CSV)  40

Konzeption  eines Integrationsmodells auf Basis der SAP Exchange Infrastructure  IV

5.6  Entwicklung des Integrationsmodells für die Tankdatenanbindung  41

5.6.1  Vorgehensweise  41

5.6.2  Grafische Darstellung des Integrationsmodells  42

5.6.3  Grafische Darstellung des Integrationsablaufs  43

5.6.4  Verbale Beschreibung des Integrationsablaufs  45

6  Fazit  49

6.1  Überprüfung des Integrationsmodells  49

6.2  Nutzen des Integrationsmodells  49

6.3  Darstellung des Mehrwerts durch den Einsatz der SAP XI  49

6.3.1  Technischer Mehrwert  49

6.3.2  Betriebswirtschaftlicher Mehrwert  50

6.4  Ausblick  50

6.4.1  Zukünftige Anwendungsbereiche der SAP Exchange Infrastructure  51

6.4.2  Neue organisatorische Anforderungen  51

6.4.3  Zentrales Monitoring  51

Literaturverzeichnis   VIII

Internetverzeichnis   XII

Anhang A:  Implementierung  XVI

Anhang B:  Das allgemeingültige Integrationsmodell  XXIV

Anhang C:  Die BSR-Systemlandschaft  XXV

Anhang :D  Das OSI-Referenzmodell  XXVI

Anhang E:  Glossar  XXVII

Abkürzungsverzeichnis

ABAP Advanced Business Application Programming Language

ACID ALE API Application Programming Interface

ASP AV AWision Applications for Waste-Management Integrated Solutions AZ Geschäftseinheit Zentraler Einkauf B2B Business-To-Business B2C Business-To-Consumer BAPI Business Application Programming Interfaces BSR Berliner Stadtreinigungsbetriebe

COM CRM CSV Comma Separated Values

EAI EDI

ERP FBS FTP File Transfer Protocol GE Geschäftseinheit GE VI Geschäftseinheit Informationstechnologie der BSR

GPS GUI HTML Hypertext Markup Language

HW IDoc IT Informationstechnologie

J2EE JDBC

MOM NFS ODBC Open DataBase Connectivity

ORB OSI P2P Punkt-zu-Punkt-Verbindung

PF PI

RF Geschäftseinheit Flächenreinigung RFC Remote Function Call RPC Remote Procedure Call SAP BW SAP Business Information Warehouse SAP R/3 Systeme Anwendungen und Produkte in der Datenverarbeitung (R/3 ist die Produktbezeichnung)

SAP xApps SAP XI

SCM SLD SOAP Simple Object Access Protocol

UDDI URL VF Geschäftseinheit Finanz- und Rechnungswesen

VI VKP

WDS WSDL XML Extensible Markup Language y2k Jahr 2000 ZAMIK Zentrales Anwenderorientiertes Modulares Informations- und Kommunikationssystem

Konzeption  eines Integrationsmodells auf Basis der SAP Exchange Infrastructure  

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.

¹ Vgl. Berliner Stadtreinigungsbetriebe (2005), (siehe Internetverzeichnis).

² Vgl. Geschäftseinheit Informationstechnologie der BSR (2005 a), (siehe Internetverzeichnis).

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.

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.

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. ³ 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.

³ Vgl. Winkeler, Thomas et al. (2001), S. 10.

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 Korrektheitsnachweis (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 Vorgehensweise. 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äftsprozessebene. Die Integration kann dabei sowohl innerhalb eines Unternehmens, als auch über Unternehmensgrenzen hinweg zu Geschäftspartnern und Kunden erfolgen. ⁵ 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. ⁶ 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.

⁴ Vgl. Meyer, Matthias (Hrsg.), Weingärtner, Stefan (2002), S. 212.

⁵ Vgl. BearingPoint Inc. (2005), (siehe Internetverzeichnis).

⁶ Vgl. Winkeler, Thomas et al. (2000), S. 20.

⁷ Vgl. Hofmeyer, Sibylle (2004), (siehe Internetverzeichnis).

2.2.1 Punkt-zu-Punkt-Verbindung

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

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. ¹⁰ 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. ¹² 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.

⁸ Vgl. Kaib, Michael (2002) S. 68 f.

⁹ Vgl. Winkeler, Thomas et al. (2000), S. 12.

¹⁰ Vgl. Cavelti, Seraina (2004), S. 21.

¹¹ Vgl. Winkeler, Thomas et al. (2000), S. 12.

¹² Vgl. Cavelti, Seraina (2004), S. 21.