Inhaltsverzeichnis I

Inhaltsverzeichnis   

Inhaltsverzeichnis   I

Abk  ürzungsverzeichnis  III

Abbildungsverzeichnis   V

1  Einleitung  1

1.1  Motivation  1

1.2  Problemdarstellung und Eingrenzung des Themas  3

1.3  Vorgehensweise.  3

2  Middleware.  5

2.1  Definition.  5

2.2  Kategorien  6

2.3  Einsatzgründe  7

2.4  Nutzen  8

3  Enterprise Application Integration.  10

3.1  Definition.  13

3.2  Integrationsebenenen.  15

3.2.1  Integration auf Datenebene.  15

3.2.2  Integration auf Objektebene  16

3.2.3  Integration auf Prozessebene  16

3.3  Architektur.  17

3.3.1  Komponenten.  17

3.3.2  Message Broker  21

3.3.3  Integration Server  23

3.4  Funktionen.  24

3.5  Einsatzmöglichkeiten  26

3.5.1  Application-to-Application (A2A)  27

3.5.2  Administration-to-Administration (A2A)  28

3.5.3  Business-to-Business (B2B)  29

Inhaltsverzeichnis II

4  Web Services  31

4.1  Definition.  32

4.2  Architektur.  34

4.2.1  Serviceanbieter  34

4.2.2  Servicenachfrager  34

4.2.3  Serviceregistrierung.  35

4.3  Komponenten  37

4.3.1  Hypertext Transfer Protocol (HTTP)  37

4.3.2  Extensible Markup Language (XML)  38

4.3.3  Simple Object Access Protocol (SOAP)  43

4.3.4  Web Service Description Language (WSDL)  46

4.3.5  Universal Description Discovery Integration (UDDI)  49

4.4  Einsatzmöglichkeiten  53

4.4.1  Application-to-Application (A2A)  53

4.4.2  Business-to-Business (B2B)  53

4.4.3  Consumer-to-Administration (C2A)  54

5  Szenario  56

5.1  Haushalts- und Verwaltungsreform.  56

5.2  Situation in Hessen.  57

5.3  Situation Rheinland-Pfalz.  58

5.3.1  Kameralistik und Doppik.  59

5.3.2  Finanzsysteme des Landes Rheinland-Pfalz.  60

5.3.3  Standardsoftware SAP R/3  62

5.4  Ist-Zustand Integrationsarchitektur  66

5.5  Lösungsansatz Enterprise Application Integration.  68

5.6  Lösungsansatz Web Services  70

6  Fazit.  73

Glossar   75

Literaturverzeichnis   78

Abkürzungsverzeichnis III

API Application Programming Interface A2A Application to Application BABSY Beihilfeabrechnungssystem BAPI Business Application Programming Interface B2B Business to Business CARLA Reisekostenabwicklung CRM Customer Relationship Management C2A Consumer to Administration DAISY Dialogisiertes Abrechnungs- und Informationssystem EAI Enterprise Application Integration EDI Electronic Data Interchange ERP Enterprise Ressource Planning GML Generalized Markup Language G2C Government to Customer G2G Government to Government HTTP Hyper Text Transfer Protocol

IRMA

ISO International Standard Organisation ITEF Internet Engineering Task Force KLEIST Personalleistungserfassungssystem KLR Kosten- und Leistungsrechnung LHO Landeshaushaltsordnung LSV Landesbetrieb für Straßen und Verkehr NAICS North American Industry Classification System NASSL Network Accessible Service Specification Language NKF Neues Kommunales Finanzmanagement OFD Oberfinanzdirektion

Abkürzungsverzeichnis IV

PIKO Projekt-Management-Verfahren RPC Remote Procedure Call SSL Secure Socket Layer SCM Supply Chain Management SDL Service Description Language SGML Standard Generalized Markup Language SOAP Simple Object Access Protocol TCP/IP Transmisson Control Protocol/Internet Working Protocol UDDI Universal Description Discovery Integration UNSPSC Universal Standard Products Services Classification URL Uniform Resource Locator WSDL Web Service Description Language WYSIWYG What You See Is What You Get W3C World Wide Web Consortium XML Extensible Markup Language ZBV Zentrale Besoldungs- und Versorgungsstelle ZULI Projekt-Bewirtschaftungs-Verfahren

