Lade Inhalt...

Investitionssicherheit und Zukunftssicherheit von DV-Anwendungen mittels moderner Integrationsmiddleware am Beispiel der Finanzsysteme des Landes Rheinland Pfalz

Diplomarbeit 2002 87 Seiten

BWL - Sonstiges

Leseprobe

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

1. Einleitung
1.1 Motivation
1.2 Problemdarstellung und Eingrenzung des Themas
1.3 Vorgehensweise

2. Middleware
2.1 Definition
2.2 Kategorien
2.3 Einsatzgründe
2.4 Nutzen

3. Enterprise Application Integration
3.1 Definition
3.2 Integrationsebenenen
3.2.1 Integration auf Datenebene
3.2.2 Integration auf Objektebene
3.2.3 Integration auf Prozessebene
3.3 Architektur
3.3.1 Komponenten
3.3.2 Message Broker
3.3.3 Integration Server
3.4 Funktionen
3.5 Einsatzmöglichkeiten
3.5.1 Application-to-Application (A2A)
3.5.2 Administration-to-Administration (A2A)
3.5.3 Business-to-Business (B2B)

4 Web Services
4.1 Definition
4.2 Architektur
4.2.1 Serviceanbieter
4.2.2 Servicenachfrager
4.2.3 Serviceregistrierung
4.3 Komponenten
4.3.1 Hypertext Transfer Protocol (HTTP)
4.3.2 Extensible Markup Language (XML)
4.3.3 Simple Object Access Protocol (SOAP)
4.3.4 Web Service Description Language (WSDL)
4.3.5 Universal Description Discovery Integration (UDDI)
4.4 Einsatzmöglichkeiten
4.4.1 Application-to-Application (A2A)
4.4.2 Business-to-Business (B2B)
4.4.3 Consumer-to-Administration (C2A)

5 Szenario
5.1 Haushalts- und Verwaltungsreform
5.2 Situation in Hessen
5.3 Situation Rheinland-Pfalz
5.3.1 Kameralistik und Doppik
5.3.2 Finanzsysteme des Landes Rheinland-Pfalz
5.3.3 Standardsoftware SAP R/
5.4 Ist-Zustand Integrationsarchitektur
5.5 Lösungsansatz Enterprise Application Integration
5.6 Lösungsansatz Web Services

6 Fazit

Glossar

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

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

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

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.

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

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.

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.

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.

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.

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.

Abbildung in dieser Leseprobe nicht enthalten

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

Abbildung in dieser Leseprobe nicht enthalten

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

Das heißt, dass EAI unterschiedliche Anwendungen in die Lage versetzt, geschäftsrelevante Daten so miteinander auszutauschen, dass alle am Austausch beteiligten Anwendungen ein gleiches Verständnis der Daten haben.

Laut Richard Nussdorfer, Geschäftsführer der CSA Consulting, steckt in dem Dreiklang EAI alles Wesentliche:

„Aus isolierten Anwendungen werden integrierte Geschäftsprozesse und die dazu gehörende IT-Lösung heißt EAI was nichts anderes als Enterprise Application Integration bedeutet. In diesem genialen Wort sind alle 3 Begriffe enthalten auf die es ankommt: Unternehmensweit, Anwendungen und Integration.“14

Während die Gartner Group, ein Marktforschungsunternehmen aus den USA, zum Thema EAI schlicht und einfach sagt:

„Application integration means making independently designed systems work together.”15

Fasst man die obigen Definitionen zusammen, geht es bei EAI darum, systemübergreifende Geschäftsprozesse mit Hilfe einer geeigneten Technik so abzubilden, dass die am Geschäftsprozess beteiligten unterschiedlichen Systeme in der Lage sind, prozessrelevante Daten miteinander in geeigneter Form auszutauschen und dabei ein gleiches Verständnis dieser Daten zu haben.

Im Kontext soll folgende Definition gelten:

„EAI ist die Integration heterogener Software-Welten unter Nutzung modernster Integrationsmiddleware mit dem Ziel Geschäftsprozesse systemübergreifend abzubilden.“

3.2 Integrationsebenenen

