Entwicklungstendenzen bei Application Integration

Inhaltsverzeichnis

1 Ausgangssituation

2 Enterprise Application Integration
2.1 Punkt-zu-Punkt-Integration
2.3 Bus-Architektur
2.4 Architekturebenen
2.4.1 Integrationsmodell
2.4.2 Kommunikationsmodell
2.4.3 Integrationsmechanismen
2.4.4 Middleware
2.5 Webservices
2.5.1 Basistechnologie
2.5.2 Webservice Architektur
2.5.3 Datentransformation

3 Tendenzen
3.1 Portale
3.2 Serviceorientierte Architektur (SOA)

4 Fazit

5 Literaturverzeichnis

1 Ausgangssituation

In der heutigen Unternehmenswelt ist eine Vielzahl von unterschiedlichen Anwendungssystemen (AWS) im Einsatz. Bereits innerhalb der Unternehmensgrenzen einer Organisation werden oft für die einzelnen Funktionsbereiche verschiedene AWS verwendet. Diese Vielfalt der Systeme ist in den meisten Fällen historisch gewachsen oder durch Fusionen entstanden.

Die eingesetzten Systeme sind allerdings i.d.R. nicht für die Zusammenarbeit mit anderen Systemen ausgelegt und verfügen daher kaum über (standardisierte) Schnittstellen zum Austausch der Daten. „Als Legacy-Systeme gelten alle Softwaresysteme, die mit einer früheren Softwaretechnologie als die gegenwärtige implementiert wurden.“^[1] Ein Austausch dieser Legacy-Systeme durch moderne Systeme mit offenen Kommunikationsmöglichkeiten, ist meistens nicht möglich, da es sich oftmals um geschäftskritische Anwendungen handelt. Ein Ausfall dieser Systeme würde die Zukunft des Unternehmens bedrohen und stellt daher ein zu großes Risiko dar.

Im Sinne der Vorstellung durchgängiger IT-gestützter Geschäftsprozesse, die teilweise unternehmensübergreifend erfolgen sollen, ist dies uneffektiv. Es besteht die Gefahr von redundanter Datenhaltung, Medienbrüchen und im schlimmsten Fall sogar von Informationsverlusten. Inkonsistenzen in den Datenbeständen der einzelnen AWS sind vorprogrammiert. Dies kann bereits durch einen so simplen Geschäftsvorgang wie einer Adressänderung passieren. Außerdem können dem Unternehmen erweiterte Möglichkeiten wie Cross-Selling-Aktivitäten oder eine einheitliche Kundenansprache entgehen.

„Die Hauptaufgabe einer Integrationslösung innerhalb einer Unternehmung ist die Abbildung von Geschäftsprozessen, die nur in einem Zusammenspiel mehrerer Anwendungssysteme automatisiert werden können.“^[2]

2 Enterprise Application Integration

„Der Begriff wurde geprägt durch das Bemühen, viele Anwendungen, die nicht für eine Zusammenarbeit entworfen wurden und auch nur Teilaufgaben von Geschäftsprozessen abdecken, dazu zu bringen, in einheitlichen Geschäftsprozessen zusammenzuspielen“.^[3] „Mit den Mitteln der Integrationstechnologie werden bestehende Datenbanken, Transaktionen und Programme hinter einer Zugriffsschale gekapselt ... “^[4]. Dies soll nach Möglichkeit so erfolgen, dass der Anwender nicht bemerkt, dass während des Prozessablaufs verschiedene AWS zum Einsatz kommen. Die Hauptaufgabe ist der automatisierte Datenaustausch zwischen den beteiligten Systemen.

Generell gilt bei der Vernetzung von AWS, dass semantisch identische Daten in jeweils spezifischen Datenstrukturen abgelegt werden. Daher sind sog. Mapping Tabellen zu pflegen, um eine korrekte Weiterverarbeitung der Daten im jeweiligen Zielsystem zu ermöglichen.

Die Vorteile, die durch EAI entstehen können liegen sowohl auf der Seite des Unternehmens als auch auf Kundenseite. Das Unternehmen ist in der Lage eine Steigerung der Effektivität und Effizienz seiner Geschäftsprozesse zu erzielen. Konkrete Maßnahme dazu sind Beseitigung von Medienbrüchen und Redundanzen, Prozessoptimierung und eine sinkende Anzahl manueller Tätigkeiten. Langfristig steigt dadurch auch die Wettbewerbsfähigkeit des Unternehmens. Durch die effizienteren Prozessabläufe kann die Kundenzufriedenheit steigen, da schneller auf Anfragen reagiert werden kann oder die Qualität der Ware steigt.