Abbildungsverzeichnis   

Abbildungsverzeichnis   

Abbildung  1: Enterprise Application Integration  

Abbildung  2: Business process integration in european businesses.  

Abbildung  3: Ebenen der Integration  

Abbildung  4: Hub-and-Spoke Ansatz.  

Abbildung  5: Bus Ansatz.  

Abbildung  6: Punkt-zu-Punkt Ansatz.  

Abbildung  7: Formen von EAI.  

Abbildung  8: Web Service Architektur - Rollen und Operationen  

Abbildung  9: Bestellung als XML-Dokument  

Abbildung  10: Ablauf einer SOAP-Nachricht.  

Abbildung  11: Struktur einer SOAP-Nachricht.  

Abbildung  12: Gemeinsame Definition eines Web Service in WSDL.  

Abbildung  13: Globales UDDI-Verzeichnis  

Abbildung  14: SAP UDDI Business Registry.  

Abbildung  15: Modularer Aufbau des R/3-Systems  

Abbildung  16: Schnittstellen-Chaos  

Abbildung  17: EAI-Ansatz  

Abbildung  18: Web-Service-Ansatz  

Einleitung 1

1 Einleitung

1.1 Motivation

Im derzeit bundesweit stattfindenden Reformprozess sind Verwaltungen gefordert, traditionelle Strukturen und Denkweisen zu überwinden. Behörden wandeln sich zu Dienstleistern der Wirtschaft und der Gesellschaft. Mehr Bürgernähe, die effiziente Gestaltung und Automatisierung von Leistungen, die Beschleunigung von Verfahren sowie die inter- und innerorganisatorische Zusammenarbeit wie auch die Einführung einer Kosten- und Leistungsrechnung bei den Organisationen sind Indizien und Indikatoren für den Wandel der öffentlichen Verwaltung.

In den letzten Jahren hat die Informations- und Kommunikationstechnik als Instrument zur Reform von Staat und Verwaltung zunehmend an Bedeutung gewonnen. Insbesondere durch die Entwicklung des Internets haben sich für die Erstellung und die Bereitstellung öffentlicher Dienstleistungen neue Gestaltungsoptionen ergeben. Entsprechend der privatwirtschaftlichen Entwicklung im Bereich eCommerce und eBusiness vollzieht sich auch innerhalb der öffentlichen Verwaltung mit zeitlicher Verzögerung ein analoger Prozess. eGovernment ist hier nur ein Stichwort, welches das Denken und Handeln der öffentlichen Hand beeinflusst. Diese Einflüsse auf die bestehenden Strukturen erfordern eine verstärkte Auseinandersetzung mit den zugrunde liegenden Prozessen, welche auf zukunftsfähigen Systemplattformen abgebildet werden müssen. Daneben spielen auf der anderen Seite auch hausgemachte individuelle Faktoren eine entscheidende Rolle, die zu unterschiedlichen IT-Konzepten und Strategien führen. Neben den Reformbestrebungen im Rahmen des so genannten „Neuen Steuerungsmodells“ mit der Erfordernis einhergehender Informations-und Kommunikationslösungen, sind hier die Bestrebungen zu mehr Eigenständigkeit auf der Basis des Wettbewerbs ein weiterer Aspekt.

Um diese Herausforderungen annehmen zu können, sehen Behörden und Verwaltungen die Notwendigkeit, innovative Technologien und

Systemplattformen einzuführen. Dem gegenüber stehen jedoch historisch

Einleitung 2

gewachsene Systemlandschaften, auf denen sich funktional mächtige Anwendungen befinden, die zentrale Abläufe und Prozesse abbilden und welche langfristig an die gestellten Aufgaben und Anforderungen angepasst wurden. In diese Anpassungsprozesse sind über Jahre hinweg Know-How und Entwicklungskosten eingeflossen.

Die Herausforderung besteht darin, einerseits alte Prozesse zu modernisieren und gegebenenfalls zu automatisieren und neue innovative Prozesse einzuführen sowie andererseits die getätigten Investitionen in die Altsysteme zu schützen.

