ID 8631
Schlieper, André: Enterprise Application Integration im Neckermann Produktions-System
Hamburg: Diplomica GmbH, 2005
Zugl.: Fachhochschule Köln, Diplomarbeit, 2005
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2005
Printed in Germany
Inhaltsverzeichnis
Vorwort ... i
I. Einleitung... 1
II. Grundlagen ... 8
II.1. Betriebliche Anwendungssysteme ... 8
II.1.1. betriebswirtschaftliche Betrachtung ... 8
II.1.2. technische Betrachtung ... 10
II.2. Grundlagen der Integration ... 12
II.2.1. Integrationsmerkmale ... 13
II.2.1.1. Integrationsrichtung ... 14
II.2.1.1.1. Integrationsrichtung horizontal ... 15
II.2.1.1.2. Integrationsrichtung vertikal ... 15
II.2.1.2. Integrationsreichweite... 16
II.2.1.2.1. Integrationsreichweite intern ... 16
II.2.1.2.2. Integrationsreichweite extern ... 17
II.2.1.3. Integrationsgegenstand ... 17
II.2.1.3.1. Integrationsgegenstand Daten ... 18
II.2.1.3.2. Integrationsgegenstand Programme ... 19
II.2.1.3.3. Integrationsgegenstand Benutzerschnittstelle... 20
II.2.1.3.4. Integrationsgegenstand Prozesse ... 20
II.2.2. Integrationsansätze ... 21
II.2.2.1. Integrationsansatz Punkt-zu-Punkt... 22
II.2.2.2. Integrationsansatz ERP... 22
II.2.2.3. Integrationsansatz Middleware ... 23
II.2.3. Middleware ... 23
II.2.3.1. Datenbank-Middleware... 25
II.2.3.2. Programmorientierte Middleware ... 26
II.2.3.2.1. Verbindung versus Synchronisation ... 27
II.2.3.2.1.1. Kopplung ... 31
II.2.3.2.2. Aufruf-Schnittstellen (RPC) ... 31
II.2.3.2.3. Nachrichten-Schnittstellen (Message-Passing)... 33
II.2.3.2.4. Aufruf- versus Nachrichten-Schnittstellen ... 34
II.2.3.3. Middleware-Dienste ... 36
II.2.4. Application-Server ... 37
II.2.4.1. Mehrschichtige Architekturen ... 39
II.2.4.1.1. Zwei-Schichten-Architektur ... 40
II.2.4.1.2. Drei-Schichten-Architektur ... 41
II.2.4.1.3. Zwei-Einhalb-Schichten-Architektur ... 42
II.2.4.1.4. Vier-Schichten-Architektur... 44
II.2.4.2. Application-Server als Mehrschichtige-Architektur ... 45
II.2.4.3. Middleware im Application-Server ... 46
II.2.4.3.1. RPC-Middleware im Application-Server ... 47
II.2.4.3.2. MOM-Middleware im Application-Server ... 48
II.2.4.3.3. Vergleich RPC und MOM im Application-Server ... 49
iii
II.2.5. Service-orientierte-Architektur ... 51
II.2.5.1. Kopplung einer SOA ... 52
II.2.5.2. Services einer SOA ... 53
II.2.5.3. Prinzipien einer SOA ... 53
II.2.6. WebServices... 54
II.2.6.1. Nutzung offener Standards... 54
II.2.6.2. Techniken der WebServices ... 55
II.2.6.3. Kopplung von WebServices... 56
II.2.6.4. WebServices versus RPC/MOM ... 57
II.2.6.5. SOAP... 58
II.2.6.6. Integrationslösung mit Hilfe von WebServices ... 58
II.2.7. Enterprise Service Bus ... 59
III. Ist-Analyse ... 62
III.1. Kernaufgaben des NPS ... 62
III.2. Anforderungen an das neue NPS ... 66
III.2.1. Gründe für die Neuimplementierung ... 67
III.2.2. Funktionale Anforderungen an das neue NPS laut Lastenheft... 68
III.3. Gegenwärtiger Entwicklungsstand ... 69
III.3.1. Anwendungen und deren Aufgaben ... 69
III.3.2. Systemstruktur... 71
III.3.2.1. Hardware-Topologie ... 71
III.3.2.2. Drei-Ebenen-Modell... 72
III.3.2.2.1. Benutzerschnittstellen-Ebene... 73
III.3.2.2.2. Programm-Ebene ... 74
III.3.2.2.3. Daten-Ebene ... 75
III.3.2.2.3.1. Helios ... 75
III.3.2.2.3.2. Cumulus ... 77
III.3.2.2.3.3. mysql... 79
III.3.2.3. Schichten-Architektur ... 80
III.4. Analyse der Integrationsfähigkeit ... 81
III.4.1. Integrationsgegenstand Benutzerschnittstelle ... 81
III.4.2. Integrationsgegenstand Programme ... 82
III.4.3. Integrationsgegenstand Daten... 83
III.5. Ergebnis der Analyse... 85
IV. Soll-Konzept... 87
IV.1. Erweiterung des NPS um einen ESB... 87
IV.2. Anschluss des NPS an einen ESB ... 88
IV.2.1. erste Stufe - NPS als Gesamtsystem an den ESB anschließen. 88
IV.2.2. zweite Stufe - Anschluss der Teilsysteme des NPS an den ESB 90
IV.3. Aufbau des ESB und Integration mit dem NPS... 91
IV.3.1. Aufbau des ESB ... 92
IV.3.2. Aufbau der um den ESB erweiterten Infrastruktur ... 94
IV.4. Ergebnis des Konzeptes ... 96
iv
V. Implementierung... 97
V.1. Aufbau des Anwendungsszenarios... 97
V.1.1. Receiver... 98
V.1.2. Sender ... 99
V.1.3. ESB... 101
V.2. Aufbau des ESB im Anwendungsszenario... 102
V.2.1. SOAP-Implementierung AXIS... 104
V.2.2. Implementierung von Bus und Router ... 105
VI. Zusammenfassung und Ausblick... 109
Literaturverzeichnis ... 111
Glossar und Abkürzungsverzeichnis... 115
Stichwortverzeichnis ... 119
A. Programmcode des Anwendungsszenarios für einen ESB ... 121
B. Eidesstattliche Erklärung ... 143
v
Tabellenverzeichnis
II-1. RPC-Middleware ... 32
III-1. NPS Anwendungen und deren Aufgaben ... 69
Abbildungsverzeichnis
I-1. Kommunikationsdrehscheibe ... 2
II-1. Anwendungssysteme in der Unternehmensorganisation ... 9
II-2. Anwendungsarchitektur in drei Ebenen ... 10
II-3. Integrationsmerkmale ... 13
II-4. Integrationsrichtungen ... 14
II-5. Integrationsreichweiten ... 16
II-6. Integrationsgegenstände ... 18
II-7. Middleware als Zwischenschicht... 24
II-8. Middleware im ISO/OSI-Referenzmodell ... 24
II-9. Datenbank-Middleware ... 26
II-10. Programmorientierte Middleware... 27
II-11. Verbindung versus Synchronisation... 29
II-12. Zwei-Schichten-Architektur ... 40
II-13. Drei-Schichten-Architektur ... 41
II-14. Zwei-Einhalb-Schichten-Architektur... 42
II-15. Vier-Schichten-Architektur ... 45
II-16. Schichten-Architektur des Application-Server... 46
II-17. RPC Middleware im Application-Server ... 47
II-18. MOM Middleware im Application-Server... 48
II-19. Integration mit RPC und MOM-Middleware ... 49
II-20. Enterprise Service Bus ... 59
III-1. Funktionales Verhalten des NPS-Gesamtsystems ... 65
III-2. Funktionales Verhalten der NPS-Teilsysteme ... 70
III-3. Hardwaretopologie... 71
III-4. serverbasiertes OPI ... 76
III-5. Speicherung eines Cumulus-Asset... 78
III-6. Helios Companion... 79
III-7. Zwei-Einhalb-Schichten-Architektur des NPS... 80
IV-1. SOA mit Hilfe eines ESB als Kummunikationsdrehscheibe ... 87
IV-2. Anbindung des NPS als Gesamtsystem an den ESB... 89
IV-3. Anbindung der Teilsysteme des NPS an den ESB ... 90
IV-4. Topologie des ESB für die Integration im NPS ... 93
IV-5. Integration der ESB-Topologie mit der NPS-Topologie ... 95
V-1. Anwendungsszenario ... 97
V-2. Anwendungsszenario (formelle Darstellung) ... 98
V-3. Ergebnis des Anwendungsszenario ... 102
V-4. ESB Komponenten Bus und Router ... 103
V-5. SOAP-Implementierung AXIS... 105
vi
V-6. Verkettung von AXIS-Engines für die SOAP-Verarbeitung im ESB ... 106
V-7. Der Enterprise Service Bus des Anwendungsszenarios ... 108
Beispiele
A-1. HelloServiceClient.java im 'Sender'... 121
A-2. parameter.xml im 'Sender'... 123
A-3. RedirectHandler.java im 'Bus'... 123
A-4. GlobalLogHandler.java im 'Bus'... 125
A-5. BusProvider.java im 'Bus' ... 126
A-6. WSDDBusProvider.java im 'Bus' ... 128
A-7. org.apache.axis.deployment.wsdd.Provider im 'Bus' ... 128
A-8. server.deploy.wsdd im 'Bus'... 128
A-9. server.undeploy.wsdd im 'Bus'... 129
A-10. BusSender.java im 'Bus' ... 129
A-11. BusTransport.java im 'Bus' ... 132
A-12. client.deploy.wsdd im 'Bus' ... 132
A-13. JMSListenerBean.java im 'Router'... 133
A-14. RedirectHandler.java im 'Router' ... 136
A-15. GlobalLogHandler.java im 'Router' ... 137
A-16. RouterProvider.java im 'Router' ... 138
A-17. WSDDRouterProvider.java im 'Router' ... 139
A-18. org.apache.axis.deployment.wsdd.Provider im 'Router'... 140
A-19. server.deploy.wsdd im 'Router' ... 140
A-20. HelloService.java im 'Receiver' ... 141
A-21. server.deploy.wsdd im 'Receiver'... 141
A-22. server.undeploy.wsdd im 'Receiver'... 141
vii
Vorwort
Die vorliegende Diplomarbeit baut auf einem Projekt auf, daß ich als freier
Mitarbeiter neben meinem Studium mitgestalten konnte. Ziel des Projektes war
die Schaffung eines Systems zur Unterstützung der Produktion von
Versandkatalogen.
Das Thema dieser Diplomarbeit ist die Erweiterung des aus dem Projekt
hervorgegangenen Systems NPS um die Möglichkeiten und Techniken der
'Enterprise Application Integration' EAI. Mit dem Ziel eine umfassende strukturelle
Basis für eine Integrationsplattform zu erstellen, um damit eine zukunftsweisende
technologische Richtung im Sinne einer standardisierten Integrationsfähigkeit zu
bieten.
Erstellt wurde das System für die Neckermann Versand AG. Daher leitet sich
auch der Name 'NPS' des entstehenden Produkts ab; NPS steht für das
'Neckermann Produktions-System'. Verantwortlich für die Entwicklung des NPS
und damit gleichzeitig mein Diplom- und Arbeitsplatzgeber, ist die Firma Vitras
GmbH (ehemals Mockenhaupt IT-Consulting), bei der ich mich sehr bedanken
möchte, da durch sie diese Diplomarbeit erst möglich gemacht wurde. Die Vitras
GmbH ist als Beratungs- und Softwareentwicklungsunternehmen für die
Neckermann Versand AG im Unternehmensbereich Werbung tätig, und hier eben
mit der Aufgabe der Entwicklung des NPS betraut.
Großer Dank gilt auch meinem Mentor, Prof. Dr. Dipl.-Inform. Frank K. Victor, für
die Unterstützung in allen Fragen der Diplomarbeit und vor allem dafür, dass er
sich trotz meiner großen Entfernung von der Hochschule, bereiterklärt hat mich zu
betreuen.
André Schlieper
i
Kapitel I. Einleitung
Die Basis der vorliegenden Diplomarbeit bildet das zu entwickelnde System NPS
- das Neckermann Produktions-System. Wie schon dessen Vorgängermodell
auch, sollte das zu entwerfende Produkt die Speicherung und Verwaltung aller
relevanten Daten der Katalogproduktion ermöglichen. Dies sind hauptsächlich die
operativen Daten der Katalogseiten, wie z.B. Bildmaterial und Produkttexte.
Zusätzlich zu der schon vorhandenen Funktionalität, also der Speicherung und
Verwaltung, versprach man sich mit dem neuen System eine darüber
hinausgehende durchgängige Unterstützung ganzer Katalogerstellungsprozesse,
basierend auf den erfassten Datenbeständen.
In einem Katalogerstellungsprozess lassen sich Arbeitsschritte zusammenfassen,
die in einem logischen Zusammenhang stehen bei der zielgerichteten
Bearbeitung eines Geschäftsfalles. Der Geschäftsfall stammt hierbei aus dem
Umfeld der Katalogproduktion.
Die reine Datenspeicherung von Produktphotographien, Texten etc. ist gemessen
am Gesamterstellungsprozess ein relativ kleiner Teil und für sich genommen kein
ganzer Prozess in der Katalogerstellung. Für eine ganzheitliche Betrachtung als
Katalogerstellungsprozess fehlt eine zielgerichtete Bearbeitung der Daten im
Sinne eines Geschäftsfalles. Auf den gespeicherten Daten operieren jedoch eine
Menge verschiedener Anwendungen um ein bestimmtes Ziel, nämlich die
Bearbeitung eines Geschäftsfalles, zu erreichen. Erst die über diese
Anwendungen verrichteten Tätigkeiten auf den Daten kann man in einem
Zusammenhang als Katalogerstellungsprozess ansehen. Die Prozesse werden in
Anlehnung an den meist betriebswirtschaftlichen Charakter auch als
Geschäftsprozesse bezeichnet.
Die Anwendungen die den Geschäftsprozessen zu Grunde liegen, sind häufig
schon vorhanden und sollen in Zukunft auch weiter benutzt werden. Da die
bestehenden Anwendungen meist nicht dafür ausgelegt und entwickelt wurden
mit anderen Systemen Daten auszutauschen, ist eine direkte Kommunikation
nicht möglich. Um eine Kooperation unterschiedlicher Anwendungen
untereinander zu gewährleisten, ist es notwendig sie zusammenzuführen bzw. sie
zu integrieren. Erreicht wird diese Integration der beteiligten Anwendungen durch
die Bereitstellung von Kommunikationskanälen über Schnittstellen. D.h. daß die
an einem Prozess beteiligten Anwendungen über Schnittstellen untereinander in
Verbindung treten können.
Das zu entwickelnde System soll zur Bereitstellung von Diensten ebenfalls
diverse bestehende Systeme und Datenbestände integrieren. Diese Systeme sind
spezialisiert auf bestimmten Gebieten wie z.B. der Massendatenverarbeitung oder
der Bildverarbeitung. Außerdem beinhalten einige die eigentliche Geschäftslogik
des Gesamtsystems. Entstanden ist diese Art der verteilten Logik durch eine
'best-of-bread'-Strategie, bei der durch Kombination verschiedener Systeme
versucht wird, die Anforderungen an das Gesamtsystem optimal abzudecken.
1
Kapitel I. Einleitung
Hierdurch entstehen zunehmend komplexe heterogene Systemlandschaften und
damit einhergehend eine komplexer werdende Schnittstellenlandschaft, welche
die Kommunikation der Systeme untereinander erschwert.
Bei der Bereitstellung von Schnittstellen, ist es nicht wünschenswert, daß jedes
System mit jedem anderen seine eigenen Kommunikationsverbindungen aufbaut.
Dies führt zu einem Schnittstellen-Chaos, da für die Verbindungen von jedem
System zu jedem anderen System jeweils eigene Schnittstellen bereitgestellt
werden müssten. Potenziell führt dies zu einer Ordnung von O(n
2
) Verbindungen
(vgl. [001] Seite 23), was in der Folge zu sehr hohen Kosten bei der Entwicklung
und Wartung führt (vgl. [003] Seite 2). Schnittstellenwartung verschlingt vielfach
bis zu 60% des gesamten IT-Budgets (vgl. [100] Seite 98). Um jedoch trotzdem
die Kommunikation der verschiedenen Dienste zu erreichen und Synergien beim
Zusammenwachsen verschiedener Systeme zu nutzen, gilt es die Systeme über
eine Art 'Kommunikationsdrehscheibe' (vgl. [004] Seite 21) miteinander zu
verbinden. Eine Drehscheibe für den gemeinsamen Datenaustausch, welche
gewährleistet, daß alle Systeme mit allen anderen kommunizieren können. Jedes
System soll hierbei nur eine einzige Schnittstelle, nämlich die zur Drehscheibe
benötigen und über diese mit allen anderen Systemen
Kommunikationsverbindungen aufbauen können.
Abbildung I-1. Kommunikationsdrehscheibe
2
Kapitel I. Einleitung
Trotz der digitalen Speicherung sind die heutigen betrieblichen Prozesse oft stark
geprägt durch manuelle Eingriffe. Häufig müssen die Daten aus den
speichernden Systemen heraus dem bearbeitenden System zugeführt werden.
Hierfür ist meistens das manuelle Eingreifen notwendig, wodurch jedoch der
durchgängige Informationsfluss unterbrochen wird. Bei den auftretenden
Prozessen, wie z.B. der Bearbeitung von Bild- und Textmaterial durch diverse
Instanzen eines Workflows oder der Bearbeitung ganzer Katalogseiten, von der
ersten Zusammenstellung eines Layouts mit Produktbildern und Texten bis zur
produktiven druckreifen Fassung und Freigabe, sollten soweit wie möglich
manuelle Eingriffe verhindert werden. Manuelles Eingreifen in einem Prozess hat
drei wesentliche Nachteile. Erstens wird die Bearbeitungszeit des
Gesamtprozesses erhöht, zweitens sind manuelle Eingriffe fehleranfälliger und
drittens wird eine Automatisierung und Rationalisierung des gesamten Prozesses
verhindert. Insgesamt gesehen ist das manuelle Eingreifen in den
Geschäftsprozessen sehr kostenintensiv. Der optimale Fall, in dem die
Geschäftsprozesse automatisiert untereinander kommunizieren können, führt zu
durchgängig unterstützen Prozessen dem Straight Through Processing kurz STP.
Geschäftsprozesse finden sowohl intern, also im Unternehmen selber, als auch
extern, also in Unternehmen zu denen man in einer geschäftlichen Beziehung
steht, statt. Externe Dienstleister im Umfeld der Katalogproduktion sind
hauptsächlich Unternehmen im Bereich der Fotoproduktion, Texterstellung und
Bildbearbeitung. Gerade im Bereich der heutigen digitalen Bildverarbeitung fallen
dort sehr schnell große Datenmengen an. Damit verbunden sind natürlich auch
hohe Datentransfervolumina, welche im Bereich bildverarbeitender Systeme zu
besonderen Anforderungen führen und besondere Lösungen bei der Integration
bildverarbeitender Systeme erfordern.
Anwendungs- und unternehmensübergreifende Geschäftsprozesse durchgängig
zu ermöglichen ist eine Kernaufgabe des Systems.
Diese erforderlichen Integrationsanforderungen zur Unterstützung
anwendungsübergreifender sowie unternehmensübergreifender Kommunikation
und die Integration von Geschäftsprozessen führt uns in diesem Projekt zu dem
Thema Enterprise Application Integration (EAI), also der Integration von
Unternehmensanwendungen zur Unterstützung von Geschäftsprozessen, sowie
seinen Mitteln und Methoden, mit deren Hilfe die gestellten Anforderungen gelöst
werden sollen.
Inhaltlich befasst sich die vorliegende Diplomarbeit mit der Erweiterung des
Systems NPS um EAI. Es wird eine Analyse von Integrationsmöglichkeiten
durchgeführt und ein Konzept zur Umsetzung einer EAI-Lösung im NPS gegeben.
Da das System von Anfang an eine sehr praktische Ausrichtung und
zielgerichtete Entwicklung war, blieb wenig Raum für theoretische Analysen in
Bezug auf mögliche Integrationstechniken. Eine zukunftsweisende technologische
Richtung im Sinne einer standardisierten Integrationsfähigkeit sowie die
umfassende strukturelle Basis für eine Integrationsplattform fehlt. Diese soll
3
Kapitel I. Einleitung
jedoch durch die vorliegende Arbeit analysiert und durch einen Prototyp
implementiert werden. Durch den Ausbau des System mit geeigneten Mitteln aus
dem Umfeld von EAI sollen im wesentlichen Vorteile erzielt werden, die das
System zukunftssicher machen sollen. Es soll als solide Grundlage für
kommende Entwicklungsprojekte und neue Herausforderungen dienen und
dadurch die getätigten Investitionen in die Entwicklung schützen.
Zum Einsatz kommt das zu entwickelnde System bei Europas größtem
Warenhaus- und Versandhandelskonzern der KarstadtQuelle AG,
bzw. dessen Tochter der Neckermann Versand AG.
In Zeiten der Globalisierung mit häufigen Fusionen, ist nicht überraschend, dass
es sich bei diesem international tätigen Unternehmen um einen Konzern
bestehend aus mehreren fusionierten Konzernunternehmen handelt. Die Zentrale
dieses Konzerns ist die KarstadtQuelle.
Die einzelnen Geschäftsfelder wie Immobilien, Dienstleistungen, stationärer
Einzelhandel und der Versandhandel werden durch die verschiedenen
Konzernunternehmen abgedeckt. Durch das Geschäftsfeld Versandhandel wird
mit über 50% Umsatzanteil der größte Umsatz generiert, und zwar überwiegend
(80% vom Versandhandelsumsatz) durch die Konzernunternehmen Quelle AG
und Neckermann Versand AG. Der Handel des immerhin drittgrössten
Versandhauses Europas der Neckermann Versand AG erfolgt hierbei
hauptsächlich (85% Umsatzanteil)
1
über die Kataloge. Hierdurch wird ein
reibungslos funktionierendes Katalogerstellungssystem zu einem sehr wichtigen
Faktor (vgl. [103,102]). Den essentiellen Charakter unterstreicht die Tatsache,
dass durch das zu erstellende Systeme eine Menge weiterer externer Firmen und
Mitarbeiter wie z.B. Photographen und Texter, welche an den
Katalogerstellungsprozessen mitwirken, eingebunden werden.
Das Thema Integration und im besonderen die Integration betrieblicher
Anwendungssoftware ist schon seit geraumer Zeit zu einem zentralen
Entwicklungsgegenstand in der Softwareindustrie geworden.
Integration bezeichnet allgemein die 'Wiederherstellung eines Ganzen' bzw. die
'Wiederherstellung einer Einheit' (vgl. [303]) durch das Verbinden logisch
zusammengehörender Teile (vgl. [003] Seite 10). Die Grundmotivation zur
Integration liegt wohl in der unbestimmten Hoffnung, dass der Nutzen des Ganzen
höher sei als die Summe der Nutzen seiner Teile (philosophisches Prinzip des
Holismus). Das 'Ganze' kann sich im Rahmen von Anwendungssystemen auf
verschiedene Ebenen beziehen. Angefangen bei der Ebene der Daten, über die
Ebene der Anwendungen und Kommunikationsprotokolle bis hin zur Ebene der
Geschäftsprozesse. Eine Integration auf Daten-Ebene bedeutet noch keine
4
Kapitel I. Einleitung
Unterstützung der auf den Daten operierenden Anwendungen, genauso wie die
Anwendungsintegration noch nicht zwangsläufig die Bereitstellung und
Unterstützung von Geschäftsprozessen bedeutet. Erst die Geschäftsprozesse
bilden eine sinnvolle betriebswirtschaftliche Einheit. Ihre Integration und eine
durchgängige Unterstützung sind das eigentliche Ziel bei der Integration von
Unternehmensanwendungen. Als Voraussetzung der
Geschäftsprozessintegration bilden die Daten- und Anwendungsintegration
jedoch die wesentlichen Grundbausteine und sind Voraussetzung für die
Geschäftsprozessintegration.
Die letztlichen Ziele dieser Integrationsbestrebungen liegen zum einen darin die
Geschäftsprozesse zu automatisieren und zu rationalisieren. Durch die
Automatisierung wird versucht, manuelle Eingriffe in die Prozesse so weit wie
möglich zu reduzieren und durch einen automatischen Fluss von Information in
einem Geschäftsprozess (automatisierter Workflow, STP) abzulösen. Durch die
Rationalisierung wird versucht die bestehenden Prozesse zu optimieren. Mit
weniger manuellen Eingriffen und der Verbesserung der Prozesse sollen Kosten-,
Zeit- und Qualitätseffekte erreicht werden. Zum anderen gibt es
Integrationsbestrebungen deren Ziele darin liegen, die Geschäftsprozesse zu
reorganisieren und neuzugestalten. Die Effekte die sich hier ergeben liegen mehr
im Bereich der Verbesserung der Kundenbeziehungen und der
Kooperationsformen zwischen Unternehmen, letztenendes um die
Wettbewerbsfähigkeit zu stärken und zu fördern (vgl. [003] Seite 25ff). In der IT
spielt die Integration schon seit den Anfängen der Datenverarbeitung eine
wichtige Rolle. Durch die Standardisierungsbestrebungen betrieblicher
Anwendungssoftware wurde schon früh versucht, betriebliche Prozesse zu
identifizieren und durch standardisierte Softwaremodule abzubilden. Ziel war es,
die nachträgliche Integration von Software und den damit verbundenen Aufwand
durch vorintegrierte Module abzulösen. Dank einheitlicher Systemstrukturen und
Schnittstellen innerhalb von Standardsoftwaresystemen (ERP) wurde es möglich
ganze Geschäftsprozesse durchgängig in individuell 'zusammensteckbaren'
Softwaremodulen abzubilden. Hierdurch wurde eine durchgängige systeminterne
Kommunikation gewährleistet, ohne teure Individualentwicklungen oder
Integrationsaufwand betreiben zu müssen. Entstanden sind die heute weit
verbreiteten und in den meisten großen Unternehmen zu findenden
Standardsoftware-Produkte wie z.B. SAP R/3.
Gelöst haben diese Standardsoftwaresysteme jedoch lediglich einen Teil des
Integrationsproblems. Hauptsächlich die unternehmensinterne Unterstützung von
Geschäftsprozessen.
Problematisch geblieben ist die innerbetriebliche Integration von Software die
nicht zum Paket der Standardsoftware gehört oder auch die innerbetriebliche
Integration von Individualsoftware. Im Sinne einer 'best-of-bread'-Strategie ist es
notwendig geblieben Schnittstellen zu entwickeln.
Außerdem wurde die externe Integration, die Kommunikation der Anwendungen
5
Kapitel I. Einleitung
und Prozesse zwischen den Unternehmen, durch die Einführung von
Standardsoftware nicht wesentlich verbessert bzw. kann den heutigen
Anforderungen nicht mehr gerecht werden.
Schon zu einem frühen Zeitpunkt hat man erkannt, dass die Vorteile einer
innerbetrieblichen Integration sich auch auf die zwischenbetriebliche Ebene
übertragen lassen. Da Unternehmen immer auch in Verbindung und damit
Kommunikation mit anderen Unternehmen stehen, tauschen sie auch Daten und
damit betriebliche Informationen mit diesen aus. Dieser Datenaustausch bildet die
Grundlage von Geschäftsprozessen, welche ebenfalls integriert und damit
rationalisiert und automatisiert werden können. Zum damaligen Zeitpunkt fand
das Bestreben nach zwischenbetrieblicher Integration hauptsächlich durch EDI
Unterstützung. EDI ist ein standardisiertes Datenformat für den Austausch von
Geschäftsinformationen über Computer-Netze. Es ist ein bis heute weit
verbreiteter Standard, welcher jedoch sehr unflexibel ist und den heutigen
Anforderungen durch eBusiness, Internet und Globalisierung in Bezug auf die
Integration von Geschäftsprozessen nur bedingt gerecht werden kann.
Unternehmensübergreifende Kommunikation und die damit verbundene
Integration zwischenbetrieblicher Prozesse war durch die inhomogene
Systemlandschaft und die komplexen Schnittstellen zwischen den Systemen
hauptsächlichen den 'Großen' vorbehalten und wurde somit zumeist nur in
Standardsoftware eingesetzt.
Durch die Entwicklung in den letzten Jahren, gerade im Bereich des eBusiness
getrieben durch das Internet, die Globalisierung (vgl. [004] Seite 12) zusammen
mit gestiegenen Anforderungen an immer kürzer werdende Produktzyklen und
sich schneller wandelnde Geschäftsprozesse, sind auch die Anforderungen an
die Integration von Software insgesamt stark gestiegen.
Um dieser Entwicklung gerecht zu werden, wurden EAI-Konzepte entwickelt.
Auch EAI an sich ist nicht neu. Schon mit der Entwicklung von Konzepten wie
Middleware wurde versucht den Integrationsproblemen entgegenzutreten. Jedoch
löst Middleware das Problem nur bis zu einer bestimmten Ebene, die nicht die
Geschäftsprozesse an sich berührt. Lediglich die technische Basis als
Grundgerüst der Kommunikation wird durch Middleware bereitgestellt, nicht
jedoch die auf der Kommunikation aufbauenden geschäftlichen Vorfälle, die
Geschäftsprozesse. Dieser Ansatz ist das eigentlich neue an EAI, die Integration
und durchgängige Unterstützung ganzer Geschäftsprozesse.
EAI konnte sich relativ unbemerkt von einem Hype in Ruhe entwickeln und zeigt
seine Leistungsfähigkeit in einer Vielzahl von Projekten, die in letzter Zeit fertig
gestellt wurden (vgl. [201] Seite 1). In Deutschland setzen rund zwei Drittel der
Unternehmen auf EAI-Lösungen (vgl. [400]), und es fließen rund 35% des
Budgets für neue IT-Projekte in die Integration (vgl. [100]).
Auch im Projekt NPS, dem Produktionssystem der Neckermann Versand AG,
sollen die Vorteile einer integrierten Gesamtlösung zum tragen kommen.
6
Kapitel I. Einleitung
Fußnoten
1. Umsatzanteile beziehen sich auf das Jahr 2003
7
Kapitel II. Grundlagen
Der Begriff Enterprise Application Integration (EAI) steht für die Integration von
Unternehmensanwendungen bzw. die Integration betrieblicher
Anwendungssysteme. In dieser Bezeichnung sind alle drei Begriffe enthalten, die
in einer heutigen IT-Landschaft wichtig sind: Unternehmensweit, Anwendungen
und Integration (vgl. [204], [004] Seite 11). Eine einheitliche Definition des
Begriffes EAI zu geben ist schwierig, da er nicht präzise definiert ist. EAI ist eine
Softwarelösung, bei der es darum geht, diverse Anwendungen eines
Unternehmen die nicht für eine direkte Zusammenarbeit ausgelegt sind, zu
verbinden. Diese indirekte Verbindung über die Softwarelösung soll es
ermöglichen, dass die Anwendungen untereinander kommunizieren können, um
Geschäftsprozesse zu unterstützen. Es geht also darum, heterogene
Anwendungen eines Unternehmens so zu integrieren, dass sie sich möglichst so
verhalten, als wären sie von Anfang an dafür entworfen, die aktuellen
Geschäftsprozesse eines Unternehmens zu unterstützen (vgl. [001] Seite 5).
Von zunehmender Bedeutung ist es, dass die zu unterstützenden Prozesse eines
Unternehmens nicht nur auf die internen beschränkt bleiben. Durch die
Globalisierung und die zunehmende Vernetzung ist es wichtig, dass auch
Prozesse zwischen Unternehmen direkt unterstützt werden.
II.1. Betriebliche Anwendungssysteme
Betriebliche Anwendungssysteme (BAS) sind Anwendungen mit deren Hilfe
betriebliche Aufgaben computergestützt abgewickelt werden können. Diese
informationsverarbeitenden Aufgaben dienen hauptsächlich der Lenkung sowie
der Automatisierung betrieblicher Prozesse (vgl. [003] Seite 11).
II.1.1. betriebswirtschaftliche Betrachtung
Anwendungssysteme lassen sich, basierend auf Mertens' Klassifikationsmodell,
nach der Art der zu unterstützenden betriebswirtschaftlichen Aufgaben in vier
vertikale Ebenen aufteilen (vgl. Abbildung II-1). Beginnend bei
Anwendungssystemen der unteren Ebene sind dies die Administrations-,
Dispositions-, Planungs- und Kontrollsysteme.
Von der unteren mengenorientierten operativen Ebene werden die Informationen
auf dem Weg zu den oberen entscheidungsorientierten strategischen Ebenen
verdichtet. D.h. es werden Informationen für die jeweils höheren Ebenen
zusammengefasst und aufbereitet.
Administrationssysteme werden eingesetzt in der klassischen Verarbeitung von
Massendaten, bei denen ein hoher Grad an Automatisierung und Rationalisierung
der Aufgaben erreicht werden kann. Beispielhafte Aufgaben dieser Systeme sind
die monatlichen Lohn- und Gehaltsabrechnungen.
8
Kapitel II. Grundlagen
Dispositionssysteme gehen über die reine Administration hinaus und sollen
zudem menschliche Entscheidungen unterstützen. Ziel dieser Systeme ist die
Rationalisierung der Entscheidungsfindung sowie deren qualitative Verbesserung.
Beispielhaft hierfür ist die Materialreservierung oder Betriebsmittelzuordnung für
eingegangene Aufträge.
Die Planungs- und Kontrollsysteme beziehen ihre Informationen aus den
Administrations- und Dispositionssystemen. Die bezogenen Daten werden
verdichtet, aufbereitet und ausgewertet. Mit Hilfe dieser Systeme werden die
Entscheidungsträger im Unternehmen bei der Unternehmensplanung und
-kontrolle unterstützt. Beispielhafte Aufgabe ist hier die Erstellung von Berichten
über den laufenden Geschäftsbetrieb.
Ergänzt werden die Systeme dieser vier Ebenen durch die Querschnittssysteme,
welche in erster Linie der Automatisierung der Bürotätigkeit dienen und auch die
Bürokommunikation unterstützen sollen. Beispielhafte Anwendungen hierfür sind
Groupware-, Workflow-, Multimedia-, Dokumentenmanagement- und
Präsentationssysteme.
Außer der vertikalen Systematisierung kann man Anwendungssysteme horizontal
kategorisieren. Dies erfolgt nach der Position des Anwendungssystems in der
betrieblichen Wertschöpfungskette. Das Anwendungssystem und seine Aufgabe
wird als Teil dieser Kette betrachtet. Je nach Anwendungsfall und Branche in der
das System zum Einsatz kommt, sind hier unterschiedliche betriebliche Bereiche
von Bedeutung wie z.B. Beschaffung, Produktion, Vertrieb oder auch
Personalwesen etc. (vgl. [003] Seite 18).
9
Kapitel II. Grundlagen
Abbildung II-1. Anwendungssysteme in der Unternehmensorganisation
(vgl. [005] Seite 4)
II.1.2. technische Betrachtung
Die technische Seite von Anwendungssystemen lässt sich in drei logisch
voneinander getrennte Ebenen aufteilen (vgl. Abbildung II-2).
1. Daten-Ebene
2. Programm-Ebene
3. Benutzerschnittstellen-Ebene
10
Kapitel II. Grundlagen
Abbildung II-2. Anwendungsarchitektur in drei Ebenen
Die Daten-Ebene stellt ein Medium zur Verfügung, welches die Daten eines
Anwendungssystems speichern kann. Hier kommen meist Datenbanksysteme
zum Einsatz, welche die Möglichkeit bieten mittels standardisierter
Abfragesprachen (SQL) auf die Inhalte zuzugreifen. Als
Schnittstellen-Technologien kommen häufig standardisierte Technologien wie
ODBC oder JDBC zum Einsatz oder aber proprietäre Schnittstellen-Technologien,
welche dann an das Datenbanksystem gebunden sind.
Auf der Daten-Ebene aufbauend folgt die Programm-Ebene
1
. Sie kommuniziert
mit der Daten-Ebene, um gespeicherte Daten zu erhalten und zu verarbeiten. In
dieser Ebene wird die Logik eines Anwendungssystems implementiert. Diese
Logik wird mittels Software in Programm-Code umgesetzt. Diese Logik wird auch
als die Geschäftslogik bezeichnet. Die Geschäftslogik besagt, was mit den Daten
des Anwendungssystems gemacht werden soll und führt die eigentliche
Datenverarbeitung durch. Die Informationen können weiterverarbeitet, an andere
Systeme oder Benutzer verschickt, gespeichert oder zur Steuerung weiterer
Systeme benutzt werden. Die Geschäftslogik eines Anwendungssystems stellt
11
Kapitel II. Grundlagen
einen wesentlicher Teil des Geschäftsprozesses dar. Die Programm-Ebene bildet
also mit der enthaltenen Geschäftslogik ganz oder teilweise Geschäftsprozesse
ab. Die Programm-Ebene besitzt Schnittstellen über welche die Daten in das
Anwendungssystem hinein- und herausfließen können. Diese Schnittstellen
enden über die Benutzerschnittstellen-Ebene beim Benutzer oder anderen
Anwendungssystemen.
Als oberste Ebene eines Anwendungssystems folgt die
Benutzerschnittstellen-Ebene
2
. Diese Ebene dient der Kommunikation eines
Benutzers mit dem System. Über sie kommuniziert ein Benutzer mit der
Geschäftslogik um Geschäftsprozesse anzustoßen oder nicht vollständig in den
Anwendungssystemen integrierte Prozesse weiterzuverarbeiten bzw.
abzuschließen. D.h. die Geschäftsprozesse werden entweder direkt vom
Anwendungssystem, von Anfang bis Ende abgearbeitet, oder bedürfen der
Kommunikation mit weiteren Anwendungssystemen die den Prozess
weiterbearbeiten und ggf. abschließen können.
Die Geschäftsprozesse befinden sich, falls sie durch das Anwendungssystem
vollständig abgebildet werden können, nur in der Geschäftslogik der
Programm-Ebene. Die Prozesse müssen dann lediglich (manuell oder
automatisiert) angestoßen werden und das System kann sie abarbeiten. Dieser
Fall ist jedoch eher selten gegeben. Meist benötigt ein Anwendungssystem zur
Abarbeitung eines Geschäftsprozesses weitere Systeme, welche ebenfalls Teile
des Geschäftsprozesses übernehmen müssen. In diesem Fall verteilen sich die
Prozesse auf verschiedene Anwendungssysteme und deren Programm-Ebenen
mit darin enthaltener Geschäftslogik.
Der Benutzer in obiger Graphik (vgl. Abbildung II-2) stellt zum einen den
manuellen Eingriff eines Benutzers in den Geschäftsprozess dar. Zum anderen
wird durch ihn ein anderes Anwendungssystem dargestellt, welches ebenfalls am
Geschäftsprozess beteiligt ist. Der Benutzer bzw. das Anwendungssystem stößt
Prozesse an oder verbindet die an einem Prozess beteiligten Systeme. Der
Benutzer kann auch Teile von Prozessen selber an den beteiligten
Anwendungssystemen manuell durchführen.
II.2. Grundlagen der Integration
Die Integration ist die eigentliche Herausforderung der EAI. Die betrieblichen
Anwendungssysteme sind die gegebenen Voraussetzungen oder auch die
Bedingungen unter denen eine Integration stattfinden muss. Oft werden die
vorhandenen Anwendungen auch als Anwendungsinseln bezeichnet (vgl. [004]
Seite 11). Dies deutet darauf hin, dass die Anwendungen ohne Verbindung zu
anderen Anwendungen existieren und völlig autark ihre Arbeit verrichten. In
dieser Metapher kann man die Anwendungen als Inseln und die Integration als
die Brücken zwischen diesen Inseln bezeichnen. Über die Brücken werden
12
Kapitel II. Grundlagen
Verbindungen und damit Kommunikationsmöglichkeiten zwischen den Inseln bzw.
den Anwendungen möglich. Um EAI als neuen Ansatz einer umfassenden
Integration heterogener betrieblicher Anwendungen zu verstehen, ist ein
Verständnis der Grundlagen der Anwendungsintegration notwendig.
II.2.1. Integrationsmerkmale
Um den Zustand eines Anwendungssystems bezüglich seiner Integration
beschreiben zu können, dienen bestimmte Integrationsmerkmale (vgl. Abbildung
II-3). Sie charakterisieren den Integrationszustand eines Anwendungssystems. In
der Literatur finden sich zahlreiche Ansätze zur Beschreibung von
Integrationsmerkmalen, die Grundlage für folgende umfassende und
vergleichende Darstellung gibt Linß (vgl. [006] Seite 7-17). Er stellt die
Dimensionen
1. Integrationsrichtung
2. Integrationsreichweite
3. Integrationsgegenstand
als wesentliche Merkmale der Integration dar. Jede Dimension enthält dabei
weitere Aufteilungen mit entsprechenden Integrationsgraden.
13
Kapitel II. Grundlagen
Abbildung II-3. Integrationsmerkmale
(vgl. [006] Seite18)
II.2.1.1. Integrationsrichtung
Die Integrationsrichtung lehnt sich an die horizontale und vertikale Aufteilung
eines Anwendungssystems im Unternehmen an (vgl . Abbildung II-1). Es wird
ebenfalls nach horizontaler und vertikaler Integration unterschieden.
14
Kapitel II. Grundlagen
Abbildung II-4. Integrationsrichtungen
II.2.1.1.1. Integrationsrichtung horizontal
Bei der horizontalen Integration stehen Anwendungssysteme im Vordergrund,
welche Teil des Leistungserstellungsprozesses sind, also Teilsysteme entlang der
Kette im Leistungserstellungsprozess darstellen. Die Grade der Integration
können wie folgt unterschieden werden;
1. teilweise Nutzung gemeinsamer Daten in den Teilsystemen, datenorientiert,
(niedriger Integrationsgrad)
2. gemeinsame Nutzung von Daten und Funktionen in den Teilsystemen,
funktionsorientiert
3. automatisierte Weitergabe von Aufgaben an folgende Teilsysteme,
prozessorientiert, (hoher Integrationsgrad)
II.2.1.1.2. Integrationsrichtung vertikal
Die vertikale Integration geht auf die Datenversorgung der Anwendungssysteme
in der vertikalen Aufbauorganisation ein (vgl. Abbildung II-1). Wichtig ist hier die
Abstimmung der Systeme, da hier eine Datenverdichtung von unten nach oben
vollzogen wird. Unter vertikaler Integration versteht man in erster Linie die
Datenversorgung der Planungs- und Kontrollsysteme aus den Administrations-
und Dispositionssystemen heraus (vgl. [005] Seite 4). Die Integrationsgrade
15
Kapitel II. Grundlagen
gehen dabei aus den unterschiedlichen Verdichtungs- und Detaillierungsgraden
hervor;
1. einfache Datenverdichtung auf operativer Ebene, (niedriger Integrationsgrad)
2. mittlere Datenverdichtung auf dispositiver Ebene
3. hohe Datenverdichtung auf strategischer Ebene, (hoher Integrationsgrad)
II.2.1.2. Integrationsreichweite
Bei der Integrationsreichweite kann man zwischen der internen bzw.
innerbetrieblichen und der externen bzw. überbetrieblichen Integration
unterscheiden. Die interne und die externe Integration werden auch zusammen
als Total Business Integration (TBI) bezeichnet (vgl. [204] [004] Seite 11) und ist
eine der wesentlichen Herausforderungen für die nächsten Jahre.
Abbildung II-5. Integrationsreichweiten
II.2.1.2.1. Integrationsreichweite intern
Die interne Integration ist die Integration der Anwendungen innerhalb eines
Unternehmens. Deswegen wird die interne auch als innerbetriebliche Integration
oder auch als Application-to-Application (A2A) Integration bezeichnet (vgl. [004]
Seite 11). Gemeint ist die Integration von Anwendungen innerhalb eines rechtlich
selbständigen Unternehmens. Die Integrationsgrade werden danach
unterschieden, ob sich die Anwendungen innerhalb oder außerhalb eines
Unternehmensbereiches befinden, und ob sich die Anwendungen in einem
16
Kapitel II. Grundlagen
Unternehmensstandort bzw. darüber hinaus befinden und integriert werden (vgl.
[003 ] Seite 19).
1. ein Unternehmensbereich, (niedriger Integrationsgrad)
2. mehrere Unternehmensbereiche
3. ein Unternehmensstandort
4. mehrere Unternehmensstandorte, (hoher Integrationsgrad)
II.2.1.2.2. Integrationsreichweite extern
Die externe Integration bezieht sich auf die Kommunikation von Anwendungen mit
externen, rechtlich selbständigen Unternehmen und Personen. Deswegen wird
die externe auch als überbetriebliche Integration bezeichnet. Diese Unternehmen
und Personen können sowohl Partner und Lieferanten eines Unternehmens sein,
als auch dessen Kunden bzw. Konsumenten (vgl. [004] Seite 11).
Die betriebswirtschaftliche Ebene auf der diese Integration vollzogen wird, wird im
allgemeinen auch als E-Business bezeichnet. Dieser Begriff kann nochmal
unterschieden werden, danach ob es sich bei dem externen
Kommunikationspartner im E-Business um einen Geschäftspartner handelt oder
um einen Konsumenten. Bei einem Geschäftspartner spricht man auch von
Collaborative-Commerce (C-Commerce) und einer Business-to-Business (B2B)
Integration. Bei einem Konsumenten spricht man auch vom Electronic-Commerce
(E-Commerce) und einer Business-to-Consumer (B2C) Integration (vgl. [204]).
Die Integrationsgrade bei der externen Integration reichen vom elektronischen
Datenaustausch über die Nutzung gemeinsamer Datenbestände sowie die
gemeinsame Nutzung von Programmen und Datenbeständen bis zur
automatischen Aufgabenabwicklung (vgl. [003] Seite 20).
1. elektronische Datenaustausch, (niedriger Integrationsgrad)
2. Nutzung gemeinsamer Datenbestände, datenorientiert
3. gemeinsame Nutzung von Funktionen und Datenbeständen,
funktionsorientiert
4. automatisierte Aufgabenabwicklung, prozessorientiert (hoher
Integrationsgrad)
II.2.1.3. Integrationsgegenstand
Es gibt vier wesentliche Objekte auf die sich die Integration von
Anwendungssystemen beziehen kann (vgl. Abbildung II-2). Jedes dieser Objekte
17
Kapitel II. Grundlagen
kann als Gegenstand der Integration herangezogen werden, um
Anwendungssysteme zu integrieren.
1. Daten
2. Programme
3. Benutzerschnittstelle
4. Prozesse
Abbildung II-6. Integrationsgegenstände
II.2.1.3.1. Integrationsgegenstand Daten
Die Daten-Integration basiert auf der Zusammenführung von Datenbeständen.
Zur Integration verschiedener Anwendungssysteme werden die Daten auf denen
die Anwendungssysteme operieren den Systemen zugreifbar gemacht, so dass
die Systeme auf einem gemeinsamen Datenbestand arbeiten. Dieses Vorgehen
bei der Daten-Integration kann in Abhängigkeit von der Datenverfügbarkeit und
dem Datenumfang in vier Integrationsgrade abgestuft werden.
1. manuelle Datenweitergabe (niedriger Integrationsgrad)
2. automatische Datenweitergabe
3. Zugriff auf gemeinsame Daten über Schnittstellen
18
Kapitel II. Grundlagen
4. gemeinsames Datenmodell (hoher Integrationsgrad)
Bei der manuellen Datenweitergabe werden Anwendungssysteme integriert,
indem Daten aus dem Datenbestand des einen Systems manuell in den
Datenbestand eines anderen übertragen werden. Dies kann z.B. bedeuten, dass
Exportfunktionen eines Systems bestimmte Daten auf ein Medium exportieren,
von dem ein anderes System die Daten wieder importieren kann. Dieses
Vorgehen ist stark von manuellen Eingriffen geprägt und relativ umständlich, oft
jedoch betriebliche Realität, da dies häufig die einzige Möglichkeit ist, Daten
zwischen verschiedenen Systemen auszutauschen.
Bei der automatischen Datenweitergabe wird das manuelle Überbringen der
Daten durch Export und Import ersetzt durch einen Automatismus. Das Prinzip
der Weitergabe eines erzeugten Datenbestandes bleibt jedoch gleich.
Ein grundsätzlich anderer Ansatz ist es, Daten mit mehreren
Anwendungssystemen gemeinsam zu nutzen und zuzugreifen. D.h. verschiedene
Anwendungssysteme greifen zusammen auf den gleichen Datenbestand zu,
wodurch eine Weitergabe von Datenbeständen, ob manuell oder automatisch,
überflüssig wird. Dieser Ansatz kann danach unterschieden werden, ob einem
System der Zugriff auf die Daten eines anderen System über Schnittstellen
gewährt wird, oder ob beide Systeme gleichberechtigt das selbe Datenmodell
benutzen. Über eine Schnittstelle zugreifende System haben nur mittelbaren
Zugriff auf die Daten, der Zugriff ist durch die Schnittstelle beschränkt. Im Falle
des unmittelbaren Zugriffs, nutzen die integrierten Anwendungssysteme
gleichberechtigt die Datenbasis, ohne zusätzliche Einschränkungen durch eine
weitere Schnittstelle.
II.2.1.3.2. Integrationsgegenstand Programme
Die Programm-Integration
3
setzt zur Integration von Anwendungssystemen an
der Programm-Ebene an. Diese Ebene (vgl. Abbildung II-2) ist für die
Verarbeitung der Geschäftslogik zuständig. Die Logik ist im Programm-Code
implementiert und realisiert die Datenverarbeitung des Anwendungssystems. Hier
setzt die Idee der Programm-Integration an. Der Programm-Code eines
Anwendungssystems wird aufgefasst als Teil eines Netzwerkes von
Datenverarbeitungsschritten. Diese Datenverarbeitungsschritte realisieren als
Gesamtheit die Geschäftslogik der Geschäftsprozesse. Die Logik ist aufgeteilt
unter den verschiedenen am Geschäftsprozess beteiligten
Anwendungssystemen. Die Programm-Integration zielt auf die Zusammenführung
der im Programm-Code enthaltenen Geschäftslogik.
Bei der Programmintegration kann man im wesentlichen zwei Integrationsgrade
unterscheiden. Dies ist zum einen die Nutzung gemeinsamer
Programm-Bibliotheken zur Umsetzung der Geschäftslogik. D.h. die
Anwendungssysteme nutzen zur Realisierung der Logik gemeinsamen
Programm-Code. Dieser Code ist aus den Anwendungssystemen heraus in
19
Kapitel II. Grundlagen
Bibliotheken verlagert und liegt den integrierten Anwendungssystemen vor. Der
nächste Grad der Programm-Integration ist der Austausch von Daten zwischen
den Anwendungssystemen. D.h. die Anwendungssysteme greifen über
Schnittstellen auf den Programm-Code und damit die Logik eines anderen
Anwendungssystems zu und nutzen diesen.
1. gemeinsame Nutzung von Bibliotheken (statisch)
2. gemeinsame Nutzung von Laufzeitumgebungen (dynamisch)
Die Programm-Integration ist die am stärksten ausgeprägte Integration. Die
Konzepte zur Programm-Integration sind die umfangreichsten
Integrations-Konzepte und sie unterstützen ein weites Spektrum zu lösender
Integrationsaufgaben. Außerdem ermöglichen sie einen hohen Grad der
Wiederverwendung und einen flexiblen Austausch der Anwendungsfunktionalität
(vgl. [003] Seite 65).
II.2.1.3.3. Integrationsgegenstand Benutzerschnittstelle
Die Benutzerschnittstellen-Integration
4
setzt zur Integration eines
Anwendungssystems an der Benutzerschnittstellen-Ebene (vgl. Abbildung II-2)
des Anwendungssystems an. Die Benutzerschnittstelle dient zur Kommunikation
eines Benutzers mit dem Anwendungssystem. Der Benutzer stößt über diese
Schnittstelle Geschäftsprozesse an, bzw. führt diese über die Schnittstelle am
System durch. Die weitere Abarbeitung der angestoßenen Prozesse obliegt dann
der im System codierten Geschäftslogik. Die Idee bei der Integration über die
Benutzerschnittstellen-Ebene ist es, die durch ein System bereitgestellte
Geschäftslogik über die Benutzerschnittstellen-Ebene anzusteuern, jedoch nicht
vom Benutzer, sondern von einem anderen Anwendungssystem. Das bedeutet,
dass ein anderes Anwendungssystem Zugriff auf die Benutzerschnittstelle eines
zu integrierenden Anwendungssystems haben muss. Der programmtechnische
Zugriff auf die graphische Benutzeroberfläche, zur automatischen Steuerung
eines System, wird auch als 'screen scraping' bezeichnet. Die Integration über die
Benutzerschnittstelle ist zwar der primitivste Ansatz für die Integration, er ist
jedoch sehr wichtig, da die Integration über die Benutzerschnittstelle oft die
einzige Möglichkeit ist um Altanwendungen zu integrieren. Altanwendungen
bieten oft keine andere Möglichkeit um an die gespeicherten Daten und
Programmlogik zu gelangen (vgl. [002] Seite 79ff). Dies ist z.B. der Fall, wenn die
Altanwendung keine klare Trennung von Daten-, Programm- und
Präsentations-Ebene besitzt und man so keinen Ansatzpunkt für eine Integration
bekommt.
II.2.1.3.4. Integrationsgegenstand Prozesse
Die Prozess-Integration
5
setzt an einer Ebene an, die sich nur teilweise im
20
Kapitel II. Grundlagen
Anwendungssystem befindet - die Ebene der Geschäftsprozesse. Hierbei handelt
es sich um die Tätigkeiten die ein Mensch oder ein Anwendungssystem ausführt.
Diese Tätigkeiten in einem betriebswirtschaftlichen Zusammenhang ergeben den
Geschäftsprozess. Wie auch in Abbildung II-2 zu erkennen ist, befinden sich die
Geschäftsprozesse nur zum Teil im Anwendungssystem. Das deutet an, daß
durch ein Anwendungssystem i.d.R. nur ein Teil des Geschäftsprozesses
abgedeckt wird. Der andere Teil des Prozesses wird von Benutzern durchgeführt
oder aber durch andere Anwendungssysteme abgedeckt. Die Zusammenführung
dieser Tätigkeiten (Prozesse) als Teile eines Geschäftsprozesses ist die Aufgabe
der Prozess-Integration. Die Grundlage von Geschäftsprozessen bilden die
Daten-, Programm- und die Präsentations-Ebene eines Anwendungssystems,
d.h. daß über diese Ebenen die Prozesse vollzogen werden. Aus diesem Grund
kann die Prozess-Integration nicht ohne die zu Grunde liegenden
Integrationsgegenstände Daten, Programm und/oder Präsentation stattfinden, sie
benötigt die Integrationstechniken dieser Ebenen. Insofern baut die
Prozess-Integration (vgl. Abbildung II-3) auf den Integrationsgegenständen Daten,
Programme und Präsentation auf.
Man kann zwischen einer aufgabenträgerorientierten und einer
aufgabenorientierten Prozess-Integration unterscheiden und entsprechend die
Integrationsgrade angeben;
1. aufgabenträgerorientiert (niedriger Integrationsgrad)
2. aufgabenorientiert (hoher Integrationsgrad)
Bei der aufgabenträgerorientierten Prozess-Integration werden die zu
bearbeitenden Aufgaben (Prozesse) an einem Arbeitsplatz zusammengeführt.
Dies setzt also immer noch das manuelle Eingreifen des am Arbeitplatz tätigen
Benutzers voraus. Der Benutzer ist nun der Träger der Aufgaben, welche zur
Bearbeitung am Arbeitsplatz des Benutzers zusammenlaufen. Ein
weitergehendes Konzept ist die aufgabenorientierte Prozess-Integration. Hierbei
werden die Teilaufgaben eines Geschäftsprozesses durchgängig unterstützt. D.h.
es ist kein manuelles Eingreifen in den Prozess nötig, da der Prozess jetzt im
Anwendungssystem selber stattfindet (vgl. Abbildung II-3).
II.2.2. Integrationsansätze
Es gibt grundsätzlich drei verschiedene Ansätze um eine Integration von
Anwendungssystemen zu erreichen. Diese Ansätze realisieren die
Integrationsaufgaben mit zum Teil sehr ähnlichen Technologien, jedoch auf einem
jeweils unterschiedlichen Weg. In der betrieblichen Praxis werden je nach Bedarf
oft Mischformen dieser Ansätze eingesetzt. Der Grund dafür ist die historische
Entwicklung der Systemlandschaft und die sich verändernden
21
Kapitel II. Grundlagen
Integrationsanforderungen in den Unternehmen (vgl. [003 ] Seite 67ff).
1. Punkt-zu-Punkt
2. ERP
3. Middleware
II.2.2.1. Integrationsansatz Punkt-zu-Punkt
Unter dem Punkt-zu-Punkt-Ansatz versteht man die direkte Verbindung
unterschiedlicher Anwendungssysteme. Jedes System, welches an einem
Geschäftsprozess beteiligt ist und zur Abwicklung der Geschäftslogik
herangezogen wird, muss über eine eigene Kommunikations-Verbindung erreicht
werden. Diese Verbindung kann je nach Anwendungssystem von sehr
unterschiedlicher Ausprägung sein und erfordert den Einsatz von
unterschiedlichsten Technologien. Diese verschiedenen Technologien müssen bei
dem Punkt-zu-Punkt-Ansatz jeweils in den Anwendungssystemen berücksichtigt
werden, damit eine Verbindung hergestellt werden kann. Diese entstehenden
Verbindungen werden auch allgemein als Schnittstellen bezeichnet. Bei einem
Punkt-zu-Punkt-Ansatz, welcher z.T. das Resultat unzureichender Planung der
Informations-Architektur eines Unternehmens ist, werden neue Anwendungen in
die Systemlandschaft eingefügt, indem bedarfsgerecht Schnittstellen eingerichtet
werden. Über diese Schnittstellen werden dann direkte Verbindungen zwischen
den Systemen gezogen. Auf diese Weise entstehen komplexe und chaotische
System- und Schnittstellenlandschaften, welche oft auch als
'Schnittstellen-Chaos' (vgl. [001] Seite 23) bezeichnet werden.
Hierbei entstehen potenziell n
2
-n Verbindungen und damit 2*(n
2
-n) Schnittstellen,
wobei n gleich der Anzahl der Anwendungssysteme ist. Die potenzielle Anzahl
von Verbindungen liegt also bei einer Ordnung von O(n
2
). Dies ruft einen hohen
Wartungs- und Pflegeaufwand und damit einen enormen finanziellen Aufwand
hervor (vgl. [002] Seite 9, [003] Seite 68).
II.2.2.2. Integrationsansatz ERP
Der ERP-Ansatz löst das Integrationsproblem durch vorintegrierte
Software-Module. Hierbei wird versucht betriebswirtschaftliche Prozesse in
Software-Modulen abzubilden, welche die wesentlichen
Standard-Geschäftsprozesse abdecken. Durch eine modulare Struktur der
ERP-Systeme soll gewährleistet werden, dass auch individuelle branchen- und
unternehmensspezifische Prozesse abgebildet und aus Modulen
zusammengesetzt werden können. Die Integration wird also dadurch erreicht,
dass die Menge der möglichen Module fest definierte Schnittstellen haben,
22
Kapitel II. Grundlagen
welche ohne großen Aufwand durch andere Module genutzt werden können.
Obwohl die ERP-Systeme einen wesentlichen Fortschritt bei der
Anwendungsintegration gebracht haben, werden durch sie nicht, wie
versprochen, sämtliche Unternehmensaufgaben gelöst und die Herausforderung
der Integration ist aktueller denn je (vgl. [100] Seite 90). Die ERP-Systeme
spielen heute wegen ihrer Komplexität vorrangig im Bereich von Mittel- bis
Großunternehmen eine bedeutende Rolle. Sie übernehmen dort die Funktion
einer zentralen Kernanwendung.
II.2.2.3. Integrationsansatz Middleware
Bei dem middlewarebasierten Ansatz wird eine Software eingeführt, welche als
Vermittler zwischen den an der Kommunikation beteiligten Systemen fungiert. Die
Middleware bildet eine Kommunikationsinstanz zwischen den beteiligten
Kommunikationspartnern, welche die Middleware nutzen, um miteinander in
Verbindung zu treten
6
. Die Kommunikation zwischen den Anwendungssystemen
findet über die vermittelnde Softwareschicht, die Middleware, statt und nicht mehr
direkt mit dem dienstanbietenden System. Die beteiligten Anwendungssysteme
werden durch die Middleware integriert.
Unter bestimmten Bedingungen
7
kann eine Middleware die Funktion einer
zentralen Kommunikationsdrehscheibe übernehmen. In diesem Fall
kommunizieren alle beteiligten Systeme über eine einzige zentrale Stelle,
wodurch jedes System mit jedem anderen in Verbindung treten kann. Dieses hat
den Vorteil, dass ein System nur noch eine Schnittstelle zu kennen braucht und
über diese Schnittstelle mit allen anderen Systemen kommunizieren kann. Aus
der geringen Anzahl von Schnittstellen ergibt sich hierbei ein verringerter
Installations- und Wartungsaufwand. Auch die Entwicklung und Integration neuer
Systeme wird durch die verminderte Schnittstellen-Komplexität dramatisch
gesenkt gegenüber einem Punkt-zu-Punkt-Ansatz.
Middleware bildet wegen seiner umfangreichen Möglichkeiten und Technologien
die technologische Basis und die technische Infrastruktur von EAI.
Die Technologien und Methoden die bei Middleware-Produkten zum Einsatz
kommen, dienen hauptsächlich der Daten-Integration (siehe Abschnitt II.2.1.3.1)
und der Programm-Integration (siehe Abschnitt II.2.1.3.2), die Integration der
Präsentation spielt bei Middleware-Produkten keine Rolle. Durch die
Middleware-Produkte wird eine Integration bis auf die Programm-Ebene erreicht,
die Semantik der durchgeführten Programme bleibt jedoch unberücksichtigt. D.h.
die Semantik und damit die auf den Programmen aufbauenden
Geschäftsprozesse werden durch Middleware nicht direkt unterstützt.
23
Kapitel II. Grundlagen
II.2.3. Middleware
Die Middleware bildet das Kernstück der Enterprise Application Integration. Der
Begriff dient als allgemeine Bezeichnung für Programme, die dazu dienen, zwei
oder mehr bereits existierende Anwendungen miteinander zu verbinden oder
zwischen ihnen zu vermitteln (vgl. [300] Suchwort Middleware). Die Middleware
dient als Kommunikationsinstanz zwischen den zu integrierenden
Anwendungssystemen. Sie ist eine Software und benötigt ein Betriebssystem als
Ablaufumgebung. Diese Middleware-Software als Schicht gesehen, bildet
zwischen den Anwendungssystemen und dem Betriebssystem eine
Zwischenschicht (vgl. Abbildung II-7, [003] Seite 102).
Abbildung II-7. Middleware als Zwischenschicht
Im Rahmen des ISO/OSI-Referenzmodells für Rechnerkommunikation in offenen
Systemen ist Middleware den anwendungsorientierten Protokollen der Ebenen
5-7 (session layer, presentation layer, application layer) zuzuordnen (vgl. [007]
Seite 5, Abbildung II-8).
24
Ende der Leseprobe aus 152 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2004, Enterprise Application Integration im Neckermann Produktions-System, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/223825
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare