Enterprise Applikation Integration (EAI) und Middleware
Grundlagen, Architekturen und Auswahlkriterien

Marten Schönherr

Zu Beginn fasst der Beitrag die Ausgangssituation vieler EAI-Projekte und deren Ziele zusammen. Danach geht er auf Grundlagen und Architekturen von EAI-Produkten ein, beschreibt Auswahlkriterien für eine Toolauswahl, listet die wichtigsten Anbieter auf und schließt mit einem kurzen Ausblick auf die zu erwartenden Entwicklungen auf dem Markt der EAI-Produkte.

Seit langem kennen vor allem große Unternehmen die Relevanz der Anwendungsintegration. Besonders der Kostenfaktor in den Bereichen Systementwicklung und -betrieb spielt hier eine bedeutende Rolle. Als in den 90er Jahren ERP-Systeme an Bedeutung gewannen, verschärfte sich die Notwendigkeit, bereits vorhandene Applikationen und Daten mit ERP-Systemen zu verbinden. Es wurden nicht nur Daten ausgetauscht, vielmehr sollten Geschäftsprozesse systemübergreifend unterstützt werden. Ein weiterer Grund für die Entwicklung von so genannten Enterprise Application Integration (EAI)-Produkten war die stark zunehmende Verbreitung von Supply Chain Management Ansätzen, Business-to-Business Integration (B2Bi), die Integration von Web-Applikationen und die allgemeinen technologischen Fortschritte in der Standardisierung von Daten- und Objektintegration.[1]

Eine allgemeine Definition des Begriffes kann sowohl akademisch als auch pragmatisch vorgenommen werden. Systemintegration wird in der Wirtschaftsinformatik als „ingenieurwissenschaftlich orientierte Vorgehensweise“ [2] beschrieben, um die betriebliche Realität möglichst genau über IT-Systemgrenzen hinaus abzubilden. Dabei umfasst der verwendete Begriff sowohl Methoden als auch Systeme [3]. Ren schreibt hierzu etwas einfacher:

„Einst benutzten die Unternehmen die Client/Server-Technologien, um Abteilungsbezogene Applikation aufzubauen, aber später bemerkten sie die enormen Vorteile, die dabei entstehen, wenn man die einzelnen Geschäftsprozesse und damit auch deren Applikationen miteinander verknüpft.“[4]

Ziel von Integrationsprojekten in Unternehmen ist vor allem die Steigerung des Nutzens beim Einsatz von IT. Diese Nutzenpotenziale können in strategische und operative unterschieden werden. Der operative Nutzen von Systemintegration kann zum einen in den Fachabteilungen und zum anderen in der IT-Abteilung betrachtet werden. [5] In der folgenden Tabelle werden diese Potenziale anhand der Kriterien Kosten, Zeit und Qualität aufgezählt: Neben den operativen Zielen steht vor allem die strategische Ebene bei der Systemintegration im Vordergrund. Schill beschreibt die folgenden Schwerpunkte [7]:
• Flexibilisierung der Organisationsstrukturen durch nachhaltig anpassbare IT-Infrastrukturen
• Umfassende Kosteneinsparpotentiale bei Merger & Akquisition-Projekten
• Kosteneinsparungen durch Einführung von Standards
• Investitionsschutz in IT-Infrastruktur durch langfristige Verwendung von Systemen in einer Integrationsumgebung
• Steigerung der Integrationsfähigkeit für die Integration weiterer Systeme

Tabelle 1: operative Nutzenpotentiale als Integrationsziele [6].

Integrationsgegenstand, -reichweite und -richtung
Die drei Dimensionen Integrationsgegenstand, -reichweite und -richtung werden als Beschreibungskriterien für den Fokus bzw. den Grad der Integration beschrieben [8]. Der Begriff Integrationsgegenstand wird oft analog zur Integrationstiefe verwendet. Sie sind Kriterien für Grad und Ebene einer Integration. In der Regel werden die Integrationsebenen Daten, Funktionen (Objekte/ Komponenten) und Prozesse unterschieden [9, 5].