Auch in Zukunft werden wesentliche Anforderungsänderungen zu erwarten sein. eGovernment befindet sich noch in einem frühen Entwicklungsstadium. Dabei sind die deutschen Behörden auf dem Weg ins Internet. Durch die Initiative der Bundesregierung „Bund Online 2005“ ist die Strategie vorgegeben worden, bis zum Jahr 2005 rund 1.200 Dienstleistungen des Bundes online abwickeln zu

können. ¹ Online einen Anwohnerparkausweis zu bestellen, eine Steuererklärung einzureichen, auf eine elektronische Bauakte zuzugreifen oder gar ein Kfz-Wunschkennzeichen auszusuchen sind keine Träume mehr, sondern Realität geworden. Welchen Weg diese Entwicklungen jedoch nehmen werden und welche Veränderungen daraus resultieren, kann heute noch niemand vorhersagen.

Die öffentliche Verwaltung braucht einerseits eine moderne und flexible Architektur, um den sich ständig wandelnden Anforderungen gerecht zu werden. Andererseits erfordert die Lage der öffentlichen Kassen aus Kostengründen den neuen Anforderungen weitgehend mit der alten Infrastruktur zu begegnen. Diese beiden Aspekte im Reformprozess der öffentlichen Verwaltung werden in dieser Arbeit mit Zukunftssicherheit und Investitionssicherheit umschrieben.

Moderne Integrationsmiddleware bietet technisch neue Lösungsansätze, um vorhandene Anwendungen in Lösungen zum Aufbau einer modernen IT-Architektur einzubinden.

¹ Vgl. Berg, S.: ePublic - Visionen für die Amtsstuben, http://www.contentmanager.de,

10.07.2002, S. 1

Einleitung 3

1.2 Problemdarstellung und Eingrenzung des Themas

Die öffentliche Verwaltung in Deutschland durchlebt derzeit eine Phase der Neuorientierung und Umstrukturierung. In sämtlichen Bundesländern wird teilweise flächendeckend oder zumindest in Teilbereichen an der Einführung einer Kosten- und Leistungsrechnung (KLR) gearbeitet. In einigen Bundesländern ist die Einführung der Kosten- und Leistungsrechnung das finanziell und organisatorisch größte Verwaltungsmodernisierungsprojekt überhaupt.

Jedes Bundesland trifft traditionell bei der Umsetzung von Reformvorhaben unterschiedliche strategische Entscheidungen, die bei der DV-technischen Realisierung dieser Vorhaben zu unterschiedlichen Lösungen führen. Diese verschiedenen Ansätze haben jedoch einschneidende Auswirkungen auf bestehende Systemlandschaften der Länder und Kommunen. Am Beispiel der Finanzsysteme des Landes Rheinland-Pfalz im Allgemeinen und der Einführung der Kosten- und Leistungsrechnung im Besonderen soll die Problematik der Investitions- und Zukunftssicherheit von DV-Anwendungen dargestellt werden.

Diese Diplomarbeit entstand im Rahmen eines internen „Forschungsprojektes“ bei der BGS Systemplanung AG, in dem erarbeitet wurde, welche strategischen IT-Entscheidungen den Behörden und Ministerien des Landes Rheinland-Pfalz empfohlen werden sollten. Im Verlauf dieser Arbeit hat sich das Finanzministerium Rheinland-Pfalz dazu entschlossen, die bestehenden Anwendungen so zu erweitern, dass sie den neuen Anforderungen genügen. Das Problem der Integration und die Frage der Zukunftssicherheit der Systeme ist gerade aus diesem Aspekt heraus nicht zu unterschätzen.

1.3 Vorgehensweise

Die vorliegende Arbeit ist wie folgt gegliedert. Im zweiten Kapitel wird der Begriff „Middleware“ definiert und die Kategorien von Middleware unterschieden und kurz erläutert. Daran anschließend werden Gründe und Nutzen des Einsatzes dieser Technologie ermittelt.

Einleitung 4

Das dritte Kapitel „Enterprise Application Integration“ führt in die Grundlagen ein und gibt einen generellen Überblick über die verschiedenen Ebenen der Integration. Des weiteren werden mögliche Architekturansätze, Einsatzmöglichkeiten sowie benötigte Funktionen des Ansatzes besprochen.

Im vierten Kapitel wird das Thema „Web Services“ behandelt. Nach der Definition von „Web Services“ werden die Bereiche Architektur, Komponenten als auch mögliche Einsatzgebiete dargestellt.

