Enterprise Application Integration im Neckermann Produktions-System

Inhaltsverzeichnis

Vorwort

I. Einleitung

II. Grundlagen
II.1. Betriebliche Anwendungssysteme
II.1.1. betriebswirtschaftliche Betrachtung
II.1.2. technische Betrachtung
II.2. Grundlagen der Integration
II.2.1. Integrationsmerkmale
II.2.1.1. Integrationsrichtung
II.2.1.1.1. Integrationsrichtung horizontal
II.2.1.1.2. Integrationsrichtung vertikal
II.2.1.2. Integrationsreichweite
II.2.1.2.1. Integrationsreichweite intern
II.2.1.2.2. Integrationsreichweite extern
II.2.1.3. Integrationsgegenstand
II.2.1.3.1. Integrationsgegenstand Daten
II.2.1.3.2. Integrationsgegenstand Programme
II.2.1.3.3. Integrationsgegenstand Benutzerschnittstelle
II.2.1.3.4. Integrationsgegenstand Prozesse
II.2.2. Integrationsansätze
II.2.2.1. Integrationsansatz Punkt-zu-Punkt
II.2.2.2. Integrationsansatz ERP
II.2.2.3. Integrationsansatz Middleware
II.2.3. Middleware
II.2.3.1. Datenbank-Middleware
II.2.3.2. Programmorientierte Middleware
II.2.3.2.1. Verbindung versus Synchronisation
II.2.3.2.1.1. Kopplung
II.2.3.2.2. Aufruf-Schnittstellen (RPC)
II.2.3.2.3. Nachrichten-Schnittstellen (Message-Passing)
II.2.3.2.4. Aufruf- versus Nachrichten-Schnittstellen
II.2.3.3. Middleware-Dienste
II.2.4. Application-Server
II.2.4.1. Mehrschichtige Architekturen
II.2.4.1.1. Zwei-Schichten-Architektur
II.2.4.1.2. Drei-Schichten-Architektur
II.2.4.1.3. Zwei-Einhalb-Schichten-Architektur
II.2.4.1.4. Vier-Schichten-Architektur
II.2.4.2. Application-Server als Mehrschichtige-Architektur
II.2.4.3. Middleware im Application-Server
II.2.4.3.1. RPC-Middleware im Application-Server
II.2.4.3.2. MOM-Middleware im Application-Server
II.2.4.3.3. Vergleich RPC und MOM im Application-Server
II.2.5. Service-orientierte-Architektur
II.2.5.1. Kopplung einer SOA
II.2.5.2. Services einer SOA
II.2.5.3. Prinzipien einer SOA
II.2.6. WebServices
II.2.6.1. Nutzung offener Standards
II.2.6.2. Techniken der WebServices
II.2.6.3. Kopplung von WebServices
II.2.6.4. WebServices versus RPC/MOM
II.2.6.5. SOAP
II.2.6.6. Integrationslösung mit Hilfe von WebServices
II.2.7. Enterprise Service Bus

III. Ist-Analyse
III.1. Kernaufgaben des NPS
III.2. Anforderungen an das neue NPS
III.2.1. Gründe für die Neuimplementierung
III.2.2. Funktionale Anforderungen an das neue NPS laut Lastenheft...
III.3. Gegenwärtiger Entwicklungsstand
III.3.1. Anwendungen und deren Aufgaben
III.3.2. Systemstruktur
III.3.2.1. Hardware-Topologie
III.3.2.2. Drei-Ebenen-Modell
III.3.2.2.1. Benutzerschnittstellen-Ebene
III.3.2.2.2. Programm-Ebene
III.3.2.2.3. Daten-Ebene
III.3.2.2.3.1. Helios
III.3.2.2.3.2. Cumulus
III.3.2.2.3.3. mysql
III.3.2.3. Schichten-Architektur
III.4. Analyse der Integrationsfähigkeit
III.4.1. Integrationsgegenstand Benutzerschnittstelle
III.4.2. Integrationsgegenstand Programme
III.4.3. Integrationsgegenstand Daten
III.5. Ergebnis der Analyse

IV. Soll-Konzept
IV.1. Erweiterung des NPS um einen ESB
IV.2. Anschluss des NPS an einen ESB
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
IV.3. Aufbau des ESB und Integration mit dem NPS
IV.3.1. Aufbau des ESB
IV.3.2. Aufbau der um den ESB erweiterten Infrastruktur
IV.4. Ergebnis des Konzeptes