EAI auf Datenebene stellt die geringste Integrationstiefe dar. Scheer unterscheidet vier Datenintegrationsgrade: manuelle Daten- Weitergabe, automatische Weitergabe über Schnittstellen, Zugriff auf eine definierte gemeinsame Datenbasis und übergreifende Abbildung aller Unternehmensdaten in einem Metadatenmodell [10]. Der Integrationsgrad steigt, je mehr Daten unabhängig von ihren Stammsystemen verwendet werden können.

Bei der Integration auf Funktions- bzw. Objektebene kommunizieren Anwendungen kontrollierter miteinander. Es werden Funktionen bzw. Methoden in den Objekten anderer Systeme aufgerufen und übergreifend verwendet. Um diese Integrationsebene zu realisieren, werden u.a. APIs eingesetzt. Systeme müssen z.T. verändert werden, wenn keine Standard- APIs zur Verfügung stehen. Auf einer höheren Abstraktionsebene bezeichnet man Programme bzw. Programmteile hier auch als Komponenten. Durch Kapselung und der standardisierten Kommunikation zwischen den gekapselten Komponenten kann eine sehr weitreichende Integration realisiert werden, die nicht mehr zwischen den originären Systemen unterscheidet, sondern die jeweils richtige Komponente verwendet. [11] Je mehr Funktionen, Objekte bzw. Komponenten unabhängig von den DV-Systemen und deren Arbeitsumgebungen, in denen sie verankert sind, verwendet werden, desto höher ist der Integrationsgrad in dieser Ebene.

Bild 1: Integrationsebenen.

Bei der Prozessintegration liegen abgebildete Geschäftsprozesse nicht mehr in Einzelsystemen, vielmehr werden Prozesse unabhängig von operativen Systemen in einer EAI- Prozessebene unterstützt. Hieraus werden dann, gemäß dem definierten Workflow, die Dienste der einzelnen Anwendungen gesteuert und aufgerufen. Dabei stehen die prozessorientierte Funktionsintegration und die durchgängige Unterstützung von Teilaufgaben eines Gesamtprozesses im Vordergrund. [12] Je durchgängiger Geschäftsprozesse unterstützt werden, ohne dass dabei die Verwendung spezifischer Systeme beachtet werden muss, sondern die Anforderungen des Prozesses, desto höher ist der Integrationsgrad.

Die Begriffe der Integrationsreichweite und der Integrationsbreite werden oft synonym verwendet. Die so genannte Integrationsbreite bestimmt sich durch die Anzahl der Anwendungen, die integriert werden sollen. Sind es nur wenige, eng zusammengehörige Systeme, so spricht man von einer geringen Integrationsbreite. Wird eine ganze Wertschöpfungskette integriert, ist die Integrationsbreite groß. Mit der Integrationsbreite steigt die Komplexität des Integrationsprojektes.[8]

Mit dem Begriff der Integrationsrichtung beschreibt Kaib den Grad der Integration bezogen auf die jeweilige Ausprägung der Integration in einer Organisationsstruktur. [5] Dabei wird zwischen horizontaler und vertikaler Integration differenziert. Der Grad der horizontalen Integration steigt mit der Anzahl der beteiligten Fachabteilungen bzw. Organisationseinheiten [8]. Bei der horizontalen Integration unterscheidet Mertens zwischen der Anzahl der integrierten Planungs- und Kontrollsysteme aus den Administrations- und Dispositionssystemen [13].

Grundlagen der Systemintegration
Heute existieren vielfältige Ansätze, Anwendungen zu integrieren. Die Konzepte und Architekturen sind abhängig von der jeweiligen zu integrierenden Systemlandschaft. Oft werden innerhalb der unterschiedlichen Produkte allerdings die gleichen Basistechnologien verwendet. Zur Definition und Realisierung einer individuellen Integrationsstrategie auf Grundlage dieser Basistechnologien benötigen die verantwortlichen Fach- und IT-Abteilungen umfassende Kenntnisse über ihre vorhandene Systemlandschaft, die Möglichkeiten der EAI-Systeme und vor allem der abzubildenden Geschäftsprozesse. Die Herausforderung eines erfolgreichen EAI-Projektes ist die Ermittlung der Anforderungen und die entsprechende Auswahl der richtigen Technologien bzw. Produkte, mit denen die Anforderungen abgedeckt sind. Im Folgenden werden die wichtigsten Architekturen, Konzepte und Auswahlkriterien kurz erläutert.