Die eigentliche Problemstellung dieser Arbeit wird im fünften Kapitel bearbeitet. Das Beispielszenario befasst sich mit den Finanzsystemen des Landes Rheinland-Pfalz. Durch die Notwendigkeit der Integration einzelner DV-Anwendungen beim Kunden, soll mittels moderner Integrationsmiddleware die Investitions- und Zukunftssicherheit dieser vorhandenen Anwendungen aufgezeigt werden. Dieses soll anhand der Lösungsvorschläge „Enterprise Application Integration“ und „Web Services“ dargestellt werden.

Abschließend fasst das sechste Kapitel die Ergebnisse dieser Arbeit zusammen und gibt einen Ausblick auf zukünftige Entwicklungen.

Middleware 5

2 Middleware

Der Begriff Middleware entstand im Zuge der Verbreitung der Client-Server-Architekturen. Die Umsetzung der Kommunikation bei diesen verteilten Anwendungen war aufwendig und fehleranfällig. Dies wurde insbesondere dann problematisch, wenn Client und Server auf verschiedenen Hard- und Softwareplattformen installiert wurden. Nicht nur die Hardware war inkompatibel, sondern auch verschiedene Datenformate erschwerten die Verständigung. Zur Lösung dieser Schwierigkeiten war eine Standardisierung der Kommunikationsschnittstellen erforderlich.

Die in jedem Betriebssystem fest verankerten Kommunikationsschnittstellen konnten nicht einfach ausgetauscht werden. Eine Softwareschicht war nötig, die eine ganzheitliche Betrachtung ermöglicht um so die Unabhängigkeit von diesen speziellen Kommunikationsschnittstellen zu erreichen. Diese Schicht wurde durch eine neue Art von Software realisiert. Den Namen Middleware erhielt sie, da sie in der Mitte zwischen Anwendung und Betriebssystem angesiedelt war.

2.1 Definition

Es ist Notwendig den Begriff Middleware zu definieren, da eine Reihe von Ansätzen existieren. Middleware kann als Softwareinfrastruktur zur Über-brückung der Verteilung von Rechnersystemen angesehen werden. ² Stahlknecht definiert den Begriff Middleware als eine systemnahe Software, die als zusätzliche Schicht zwischen Betriebssystem und Anwendungssoftware gelegt

wird. 3

² Vgl. Geihs, K.: Client/Server-Systeme - Grundlagen und Architekturen, Thomson´s Aktuelle

Tutorien, Band 6, Bonn, 1995

³ Vgl. Stahlknecht, P.: Einführung in die Wirtschaftsinformatik, 7. Aufl., Berlin, 1995, S. 94

Middleware 6

Auf das Wesentliche reduziert sich folgende Definition, die im Zusammenhang dieser Arbeit gelten soll:

„Middleware is the slash (/) between Client and server. It is the

glue that lets a client obtain a service from the server.” 4

Middleware ist das Verbindungsglied zwischen dem Client und dem Server. Durch diese Verbindung wird es dem Client ermöglicht, Dienste des Servers in Anspruch zu nehmen.

2.2 Kategorien

Im Laufe der Zeit wurden verschiedene Konzepte und Technologien entwickelt, auf deren Basis Middleware aufbaut. Bei der Vorstellung dieser Konzepte und Technologien in der Literatur wird Middleware in Kategorien eingeteilt. Sowohl die Bezeichnung als auch die Einteilung in diese Kategorien können variieren, jedoch sind nachstehende die Verbreitetsten:

• Datenbankorientierte Middleware

• Funktionsorientierte Middleware

• Transaktionsorientierte Middleware

• Messageorientierte Middleware

• Objektorientierte Middleware

Nachstehend wird eine allgemein gehaltene Einführung in die verschiedenen Kategorien gegeben.

Datenbankorientierte Middleware unterstützt die Integration von Daten, die in verteilten Datenbanken verwaltet werden. Die Hersteller dieser Datenbanken bieten häufig systemspezifische Lösungen an, die im Wesentlichen die Verteilung der eigenen Datenbanksysteme auf unterschiedlichen Plattformen ermöglichen.