V. Implementierung
V.1. Aufbau des Anwendungsszenarios
V.1.1. Receiver
V.1.2. Sender
V.1.3. ESB
V.2. Aufbau des ESB im Anwendungsszenario
V.2.1. SOAP-Implementierung AXIS
V.2.2. Implementierung von Bus und Router

VI. Zusammenfassung und Ausblick

Literaturverzeichnis

Glossar und Abkürzungsverzeichnis

Stichwortverzeichnis

A. Programmcode des Anwendungsszenarios für einen ESB

Tabellenverzeichnis

II-1. RPC-Middleware

III-1. NPS Anwendungen und deren Aufgaben

Abbildungsverzeichnis

I-1. Kommunikationsdrehscheibe

II-1. Anwendungssysteme in der Unternehmensorganisation

II-2. Anwendungsarchitektur in drei Ebenen

II-3. Integrationsmerkmale

II-4. Integrationsrichtungen

II-5. Integrationsreichweiten

II-6. Integrationsgegenstände

II-7. Middleware als Zwischenschicht

II-8. Middleware im ISO/OSI-Referenzmodell

II-9. Datenbank-Middleware

II-10. Programmorientierte Middleware

II-11. Verbindung versus Synchronisation

II-12. Zwei-Schichten-Architektur

II-13. Drei-Schichten-Architektur

II-14. Zwei-Einhalb-Schichten-Architektur

II-15. Vier-Schichten-Architektur

II-16. Schichten-Architektur des Application-Server

II-17. RPC Middleware im Application-Server

II-18. MOM Middleware im Application-Server

II-19. Integration mit RPC und MOM-Middleware

II-20. Enterprise Service Bus

III-1. Funktionales Verhalten des NPS-Gesamtsystems

III-2. Funktionales Verhalten der NPS-Teilsysteme

III-3. Hardwaretopologie

III-4. serverbasiertes OPI

III-5. Speicherung eines Cumulus-Asset

III-6. Helios Companion

III-7. Zwei-Einhalb-Schichten-Architektur des NPS

IV-1. SOA mit Hilfe eines ESB als Kummunikationsdrehscheibe

IV-2. Anbindung des NPS als Gesamtsystem an den ESB

IV-3. Anbindung der Teilsysteme des NPS an den ESB

IV-4. Topologie des ESB für die Integration im NPS

IV-5. Integration der ESB-Topologie mit der NPS-Topologie

V-1. Anwendungsszenario

V-2. Anwendungsszenario (formelle Darstellung)

V-3. Ergebnis des Anwendungsszenario

V-4. ESB Komponenten Bus und Router

V-5. SOAP-Implementierung AXIS

V-6. Verkettung von AXIS-Engines für die SOAP-Verarbeitung im ESB

V-7. Der Enterprise Service Bus des Anwendungsszenarios

Beispiele

A-1. HelloServiceClient.java im ’Sender’

A-2. parameter.xml im ’Sender’

A-3. RedirectHandler.java im ’Bus’

A-4. GlobalLogHandler.java im ’Bus’

A-5. BusProvider.java im ’Bus’

A-6. WSDDBusProvider.java im ’Bus’

A-7. org.apache.axis.deployment.wsdd.Provider im ’Bus’

A-8. server.deploy.wsdd im ’Bus’

A-9. server.undeploy.wsdd im ’Bus’

A-10. BusSender.java im ’Bus’

A-11. BusTransport.java im ’Bus’

A-12. client.deploy.wsdd im ’Bus’

A-13. JMSListenerBean.java im ’Router’

A-14. RedirectHandler.java im ’Router’

A-15. GlobalLogHandler.java im ’Router’

A-16. RouterProvider.java im ’Router’

A-17. WSDDRouterProvider.java im ’Router’

A-18. org.apache.axis.deployment.wsdd.Provider im ’Router’

A-19. server.deploy.wsdd im ’Router’

A-20. HelloService.java im ’Receiver’

A-21. server.deploy.wsdd im ’Receiver’