Konventionelle und individuell entwickelte Punkt zu Punkt-Schnittstellen gehören ebenso zum relevanten Handwerkszeug wie so genannte zentrale Hub&Spoke-Ansätze und verteilte Service-Orientierte Architekturen (SOA). Bild 2 zeigt grundsätzliche Integrationsarchitekturen, die in der Praxis allerdings selten in reiner Form zu finden sind [14]:

Bild 2: Integrationsarchitekturen.

Die Architekturen haben je nach Einsatz Stärken und Schwächen. So sind dezentrale proprietäre Punkt-zu-Punkt Schnittstellen teuer zu entwickeln und zu warten und unflexibel, zeichnen sich allerdings durch transaktionale Performance, Sicherheit und individuelle Passgenauigkeit aus, da sie für ein spezifisches Szenario konzipiert wurden.

SOA greift den dezentralen Ansatz der Punkt-zu-Punkt Interfaces auf, stellt im Gegensatz dazu aber auf Standards basierende Schnittstellen zur Verfügung, die im Backend systemneutrale gekapselte Services (Funktionen) anbieten, die sowohl wieder verwendet als auch verteilt prozessorientiert orchestriert werden können. Zurzeit steht die Web Service Technologie als Implementierungsumgebung ganz oben in der Gunst der SOA-Vertreter. Web Services sind allerdings noch nicht lange in diesem Kontext bekannt und bergen daher noch Implementierungsrisiken und Methodenschwächen im Vergleich zu den anderen Architekturen.

Meist auf Middlewarekonzepten basierende Hub&Spoke Architekturen, die vielen bekannten EAI-Produkten zugrunde liegen, zeichnen sich durch hohe Flexibilität und zentrale Administration aus. Sie haben das Ziel, große Anteile des systemübergreifenden Datenverkehrs abzuwickeln, was hohe Anforderungen an Performance und Ausfallsicherheit bedeutet. Diese Faktoren müssen in der Regel teuer bezahlt werden. Es gibt in diesem Zusammenhang ebenfalls Busarchitekturen, die netzwerkzentrisch und verteilt arbeiten. Hub&Spoke Instanzen können ebenfalls verteilt und damit nicht ausschließlich zentral eingesetzt werden. [5]

Bei Hub&Spoke Systemen werden über Adapter (Spokes), die die Konnektivität zu den angebundenen Systemen realisieren, Nachrichtendokumente (Messages) an den zentralen Hub gesendet und dort für die Zielsysteme transformiert und nach definierten Regeln über Adapter (Spoke) an diese weitergeleitet. Sie werden in n:m Szenarien eingesetzt. Busarchitekturen basieren auf dem Publish&Subscribe –Ansatz. Ein Sender (Publish) verteilt über den Bus Messages an definierte Empfänger (Subscribe), die an die Zielsysteme weitergegeben werden. Diese Vorgehensweise ist vor allem sinnvoll für einfache, in der Praxis aber weit verbreitete 1:n/n:1 Szenarien wie Datenabgleich- und Reportingfunktionen. [15]

 

Beide Ansätze basieren auf Nachrichtenaustausch (Messaging). Einige EAI-Produkte setzen bekannte Middlewaresysteme ein, andere haben ein eigenes Nachrichtenmanagement entwickelt. Wie auch im Bereich der messageorientierten Middleware gibt es diverse Konzepte, das Messaging zu organisieren. Zum einen werden synchrone und asynchrone Ansätze unterschieden. Der asynchrone Ansatz hat den Vorteil, dass nicht alle beteiligten Systeme online sein müssen. Eine Integration ist dementsprechend auch ohne zeitgleiche Verfügbarkeit aller Systeme möglich. Viele Szenarien lassen sich mit synchronen Ansätzen letztendlich nicht zuverlässig integrieren, da eine Konnektivität bzw. Belastbarkeit durch Datenexport- und -import nicht permanent gegeben ist. Weiterhin modellieren die meisten Produkte das Messaging nach formalen Regeln. Syntaktisches und semantisches Mapping, Reihenfolge der Abarbeitung, Ausfall- und Fehlerregeln und vieles mehr kann entweder durch Skriptsprachen oder grafische Oberflächen definiert werden. [5]
 

