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 (RP)C  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.  MO-MMiddleware 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  ESB90

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

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 MO-MMiddleware  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 ² ) 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.

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) ¹ ü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

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

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

(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

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.

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

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 ³ 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 ⁴ 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 ⁵ 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 ² -n Verbindungen und damit 2*(n ² -n) Schnittstellen, wobei n gleich der Anzahl der Anwendungssysteme ist. Die potenzielle Anzahl von Verbindungen liegt also bei einer Ordnung von O(n ² ). 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