A-22. server.undeploy.wsdd im ’Receiver’

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

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.

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(n2) Verbindungen (vgl.001Seite 23), was in der Folge zu sehr hohen Kosten bei der Entwicklung und Wartung führt (vgl.003Seite 2). Schnittstellenwartung verschlingt vielfach bis zu 60% des gesamten IT-Budgets (vgl.100Seite 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.004Seite 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 in dieser Leseprobe nicht enthalten

Abbildung I-1. Kommunikationsdrehscheibe

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 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.003Seite 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 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.003Seite 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 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.004Seite 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.

Fußnoten

1. Umsatzanteile beziehen sich auf das Jahr 2003

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,004Seite 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.001Seite 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.003Seite 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.

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.003Seite 18).

Abbildung II-1. Anwendungssysteme in der Unternehmensorganisation

Abbildung in dieser Leseprobe nicht enthalten

(vgl.005Seite 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

Kapitel II. Grundlagen

Abbildung II-2. Anwendungsarchitektur in drei Ebenen

Abbildung in dieser Leseprobe nicht enthalten

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-Ebene1. 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 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-Ebene2. 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

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.

Abbildung II-3. Integrationsmerkmale

Abbildung in dieser Leseprobe nicht enthalten

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

Abbildung II-4. Integrationsrichtungen

Abbildung in dieser Leseprobe nicht enthalten

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.005Seite 4). Die Integrationsgrade 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.204004Seite 11) und ist eine der wesentlichen Herausforderungen für die nächsten Jahre.

Abbildung II-5. Integrationsreichweiten

Abbildung in dieser Leseprobe nicht enthalten

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 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.004Seite 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.003Seite 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 kann als Gegenstand der Integration herangezogen werden, um Anwendungssysteme zu integrieren.

1. Daten

2. Programme

3. Benutzerschnittstelle

4. Prozesse

Abbildung II-6. Integrationsgegenstände

Abbildung in dieser Leseprobe nicht enthalten

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

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-Integration3setzt 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 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-Integration4setzt 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.002Seite 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-Integration5setzt an einer Ebene an, die sich nur teilweise im 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 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 n2-n Verbindungen und damit 2*(n2-n) Schnittstellen, wobei n gleich der Anzahl der Anwendungssysteme ist. Die potenzielle Anzahl von Verbindungen liegt also bei einer Ordnung von O(n2). 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, 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 treten6. 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 Bedingungen7kann 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.

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

Abbildung in dieser Leseprobe nicht enthalten

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.007Seite 5, Abbildung II-8).

Abbildung II-8. Middleware im ISO/OSI-Referenzmodell

Abbildung in dieser Leseprobe nicht enthalten

(vgl. 003 Seite 103, 007 Seite 33)

Die Kommunikation der Anwendungssysteme ist über die Middleware nicht mehr an das Betriebssystem gebunden, sondern nur noch an die Middleware bzw. an die von ihr bereitgestellten Kommunikations-Technologien. Sie stellt den Anwendungssystemen einheitliche Möglichkeiten8bereit miteinander zu kommunizieren, unabhängig vom zu Grunde liegenden Betriebssystem. Hierdurch erfüllt Middleware eine wichtige Aufgabe; die Abstraktion der Funktionalität eines Systems auf eine dienstorientierte Ebene. Die Komplexität eines Systems wird versteckt und die Dienste eines anderen Systems können damit unabhängig von dessen Betriebssystem und Netzwerkprotokollen genutzt werden (vgl.002Seite 120). Im Laufe der technologischen Entwicklung von Middleware-Produkten, haben sich eine Menge verschiedener Ansätze für deren Umsetzung ergeben. In Anlehnung an die Ebenen-Struktur eines Anwendungssystems (vgl. Abbildung II-2) lassen sich Middlewareprodukte danach unterscheiden, auf welcher Ebene eine Integration mittels einer Middleware stattfindet. Die zwei wichtigsten Vertreter von Middleware sind die auf der Daten-Ebene ansetzende Datenbank-Middleware und die auf der Programm-Ebene ansetzende programmorientierte Middleware.

II.2.3.1. Datenbank-Middleware