Bild 3.: EAI-Bestandteile [16].

EAI-Produkte grenzen sich weiterhin von konventionellen Middleware-Ansätzen ab, indem sie weitere Features anbieten. Existierende Adapter für eine Vielzahl bekannter Standardsoftwaresysteme, BPM-Tools, Repositories und umfassende Administrationskonsolen qualifizieren sie für den Einsatz als zentrale Infrastruktursysteme, die durchaus erfolgskritische Aspekte für Unternehmen abbilden. 

Um die unabhängig von den oben beschriebenen Konzepten in der Regel notwendigen funktionalen EAI-Bestandteile zusammenzufassen, bietet sich die folgende Referenzarchitektur an:

Auswahl- und Bewertungskriterien für EAI-Produkte
Eine pauschale EAI-Systemauswahl läßt sich auf Grund der individuellen Anforderungen von Integrationsszenarien und der Vielfalt von am Markt erhältlichen Produkten nicht treffen. Auf dem deutschsprachigen Markt bieten etwa 200 Hersteller zumeist spezifische Teillösungen für die oben aufgeführten EAI-Bestandteile. Nur etwa ein dutzend Systeme können als umfassende EAI-Infrastrukturprodukte bezeichnet werden. Die folgenden Kriterien sollen helfen, die wichtigsten Anforderungen für eine Toolauswahl zu definieren. Das Ergebnis einer Produktauswahl sollten wenige Anbieter sein, die ihre Produkte fallbezogen in einem proof-of-concept vorstellen, auf dessen Grundlage eine finale Entscheidung getroffen werden kann. Zu beachten ist weiterhin, dass sehr oft mehrere Produkte letztendlich zu einer passenden Lösung zusammenkommen, deren gemeinsamer Einsatz natürlich alle Anforderungen erfüllen muss.

Prinzipiell lassen sich technische und nicht-technische Kriterien unterscheiden. Die nicht-technischen sind analog zu denen anderer Softwaresystemkategorien u.a. Unternehmensentwicklung des Anbieters, Serviceleistungen, Lizenzbedingungen und Referenzen.

Im folgenden werden zentrale technische Kriterien kategorisiert und als Stichpunkte aufgezählt. Es lassen sich Design-Time, Run-Time und allgemeine Architekturkriterien einer EAI-Plattform unterscheiden. Da in der Regel nie alle relevanten Systeme gleichzeitig über eine EAI-Infrastruktur angebunden werden, geht dem operativen Betrieb (Run-Time) immer eine Projektphase (Design-Time) voraus bzw. bei Änderungen werden auch während der Run-Time rollierend Design-Time-Aspekte relevant. Die allgemeine Architektur sollte den IT-Richtlinien bzw. der IT-Strategie entsprechen. 

Architektur
• History
• Konzepte zur persistenten Datenhaltung innerhalb des EAI-Systems
• Integration der verschiedenen Elemente des EAI-Systems bzw. der Komponenten verschiedener Anbieter
• Mandantenfähigkeit
• Replikation bzw. verteilter Einsatz zentraler Komponenten und deren regelbasierter Abgleich
• Unterstützte Standards (u.a. Orchestration, Datenaustauschformate, Sicherheit)

 

Design-Time
• EAI-Funktionen

• Adapter (eigene oder fremde)
• Mapping/Transport/Routing-Strategien
• Standard-Nachrichtenmanagement/Middleware (Corba, .Net, COM/DCOM)
• IDE (integrierte Entwicklungsumgebungen)
• Applikationsserver (Portal-, J2EE-, .NET-Server etc.)
• Testumgebung

• BPM-Funktionen