Funktionsorientierte Middleware realisiert die Zerlegung und Strukturierung von Programmen auch über Systemgrenzen hinweg.

⁴ Orfali, R., et al., The Essential Client/Server Survival Guide, New York, 1996

Middleware 7

Dies kann bei umfangreichen Anwendungen sinnvoll sein, um die Ausführung auf einem System effizienter zu gestalten. Bei verteilten Anwendungen befinden sich die einzelnen Funktionen der Anwendung bzw. eines Programms nicht lokal auf dem System, auf dem das Programm gestartet wird, sondern sind auf einem oder mehreren Systemen verteilt. Der Aufruf einer auf einem entfernten System installierten Funktion nennt man Remote Procedure Call (RPC).

Transaktionsorientierte Middleware stellt das Transaktionsprinzip in den Mittelpunkt. Transaktionen sind eine Schlüsseltechnologie, um eine zuverlässige Informationsverarbeitung zu gewährleisten. Das Konzept der Transaktion wird seit langem erfolgreich in Datenbanken eingesetzt. In den letzten Jahren wurde das Konzept der Transaktion auch zunehmend bei verteilten Systemen angewendet. Es hat das Ziel, die verteilte Verarbeitung eines Programms zu strukturieren und die Komplexität der Anwendung besser zu kontrollieren. Dazu werden die Verbindungen von den Clients zu einem Server von einem Monitor überwacht. Er fügt die benötigten Transaktionseigenschaften den Verbindungen zu.

Messageorientierte Middleware basiert auf der Idee, das Anwendungen miteinander kommunizieren, indem sie Nachrichten austauschen. Eine Nachricht ist eine Folge von Daten die eine gewisse Bedeutung haben. Daneben können Nachrichten auch noch Kontrolldaten enthalten.

Objektorientierte Middleware setzt für die Kommunikation zwischen Anwendungen kleine Programme ein, die standardisierte Schnittstellen und Protokolle nutzen. Sie können, da sie standardisiert sind und die gleichen Kommunikationsprotokolle verwenden, unabhängig vom vorhandenen Betriebssystem Informationen austauschen.

2.3 Einsatzgründe

Moderne Integrationsmiddleware gewinnt zur Zeit immer mehr an Bedeutung. Einer der Gründe ist z.B. der zunehmende Drang nach Unternehmensfusionen und der damit verbundene Zwang zur Integration heterogener IT-Landschaften.

Middleware 8

Dieser Trend zur Globalisierung bedeutet, dass jedes Unternehmen mit jedem kommunizieren möchte und daraus resultierend z.B. Bestellungen oder Aufträge weltweit mittels automatisierter Geschäftsprozesse abgewickelt werden sollen. Verschiedene Unternehmensstrategien setzen eine umfassende Integration der einzelnen IT-Systeme in einer Organisation voraus. Innerhalb von Organisationen kann der Einsatz einer Middlewaretechnologie dann sinnvoll werden, wenn ein vorhandenes System durch ein neues ersetzt oder einfach nur ein neues System eingeführt wird. Man denke nur an aktuelle Strategien wie die Einführung und Abbildung einer Balanced Score Card, einer betriebwirtschaftlichen Standardsoftware oder eines Supply Chain Managements. Eine neue Anwendung soll möglicherweise mit einer Vielzahl von vorhandenen Systemen verbunden werden. Das bedeutet, dass eine große Anzahl von Schnittstellen nötig sind, damit mit der neu eingeführten Anwendung produktiv gearbeitet werden kann.

Auch die Einführung eines Data Warehouse in einem Unternehmen kann den Einsatz von Middleware erforderlich machen. Viele Unternehmensführungen verlangen im steigenden Wettbewerb immer mehr unternehmensinterne Informationen. Im Zuge der zunehmenden Automation und des Workflows nimmt auch das Bedürfnis nach umfassenden Informationen zu. So genannte „Management Informationssysteme“ sollen der Unternehmensführung und dem Controlling wichtige Daten anschaulich aufbereiten. Diese Daten müssen jedoch häufig aus verschiedenen Systemen und Datenbanken zusammengetragen werden.

Ein weiteres Einsatzgebiet für Middlewarelösungen kann das eBusiness sein, falls Unternehmen und Organisationen z.B. im Internet Handel betreiben und damit ihre Geschäftsprozesse auch über Unternehmensgrenzen hinweg abbilden möchten.