Möchten Unternehmen bzw. Organisationen ihre bestehenden Geschäftsprozesse systemübergreifend in einer heterogenen Systemlandschaft abbilden, reicht es nicht aus, dass die vorhandenen Systeme Daten untereinander austauschen, sondern es müssen auch Geschäftsprozesse abgebildet werden können.16 Dies bedeutet, dass eine Aktion in einem System mehrere Aktionen in anderen Systemen nach sich ziehen kann, die zeitgleich oder in einer bestimmten Reihenfolge ablaufen müssen. Somit sollte neben der Integration auf Datenebene und Objektebene eine Integration auf Prozessebene stattfinden. Durch diese unterschiedlichen Sichtweisen sollten die verschiedenen Ebenen der Integration dargestellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Ebenen der Integration

3.2.1 Integration auf Datenebene

Die Integration auf der Datenebene ist die Grundlage der semantischen Integration und beinhaltet das Verbinden der Anwendungen. Generell müssen Anwendungen in der Lage sein „zu kommunizieren“, um diese Integration zu erreichen. Gerade bei eigenentwickelter Software ist oftmals ein Versenden von Daten an andere

Anwendungen nicht vorgesehen. Die Integration auf Datenebene ermöglicht eine Kommunikation in dem Sinne, dass eine Anwendung Daten empfängt, die von einer anderen Anwendung gesendet wurden. Jedoch wird hierbei bewertet, was gesendet und empfangen wird. Eine einfache Datenübertragung genügt dem Anspruch der semantischen Integration noch nicht.17

3.2.2 Integration auf Objektebene

Integration auf Objektebene baut auf der Integration auf Datenebene auf und übersetzt den Wortschatz der verschiedenen Anwendungen. Die semantische Integration ist hierdurch noch nicht erreicht, da nicht alle Daten „eins zu eins“ übersetzt werden können. Anwendungen verfügen selten über den gleichen Wortschatz und können aus diesem Grund die Vokabeln nicht in dem Maße umsetzen, wie sie ursprünglich von der sendenden Anwendung gemeint waren. Dieses „Verstehen und Umsetzen“ setzt die Einbeziehung der Bedeutung der Daten voraus. Diese Einbeziehung wird auf der nächsten Integrationsebene umgesetz.18

3.2.3 Integration auf Prozessebene

Um die Semantik zu berücksichtigen, ist eine Integration auf Prozessebene notwendig. In diesem Zusammenhang ist der aktuelle und der vorherige Zustand einer Anwendung ein elementares Kriterium. Dieses kann dazu beitragen, dass Daten verstanden und richtig umgesetzt werden. Um diesen Zusammenhang zu verdeutlichen, stelle man sich folgende Situation vor:

Ein Unternehmen hatte in der Vergangenheit diverse Probleme mit seinen Debitoren. Unter anderem sind Verbindlichkeiten unregelmäßig beglichen worden. Um dieses Problem in Zukunft auszuschließen, wurde eine Abfrage und eine Sperrfunktion in die EDV eingefügt: Wenn der Rechnungsbetrag der letzten Bestellung des Kunden nicht innerhalb von 60 Tagen auf dem Debitorenkonto eingegangen ist, kann eine erneute Bestellung nicht angenommen werden.

Auf diese Weise wird ein neuer Geschäftsprozess erst angestoßen, wenn ein bestimmter Punkt in einem vorhergehenden Geschäftsprozess aktiviert wurde.19

3.3 Architektur

Allgemeingültige und standardisierte Muster zur Integration von Applikationen wird es nicht geben. Jede Architektur und jedes Integrationskonzept ist abhängig von dem Aufbau der zu verbindenden Applikationen.

Je nachdem wie „anbindungsfreudig“ die Anwendungen sind, desto einfacher kann ein EAI-System die Integration durchführen und optimieren. Lässt eine Anwendung beispielsweise nur den Im- und Export von Daten zu, kann das EAI- System zur Umsetzung eines betrieblichen Prozesses auch nur Daten senden bzw. empfangen. Ist es dagegen möglich, dass in der Anwendung Abläufe von außen gestartet werden können, ist auch das EAI-System in der Lage, komplexe Geschäftsprozesse zu generieren.

3.3.1 Komponenten

EAI-Systeme stellen vorgefertigte standardisierte Verbindungsmodule bereit, um Applikationen nach dem jeweiligen Architekturkonzept untereinander bzw. miteinander zu verknüpfen. Diese Verbindungen werden Adapter oder Konnektoren genannt. EAI-Systeme können Verbindungen zu den einzelnen Applikationen verschieden aufbauen. So können sie beispielsweise eine Verbindung von einer Applikation zu einer anderen direkt aufbauen oder immer nur Verbindungen zu sich selbst zulassen. Ferner können Daten vom Format der Anwendung A in das Format der Anwendung B umgewandelt werden oder erst grundsätzlich alle Daten in ein allgemeingültiges Format konvertiert werden etc.. Des Weiteren werden Workflowmanagementsysteme dazu genutzt, um betriebwirtschaftliche Geschäftsprozesse abzubilden und generieren zu können.