• Modellierungsumgebung
• Notationen (Durchgängigkeit von Geschäftsprozess- zur Message Queing-Modellierung)
• Prozess-Engine (regelbasiert, Repository, Administration, Performance)
• Prozessmonitoring 

 

Run-Time
• Deployment
• Verfügbarkeit
• Skalierbarkeit
• Sicherheit
 

Fazit
Zusammenfassend lässt sich sagen, dass der EAI-Markt in den letzten beiden Jahr bei leicht steigendem Umsatz bereits durch Unternehmenskäufe und Fusionen überschaubarer geworden ist. Die in den Markt drängenden großen Anbieter (Microsoft, SAP, Sun, Oracle etc.) machen den bereits länger am Markt zu findenden Spezialisten (WebMethods, Vitria, TIBCO etc.) zu schaffen, da immer mehr Kunden bei ihren großen Infrastrukturlieferanten auch Integrationslösungen nachfragen und bereit sind, auf deren Ansätze zu warten. Der einzige große Anbieter, der bereits viele Jahre Erfahrungen mit dem EAI-Geschäft hat, ist IBM mit einer immer größer werden Produktpalette (eigene und gekaufte) unter dem Label WebSphere.

Die größten funktionalen Schwächen weisen viele Anbieter noch im Bereich der prozessorientierten Integration auf, wo es an durchgängigen Konzepten und Technologien fehlt, reale volatile Geschäftsprozesse tatsächlich in die existierende IT-Infrastruktur zu implementieren und auf deren Änderungen effizient abzubilden. Ebenfalls fehlen generische Methoden, mit denen Unternehmen in die Lage versetzt werden, die sehr komplexen EAI-Projekte erfolgreich umzusetzen.

Das könnte Sie auch interessieren:

[ EAI in der Praxis Eine empirische Studie ]
[ Enterprise Applikation Integration (EAI) und Middleware ]

Schlüsselwörter:

EAI, Middleware, Architekturen, Integration-Broker, Messaging

Literatur:

[1] Vander Hey, D.: One Customer, One View; in: Intelligent Enterprises Magazine, Heft 4; 1.3.2000.
[2] Kurbel, K.; Rautenstrauch, C.: Integration Engineering. in: Heilmann, H,; Heinrich, L.; Roithmayr, F.: Information Engineering, München, Wien 1996.
[3] Mertens, P.: Integrierte Informationsverarbeitung. in: Mertens, P. u.a.: Lexikon der Wirtschaftsinformatik. Berlin 1997.
[4] Ren, F.: The Marketplace of C, http://www.public.asu.edu/~mbfr2047/eai.html.
[5] Kaib, M.: Enterprise Application Integration, Wiesbaden, 2002.
[6] Scheckenbach, R.: Semantische Geschäftsprozessintegration. Wiesbaden, 1997.
[7] Schill, A.: Middleware im Vergleich. http://www.competence-site.de/eaisysteme.nsf/C937534DE4B6BC14C1256A14005...$File/middleware.pdf, 2000.
[8] Linß, H.: Integrationabhängige Nutzeffekte der Informationsverarbeitung: Vorgehensmodell und empirische Ergebnisse. Wiesbaden, 1995.
[9] Linthicum, D.S.: Enterprise Application Integration, München, 2000.
[10] Scheer, A.-W.: CIM. Berlin, 1990.
[11] Mertens, P.; Griese, J.: Integrierte Informationsverarbeitung 2 – Planungs- und Kontrollsysteme in der Industrie. Wiesbaden, 2000.
[12] Ferstl, O.: Integrationskonzepte betriblicher Anwendungskonzepte. Fachbericht Informatik der Universität Koblenz-Landau, Nr. 1, 1992.
[13] Mertens, P.: Integrierte Informationsverarbeitung 1 Administrations- und Dispositionssysteme in der Industrie. Band 1, Wiesbaden, 2000.
[14] Aier, S.; Schönherr, M.: EAI-Flexibilisierung komplexer Unternehmensstrukturen. Band 1, Berlin 2004
[15] Born, A.; Diercks, J.: Abgeschirmt. In iX, Heft 11, 2003.
[16] Ring, K.: EAI - Making the right Connections; Boston, 2000.