2.4 Nutzen

Es stellt sich die Frage, in welchem Maße Organisationen von der Nutzung moderner Integrationsmiddleware profitieren. Folgende Argumente stechen bei dem Einsatz von Middleware hervor: Integration, Automatisierung und Flexibilität. Die Integration von Anwendungen bedeutet verbesserte Kommunikationsmöglichkeiten auf der Anwendungsebene.

Middleware 9

Die interne Kommunikation, wie auch die mit Partnern außerhalb der Organisation, wird durch die Nutzung von Middleware-Anwendungen ohne manuelle Eingriffe, d.h. ohne Medienbrüche, ermöglicht. Diese Optimierung bringt Zeitgewinne und damit Kosteneffekte mit sich.

Automatisierung bedeutet hingegen das Reengineering der Geschäftsprozesse mit dem Ziel, z.B. die Durchlaufzeiten einer Bestellung ohne Medienbrüche und möglichst ohne manuelle Eingriffe zu ermöglichen. Der Haupteffekt der Automatisierung ist das damit verbundene Kostensenkungspotential. Durch die Minimierung der manuellen Eingriffe bei Geschäftprozessen erreichen Unternehmen und Organisationen Zeitgewinne, schnelle Reaktion auf Änderungen sowie eine gewisse Flexibilität und damit einen besseren Service bzgl. der Leistungsübergabe.

Durch den Einsatz von Integrationsmiddleware werden Organisationen in die Lage versetzt, flexibel auf Marktveränderungen zu reagieren. Auf zukünftige Erweiterungen des Softwaresystems kann genauso flexibel geantwortet werden wie auf die schrittweise Anbindung von bereits vorhandenen Anwendungen.

Neben den bereits genannten Aspekten gibt es zwei zentrale Beweggründe, moderne integrative Middleware einzusetzen. Middlewarelösungen stellen einen Investitionsschutz dar. Die grundlegende Integration bereits vorhandener Anwendungen oder sogenannter „Legacy“ - Anwendungen wird ermöglicht. Diese Altanwendungen erhalten durch die Integration in die neue Architektur einen längeren Lebenszyklus. Da sie durch moderne Integrationstechniken an neue Herausforderungen angepasst werden können, um sie z.B. eBusiness tauglich zu machen, spricht man in diesem Zusammenhang auch von der Zukunftssicherheit der Anwendungen. So werden bereits getätigte Investitionen geschützt und kostenintensive Weiterentwicklungen oder gar Neuentwicklungen auf der Basis dieser Altlasten können verschoben oder verworfen werden.

Enterprise Application Integration 10

3 Enterprise Application Integration

Globalisierung, der stetig wachsende Wettbewerb und der zunehmende Kostendruck sind nur einige Gründe, die Organisationen und Unternehmen dazu veranlasst haben, IT-Lösungen umzusetzen, die verschiedene Datenquellen zusammenführen um somit eine gemeinsame Systemplattform zu schaffen. Diese Plattformen bilden die Grundlage für die Integration von verschiedensten heterogenen Systemen. Enterprise Application Integration bedeutet „Integration von Anwendungen“ und ist eine Software-Lösung die es ermöglicht,

Anwendungen eines Unternehmens zu integrieren. ⁵ EAI ist Voraussetzung für eine erfolgreiche Integrationsstrategie von vorhandenen Softwaresystemen innerhalb und außerhalb der Grenzen eines Unternehmens.

Geschäftspartner

Enterprise Application Integration ist ein neuer Typ von Middleware, der über die herkömmlichen Einsatzbereiche „klassischer“ Middleware hinausgeht. Klassische Middleware-Produkte beschäftigen sich mit der Integration auf Datenebene. Daten kommunizieren miteinander, indem diese jedoch nur gegenseitig Informationen

⁵ Vgl. Keller, W.: Enterprise Application Integration - Erfahrungen aus der Praxis, 1. Aufl.,

Heidelberg, 2002, S. 5

Enterprise Application Integration 11

austauschen, wobei die Semantik der Daten außer Acht gelassen wird. ⁶ EAI-Systeme dagegen sorgen für den Transport von Daten, gleichen unterschiedliche Datenstrukturen ab und ermöglichen, dass Informationen in den richtigen Anwendungen zur Verfügung stehen.