Adapter: Jedes EAI-System sollte eine Reihe von standardisierten Adaptern bieten. Um eine marktübliche Integration zu erleichtern und den individuellen

Programmieraufwand zu minimieren, benötigt ein EAI-System beispielsweise zur Anbindung an Standardapplikationen schon vorgefertigte Lösungen. Standard- applikationen sind z.B. ERP20-Systeme der Unternehmen SAP, Peoplesoft oder Siebel. Die Integration solcher Systeme sollte ein EAI-System durch vorgefertigte Module unterstützen. Die Module werden Konnektoren, Adapter oder einfach Schnittstellen genannt.

Des Weiteren sollte ein EAI-System in der Lage sein, Programme, die unternehmensspezifisch oder von Nischenanbietern erstellt wurden, zu integrieren. Dazu sind oft sogenannte Standardadapter vorhanden, die von den jeweiligen Applikationen gefüllt oder u.U. noch angepasst werden müssen. Je umfangreicher standardisierte Adapter in einem EAI-System vorhanden sind, desto höher ist die Anzahl der Applikationen die eingebunden werden können und desto komplexere Integrationen können umgesetzt werden.

Konverter: Ein zentrales Architekturmerkmal eines EAI-Systems ist der Datenkonverter. Um eine Applikation mit einer anderen zu verbinden, müssen die Daten oft von einem in ein anderes Format umgewandelt werden.

Ein Konverter ist in der Lage, Daten in einer bestimmten Form zu lesen und in einer anderen Form wieder auszugeben. Daten können nicht nur von einer Struktur in eine andere umgewandelt werden, sondern können von Konvertern auch manipuliert werden. Das heißt, sie können beispielsweise Datenformate ändern, Berechnungen mit den Daten ausführen oder einfach nur die Daten beim abbilden aufsplitten, zusammenführen oder abschneiden. Leistungsstarke Konverter können mehere Schnittstellen paralell bedienen um so z.B. Daten in mehrere Nachrichten gleichzeitig umzuwandeln.

Workflowmanagementsysteme: Ein weiteres Architekturmerkmal eines EAI- Systems kann ein Workflowmanagementsystem sein. Abgesehen von den Datenflüssen die entstehen, wenn Daten von einer Anwendung in die nächste und von der wieder in eine Dritte transferiert werden, gibt es EAI-Systeme, die unabhängig von der reinen Datenintegration eine BusinessLogic erzeugen können.

[...]


1 Vgl. Berg, S.: ePublic – Visionen für die Amtsstuben, http://www.contentmanager.de, 10.07.2002, S. 1

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

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

5 Vgl. Keller, W.: Enterprise Application Integration – Erfahrungen aus der Praxis, 1. Aufl., Heidelberg, 2002, S. 5

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

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

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

14 Nussdorfer, R., Von Enterprise Application Integration zu Collaborative Business Integration, S.3

15 Vgl. Altman, R. et al.: Middleware – The Glue for Modern Applications, http:www.gartner.com, 10.08.2002

16 Sailer, M.: Anforderungen, Entwicklungen und Trends im Bereich Enterprise Application Integration, White Paper, http://www.sercon.de, 05.08.2002

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

18 Ebd. S. 7

19 Ebd. S. 7

20 Enterprise Ressource Planning

Details

Seiten
87
Jahr
2002
ISBN (eBook)
9783638190930
Dateigröße
685 KB
Sprache
Deutsch
Katalognummer
v13426
Institution / Hochschule
Hochschule Niederrhein in Mönchengladbach – Wirtschaft
Note
Gut
Schlagworte
Investitionssicherheit Zukunftssicherheit DV-Anwendungen Integrationsmiddleware Beispiel Finanzsysteme Landes Rheinland Pfalz

Autor

Teilen

Zurück

Titel: Investitionssicherheit und Zukunftssicherheit von DV-Anwendungen mittels moderner Integrationsmiddleware am Beispiel der Finanzsysteme des Landes Rheinland Pfalz