Zunächst werden nun die verschiedenen technischen Möglichkeiten der EAI erläutert.

2.1 Punkt-zu-Punkt-Integration

Auf der Punkt-zu-Punkt (P2P) Integrationsstufe erfolgt die Kopplung durch eine direkte Kommunikationsverbindung zwischen den beiden zu Verbindenden AWS.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Punkt-zu-Punkt-Integration von Anwendungssystemen Quelle: Eigene Darstellung

Die Anzahl der benötigten Schnittstellen steigt mit zunehmender Anzahl an AWS linear nach der Formel n*(n-1) an. Dies bedeutet, dass sich der Aufwand zur Einrichtung und anschließenden Wartung der Schnittstellen mit jedem neuen AWS erhöht.

Bereits in dieser relativ kleinen Umgebung mit 4 AWS werden zur vollständigen Integration 12 Schnittstellen benötigt. Da es sich bei jeder Schnittstelle i.d.R. um individuell angepasste Verbindungen handelt ist die Implementierung mit hohem Aufwand verbunden. Erfolgt ein Austausch eines AWS, müssen mit einem Schlag für Schnittstellenanpassungen in den verbliebenen drei AWS durchgeführt werden.

Die Anfangskosten einer P2P-Integration sind relativ gering. Es fallen nur die ohnehin zu zahlenden Lizenzkosten für die Anwendungssoftware und die Einrichtung der Schnittstellen in den jeweiligen AWS an. Aus den o.g. Gründen sind allerdings Betrieb und Wartung von hohen Folgekosten begleitet.

2.2 Hub-and-Spoke-Arch itecture (HaS)

Ins Deutsche übersetzt bedeutet der Begriff Nabe-und-Speichen-Architektur und entstand in Anlehnung an den Aufbau des Fahrrad-Reifens. Von der zentralen Stelle – der Nabe – sind sämtliche angeschlossenen AWS über definierte Wege – die Speichen – zu erreichen.

Um der hohen Anzahl der Schnittstellen, und dem daraus entstehendem hohen Wartungsaufwand, als bedeutendem Nachteil der P2P-Integration zu begegnen wurde die HaS entwickelt. Um eine plattform- und systemübergreifende Integration zu ermöglichen wird eine Kommunikationsebene in Form einer gemeinsamen, zentralen Middleware eingesetzt. Die Anzahl der benötigten Schnittstellen sowie der Aufwand für Wartung und Betrieb soll dadurch minimiert werden.

Jedes anzuschließende AWS benötigt lediglich zwei Schnittstellen (Hin- und Rückweg) zum zentralen EAI Broker. Dieser wird auch als Middleware bezeichnet. Der EAI Broker agiert als Kommunikationszentrale und steuert den Datenaustausch zwischen den AWS.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: HaS zur EAI-Integration von Anwendungssystemen Quelle: Eigene Darstellung Der EAI Broker entspricht in der HaS der Nabe und die zu integrierenden AWS sind als die Endstellen der Speichen zu verstehen.

Wichtige Aufgabe des EAI Brokers ist ebenfalls die Datentransformation in die Syntax der entsprechenden Quell- und Zielsysteme. Um dies zu erreichen ist es sinnvoll, eine systemunabhängige Datenstruktur, ein sog. Basisschema, zu schaffen. Für jedes anzuschließende AWS ist nun lediglich eine einmalige Mapping-Tabelle zu diesem Basisschema zu definieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Mapping von Datenstrukturen zu einen Basisschema Quelle: Gräff S.26

Die Anzahl der benötigen Schnittstellen sinkt also auf 2n. Damit werden in unserem Beispiel nur noch 8 Schnittstellen anstelle von 12 bei der P2P-Integration benötigt. Die Investivkosten dieser Architektur sind im Vergleich zur P2P-Integration deutlich höher, da eine EAI Komponente benötigt wird. Diese ist i.d.R. kostenpflichtig. Zusätzlich fällt Aufwand für die Basiskonfiguration der EAI Lösung an. Die Folgekosten reduzieren sich jedoch deutlich dadurch, dass die Anzahl der Schnittstellen sinkt und der Wartungsaufwand dank des Basisschemas ebenfalls verringert wird.

[...]

^[1] 1Sneed (2002) S.3

^[2] Gräff S.23

^[3] 3 Keller (2002) S.5

^[4] Sneed (2002) S.4