Die Datenbank-Middleware führt eine Integration auf der Daten-Ebene durch (vgl. Abschnitt II.2.1.3.1). Die Datenbank-Middleware unterstützt den Integrationsgrad eines gemeinsamen Datenmodells. Zum Zwecke der Integration von Anwendungssystemen werden die zu Grunde liegenden Datenbanken der beteiligten Anwendungssysteme zusammengeführt, zu einem einzigen logischen Datenmodell. Ziel ist die integrierte Sicht auf die verteilten Daten im Sinne einer einzelnen virtuellen bzw. föderierten Datenbank. Das virtuelle Datenmodell ist verteilt auf verschiedene physikalische Datenbanken, über welche man anhand der Middleware eine einheitliche Schnittstelle bekommt (vgl. Abbildung II-9 ). Für das Programmiermodell sieht es so aus, als wären die Daten in einer einzigen physikalischen Datenbank abgelegt. Mit dieser Datenbank-Middleware ist es möglich, verschiedene Datenbank von verschiedenen Herstellern auf unterschiedlichen Technologien basierend zusammenzuführen zu einem gemeinsamen Datenmodell. Die nötige Transformation der Daten zwischen den Datenbank übernimmt hierbei die Middleware.

Abbildung II-9. Datenbank-Middleware

Abbildung in dieser Leseprobe nicht enthalten

Der große Nachteil bei einer Integration über die Daten-Ebene ist die Umgehung der auf den Daten operierenden Anwendungslogik. Hierbei wird der Code und damit die Logik einer integrierten Anwendung nicht verwendet. Oft sind die Daten jedoch sehr eng mit der Logik des Anwendungssystems verbunden. Über die Programmlogik werden oft Zustände im Datenbestand sichergestellt, welche dadurch als gegeben vorausgesetzt werden können. Durch den direkten Zugriff auf die Daten durch ein anderes Anwendungssystem, ohne die Anwendungslogik zu nutzen, können sehr schnell Inkonsistenzen im Datenbestand auftreten. Diese führen in der Folge zu Fehlern deren Ursache schwer zu lokalisieren ist.

II.2.3.2. Programmorientierte Middleware

Programmorientierte Middleware setzt zur Integration an der Programm-Ebene eines Anwendungssystems an (vgl. Abschnitt II.2.1.3.2). Die Integration findet hier durch die Zusammenführung und gemeinsame Nutzung der Laufzeit eines Anwendungssystems statt (vgl. Abschnitt II.2.3.2). Durch die gemeinsame Nutzung wird die Anwendungslogik und damit die Geschäftslogik unter den an der Integration beteiligten Anwendungssystemen geteilt bzw. über die Middleware integriert. Durch die programmoriente Middleware ist ein hoher Grad an Wiederverwendung der Anwendungslogik gewährleistet. Zudem entstehen durch eine programmorientierte Middleware nicht die Möglichkeiten der Dateninkonsistenz, wie es bei der Datenbank-Middleware der Fall ist. Hier wird nicht direkt auf die Daten eines Anwendungssystems zugegriffen wodurch die Logik eines Systems umgangen wird. Hierbei wird ausschließlich über die Logik eines Anwendungssystems auf die Daten zugegriffen.

Abbildung II-10. Programmorientierte Middleware

Abbildung in dieser Leseprobe nicht enthalten

Programmorientierte Middleware kann man danach unterscheiden, ob die Kommunikation verbindungsorientiert oder verbindungslos ist.

II.2.3.2.1. Verbindung versus Synchronisation

(vgl. 001 Seite 78ff)

Da die Unterscheidung nach der Verbindung nicht unmittelbar klar ist, werde ich den Begriff der Verbindung näher beschreiben; Außerdem wird der Begriff der Synchronisation, welcher in einer engen Beziehung zu dem Begriff der Verbindung steht, im Zusammenhang erläutert.

Zunächst kann man die Kommunikation von Programmen danach unterscheiden, ob sie synchron oder asynchron stattfindet. Bei der synchronen Kommunikation sind der Sender und der Empfänger in ihrem Ablauf aneinander gekoppelt. Bei der asynchronen Kommunikation ist dies nicht der Fall.

Bei der synchronen Kommunikation schickt ein Sender einem Empfänger eine Nachricht und blockiert solange bis der Empfänger der Nachricht eine Antwort auf die Nachricht zurückschickt. Solange der Sender die Antwort nicht erhalten hat, blockiert der Sender und wartet bis die Antwort eintrifft. Dieses Verfahren liegt dem entfernten Prozedur-Aufrufen (Remote Procedure Call - RPC) zugrunde.

Bei der asynchronen Kommunikation hingegen schickt der Sender einem Empfänger eine Nachricht, wartet jedoch nicht auf die Antwort. Der Sender der Nachricht blockiert nach dem Senden der Nachricht nicht und kann sofort weiterarbeiten. Dieses Verfahren wird oft auch als Message-Passing bezeichnet.