David Linthicum beschreibt die Unterschiede zwischen Enterprise Application

Integration und klassischer Middleware: 7

• EAI focuses on the integration of both business-level processes and data,

whereas the traditional middleware approach is data oriented.

• EAI includes the notion of reuse as well as distribution of business

processes and data.

• EAI allows users who understand very little about the details of the

applications to integrate the applications.

In der Vergangenheit wurde Middleware dazu benutzt, um offene Anwendungen zu erstellen. Diese Anwendungen wurden als Hilfsmittel zur Unterstützung von betriebswirtschaftlichen Anforderungen eingesetzt. Beispiele hierfür sind Buchungssysteme der Fluggesellschaften und Abrechnungssysteme von Telekommunikationsunternehmen. Anwendungserfahrungen wurden unter anderem auch in Kliniken gemacht. In der Kölner Universitätsklinik fallen neben Daten aus betriebswirtschaftlich-administrativen Anwendungen auch Daten aus medizinischen Anwendungen an. Hier müssen beispielsweise für Untersuchungen von Blutproben Patientenstammdaten aus einem SAP R/3-Modul in einer

Anwendung des Labors zur Verfügung stehen. ⁸ Während Middleware Applikationen technisch miteinander verbindet, so dass Daten ausgetauscht werden können, integriert ein EAI-System Applikationen sozusagen wirtschaftlich miteinander, um so betriebwirtschaftliche Abläufe quer durch das Unternehmen zu ermöglichen. Ebenso fällt eine EDI-Verbindung (Electronic Data Interchange) mit Geschäftspartnern unter das EAI-Konzept. Während herkömmliche Integration Computersysteme nur technisch miteinander verbunden hat, ist EAI

⁶ Vgl. Buhl, L., et al.: Marktstudie - Softwaresysteme für Enterprise Application Integration, 1.

Aufl., Paderborn, 2001, S. 5

⁷ Vgl. Linthicum, D.: Enterprise Application Integration, Boston, 2000, S. 5

⁸ Vgl. Buhl, L, a.a.O., S. 7

Enterprise Application Integration 12

mehr eine ganzheitliche wirtschaftliche Integration aller modernen IT-Elemente in einem Unternehmen.

Unter Analysten werden EAI-Systeme in Anlehnung und zur Unterscheidung zur

Middleware auch Prozessware oder Businessware genannt. ⁹ Mit Prozess ist der Geschäftsprozess gemeint. Diesbezüglich wird auch auf eine sogenannte „Business Logic“ abgestellt, die betriebswirtschaftliche Vorgänge generieren kann, losgelöst vom eigentlichen Workflow, der durch den Datentransport entsteht. Durch unterschiedliche Sichtweisen entstehen auch verschiedene Ebenen, auf die später noch intensiver eingegangen wird. Einmal gibt es eine technische Ebene, in der Daten von einem System in das andere transferiert werden. Anderseits ist eine betriebwirtschaftliche Schicht vorhanden, die Prozessebene, in der die Informationsflüsse nicht datentechnisch gesehen werden, sondern als wirtschaftliche Geschäftsprozesse. Des Weiteren wird eine Objektebene definiert. Ein EAI-System muss nicht nur die technisch und objektbezogene Verbindung realisieren sondern auch einer wirtschaftlichen Sichtweise gerecht werden.

Nach einer Studie des European Information Technology Observatory versuchen

Organisationen folgende Herausforderungen dank EAI zu bewältigen: 10

• Integration of internal packaged applications with other internal

packaged applications (e.g., the linking of a packaged CRM solution

with a packaged Enterprise Resource Management solution).

• Integration of internal packaged applications with internal legacy

applications (e.g., the linking of a packaged CRM application with a

legacy, home-grown customer database).

• Integration of internal packaged and legacy applications with internal

packaged and legacy applications (e.g., the linking of an internal SCM

application with an external inventory management system).

⁹ Vgl. Nussdorfer, R.: Von Enterprise Application Integration zu Collaborative Business

Integration, Velbert, 2002, S. 3 ff.

¹⁰ Vgl. European Information Technology Observatory 2002, 10. Aufl., Frankfurt, 2002, S. 37