Lade Inhalt...

Investitionssicherheit und Zukunftssicherheit von DV-Anwendungen mittels moderner Integrationsmiddleware

Am Beispiel der Finanzsysteme Rheinland-Pfalz

©2002 Diplomarbeit 89 Seiten

Zusammenfassung

Inhaltsangabe:Zusammenfassung:
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. Im 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 […]

Leseprobe

Inhaltsverzeichnis


ID 6790
Nühlen, Holger: Investitionssicherheit und Zukunftssicherheit von DV-Anwendungen
mittels moderner Integrationsmiddleware - Am Beispiel der Finanzsysteme Rheinland-
Pfalz
Hamburg: Diplomica GmbH, 2003
Zugl.: Krefeld, Fachhochschule, Diplomarbeit, 2002
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany

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
Abkürzungsverzeichnis
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
Integriertes Rheinland-Pfälzisches Mittelbewirtschaftungs-
und Abrechnungssystem
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
V
Abbildungsverzeichnis
Abbildung 1: Enterprise Application Integration ...10
Abbildung 2: Business process integration in european businesses...13
Abbildung 3: Ebenen der Integration ...15
Abbildung 4: Hub-and-Spoke Ansatz...19
Abbildung 5: Bus Ansatz...20
Abbildung 6: Punkt-zu-Punkt Ansatz...21
Abbildung 7: Formen von EAI...27
Abbildung 8: Web Service Architektur - Rollen und Operationen ...36
Abbildung 9: Bestellung als XML-Dokument ...42
Abbildung 10: Ablauf einer SOAP-Nachricht...45
Abbildung 11: Struktur einer SOAP-Nachricht...46
Abbildung 12: Gemeinsame Definition eines Web Service in WSDL...48
Abbildung 13: Globales UDDI-Verzeichnis ...50
Abbildung 14: SAP UDDI Business Registry...50
Abbildung 15: Modularer Aufbau des R/3-Systems ...63
Abbildung 16: Schnittstellen-Chaos ...67
Abbildung 17: EAI-Ansatz...69
Abbildung 18: Web-Service-Ansatz...71

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 Ent-
wicklung 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.
1
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.
1
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, Einsatz-
mö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 Kommunikations-
schnittstellen 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.
2
Stahlknecht
definiert den Begriff Middleware als eine systemnahe Software, die als
zusätzliche Schicht zwischen Betriebssystem und Anwendungssoftware gelegt
wird.
3
2
Vgl. Geihs, K.: Client/Server-Systeme ­ Grundlagen und Architekturen, Thomson´s Aktuelle
Tutorien, Band 6, Bonn, 1995
3
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.
4
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 Standard-
software 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.
5
EAI ist Voraussetzung für
eine erfolgreiche Integrationsstrategie von vorhandenen Softwaresystemen
innerhalb und außerhalb der Grenzen eines Unternehmens.
Enterprise
Application
Integration
Data
Ware
house
Leg
acy
S
C
M
CR
M
ERP
eProcurement
Geschäftspartner
Kunden
Internet
Marktplätze
Lieferanten
Abbildung 1: Enterprise Application Integration
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
5
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.
6
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.
8
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
6
Vgl. Buhl, L., et al.: Marktstudie ­ Softwaresysteme für Enterprise Application Integration, 1.
Aufl., Paderborn, 2001, S. 5
7
Vgl. Linthicum, D.: Enterprise Application Integration, Boston, 2000, S. 5
8
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.
9
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).
9
Vgl. Nussdorfer, R.: Von Enterprise Application Integration zu Collaborative Business
Integration, Velbert, 2002, S. 3 ff.
10
Vgl. European Information Technology Observatory 2002, 10. Aufl., Frankfurt, 2002, S. 37

Enterprise Application Integration
13
Supply Chain Management (SCM)
Enterprise Application Integration (EAI)
ERP/
Enterprise
Resource
Management
Applications
CRM
Legacy
eCommerce
eP
ro
curem
ent
B2B
eBusiness
Suppliers
Customers
Abbildung 2: Business process integration in european businesses
3.1 Definition
Enterprise Application Integration ist in den USA entstanden, wo die
Heterogenität in den IT-Strukturen besonders umfangreich ist.
11
Eine erste
Definition in der amerikanischen wissenschaftlichen Literatur lautet:
,,EAI is the unrestricted sharing of data and business processes
among any connected applications and data sources in the
enterprise."
12
Bei dieser Definition sind die zentralen Aussagen die Integration der Daten und
der Geschäftsprozesse. Das Forschungs- und Beratungsunternehmen Ovum
definiert den Begriff EAI wie folgt:
,,EAI is the combination of technologies and processes that
enable custom-built and/or packaged business applications to
exchange business-level informations in formats and contexts
that each understands."
13
11
Vgl. Linthicum, D., S. 6 ff.
12
Vgl. Linthicum, D., S. 3
13
Vgl. Ovum: Enterprise Application Integration, http://www.ovum.com, 14.07.2002

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2002
ISBN (eBook)
9783832467906
ISBN (Paperback)
9783838667904
DOI
10.3239/9783832467906
Dateigröße
638 KB
Sprache
Deutsch
Institution / Hochschule
Hochschule Niederrhein in Krefeld – Wirtschaft
Erscheinungsdatum
2003 (Mai)
Note
2,0
Schlagworte
enterprise application integration e-government services standardsoftware kostenrechnung
Zurück

Titel: Investitionssicherheit und Zukunftssicherheit von DV-Anwendungen mittels moderner Integrationsmiddleware
book preview page numper 1
book preview page numper 2
book preview page numper 3
book preview page numper 4
book preview page numper 5
book preview page numper 6
book preview page numper 7
book preview page numper 8
book preview page numper 9
book preview page numper 10
book preview page numper 11
book preview page numper 12
book preview page numper 13
book preview page numper 14
book preview page numper 15
book preview page numper 16
book preview page numper 17
book preview page numper 18
book preview page numper 19
89 Seiten
Cookie-Einstellungen