Häufig wird das Merkmal, synchron oder asynchron, als entscheidendes Kommunikations-Merkmal herangezogen. Gerade bei EAI-Systemen wird meist von einer asynchronen Kommunikation gesprochen. Dieses Merkmal ist jedoch nicht das entscheidende bei der Kommunikation. Aus dem einfachen Grund, da sich die synchrone aus der asynchronen und auch die asynchrone aus der synchronen Kommunikation gewinnen lässt.

Der vordergründige Nachteil der synchronen Kommunikation ist, dass der Sender so lange nichts tun kann, wie er auf die Antwort des Empfängers wartet. Dies kann jedoch durch Auslagerung der synchronen Kommunikation in einen eigenen Prozess bzw. Thread umgangen werden. Dieser Prozess wartet nebenläufig auf die Antwort des Nachrichten-Empfängers, während der Hauptprozess weiterarbeiten kann. Somit hat man eine synchrone Kommunikation in eine asynchrone Kommunikation umgewandelt. Andersherum kann auch eine asynchrone Kommunikation in eine synchrone Kommunikation umgewandelt werden, in dem der Sender einfach solange blockiert, bis der Empfänger eine Antwort gesendet hat.

Die Synchronisation der Kommunikation scheint nicht das entscheidende Kriterium für die Kommunikation zu sein. Wichtiger als die Synchronisation ist die Orientierung an der Verbindung.

Eine verbindungsorientierte Kommunikation erfordert, dass der Sender zum Empfänger der Nachricht eine Verbindung aufbaut. Hierzu bindet sich der Sender an den Empfänger und teilt mit diesem für den Zeitraum der Kommunikation einen gemeinsamen Zustand bis alle Daten bzw. die Nachricht und die Antwort auf die Nachricht ausgetauscht sind. Dieses Vorgehen erfordert es ganz offensichtlich, dass der Sender und der Empfänger der Nachricht zum selben Zeitpunkt ’wach’ und ’breit’ sind um die Kommunikation durchzuführen. Zudem wird hier von beiden Partnern eine typisierte Schnittstelle erwartet, welche durch einen Compiler einer statischen Typprüfung unterworfen ist, folglich nur bestimmte Datentypen zulässt. Außerdem ist gegeben durch die direkte Verbindung zwischen den Kommunikationspartnern die Anzahl der Empfänger der Nachricht maximal eins. Verbindungslose Kommunikation erfordert nicht, dass der Sender eine Verbindung zum Empfänger aufbaut. Der Sender weiß ohne weitere Maßnahmen nicht einmal, ob die Nachricht beim Empfänger ankommt und ob diese verarbeitet wird. Diese Art der Kommunikation erfordert einen dritten Kommunikationspartner, welcher die Nachrichten aufnimmt und an den Empfänger weiterleitet. Weiterhin müssen bei dieser Art der Kommunikation nicht zwangsläufig beide Kommunikationspartner gleichzeitig ’bereit’ und nicht einmal gleichzeitig ’wach’ sein, d.h. zum Zeitpunkt des Sendens kann der Empfänger nicht empfangsbereit oder sogar physikalisch ausgeschaltet sein. Die Schnittstellen des Senders und des Empfängers beschränken sich lediglich auf das Format und den Inhalt der Nachricht, welche hier jeglicher Art und Kombination von Datentypen sein kann. Die Anzahl der Empfänger ist unbeschränkt, sie kann effektiv sogar leer sein. Insbesondere ist diese Art der Kommunikation zustandslos, d.h. die Partner teilen hierbei keinen gemeinsamen Zustand, da sie keine Verbindung zueinander besitzen.

Wichtigstes Merkmal der Kommunikation ist also die Verbindung. Mit geeigneten Techniken (Nebenläufigkeit bzw. Blockierung) kann aus verbindungsorientierten und verbindungslosen Kommunikationen eine synchrone oder asynchrone Kommunikation erstellt werden. Ohne die Zuhilfenahme dieser Mittel kann man jedoch sagen, dass eine verbindungsorientierte Kommunikation im Kern synchron abläuft und eine verbindungslose Kommunikation im Kern asynchron.

Abbildung II-11. Verbindung versus Synchronisation

Abbildung in dieser Leseprobe nicht enthalten

[...]