Reaktionsfähig mit guter Verbindung

Im Zeitalter des E-Commerce sind nur schnell reagierende Unternehmen erfolgreich, die verzögerungsfrei auf Kundenwünsche eingehen können. Die Integration heterogener IT-Welten und Anwendungen mittels Enterprise Application Integration schafft dafür die Basis.

Von: Achim Scharf

EAI-Aktivitäten (EAI = Enterprise Application Integration) starteten zunächst in den USA und dort in Hospitälern. Aufgrund der vielen unterschiedlichen Abteilungen und Anwendungen, dem geringen IT-Budget sowie der Konkurrenzsituation, also dem Zwang zum wirtschaftlichen Arbeiten, entstand der Druck zur Anwendungsintegration. Heute haben 70 Prozent aller Krankenhäuser der USA EAI-Software implementiert. Mit dem Aufkommen des E-Business sehen sich auch Unternehmen anderer Wirtschaftsbereiche in einer ähnlichen Situation und müssen schnell reagieren können, um ihre Position behaupten zu können.

Theoretisch sollten Standards die Anwendungsintegration erleichtern, in der Praxis funktioniert das aber nicht. Common Object Model (COM), Common Object Request Broker Architecture (CORBA) oder Enterprise Java Beans (EJB) stellen zwar technische Mechanismen zur Interaktion von Objekten innerhalb einer Applikation zur Verfügung, sie unterstützen aber nicht die erforderlichen semantischen Transformationen zwischen Anwendungen.

Der traditionelle Ansatz war daher zunächst die Punkt-zu-Punkt-Integration für jedes Anwendungspaar. Oftmals wurde eine solche Integration ungenügend mit einer Reihe von Programmen für Extraktion, Dateitransfer, Messaging oder TCP/IP-Verbindung realisiert. Bei vielen beteiligten Anwendungen und Integrationsprogrammen entsteht schnell eine chaotische Struktur, die analog der chaotischen Programmierung von Anwendungen (Spaghetti-Code) auch als "Spaghetti-Integration" bezeichnet wird.

Dann kam die Hub-and-Spoke-Architektur, wo der Hub als zentralisierte Softwarekomponente die zu integrierenden Anwendungen über unterschiedliche Plattformen miteinander verband. "Die nächste Generation von EAI-Software ist verteilt, fehlertolerant und multi-threaded", so Jim Demetriades, Präsident von Software Technologies (STC), einer der Pioniere im Umfeld EAI.

Die Analysten bescheinigen nur zwei Firmen die Fähigkeit zum Marktführer aufgrund ihrer Visionen und deren Umsetzung.

"Vor zehn Jahren leitete ich eine Gruppe, die Software zur Integration von Computersystemen entwickelte. Wir wiederholten bei jedem neuen Projekt die gleichen Arbeiten. So entstand die Idee, wie wir Zeit und Kosten um bis zu 90 Prozent einsparen konnten. Ich entwickelte ein Produkt und gründete STC. 1991 stellten wir E-Gate vor, eine EAI-Software, basierend auf dem Client/Server-Prinzip. Die Anzahl der Schnittstellen reduzierte sich auf ein nicht-invasives Gateway (E-Way) zwischen jeder Anwendung und E-Gate. Das Ziel der Kostenreduzierung um 90 Prozent wurde eingehalten", erzählt Demetriades. "Allerdings waren damals weder die Messaging-Standards so ausgereift wie heute noch TCP/IP so verbreitet. Wir mussten mit SNA, Novell und Decnet auskommen. Heute unterstützen wir einschließlich XML rund 500 Messaging-Standards."

Enterprise Application Integration impliziert damit zunächst eine strukturierte Kopplung von Geschäftsprozessen, in zweiter Linie die Möglichkeit, beliebige Geschäftspartner unabhängig von Standort und Zeit erreichen zu können. "EAI-Software ist die technische Middleware für die Realisierung einer E-Business-Strategie", so eine Definition von Richard Nußdorfer, Geschäftsführer der Münchener CSA Consulting. Die Integration der Lieferketten sei das wesentliche Ziel. Das Ergebnis ist ein ereignisgesteuertes latenzarmes Unternehmen, das aufgrund der Automatisierung und Vernetzung aller Geschäftsprozesse sofort reagieren kann.

Virtuelle Unternehmen können per EAI Informationen in Echtzeit austauschen.

Durch Adapter als einfachste Stufe ist auch technisch orientierte Middleware für die Anwendungsintegration einsetzbar. Somit ist eine evolutionäre Weiterentwicklung auf Basis vorhandener Middleware laut CSA bedingt möglich. Typische Anbieter in diesem Umfeld sind BEA, IBM, Microsoft oder die Software AG.

Message Queuing Software wie "MQSeries 5.0" von IBM transportiert Daten über verschiedene Anwendungsprogramme und Systemplattformen, vom PC bis zum Mainframe. Zusätzlich bauen die Unternehmen das Angebot an Zusatzmodulen, beispielsweise um XML, erheblich aus. Weiterhin gibt es neue APIs. Das Application Messaging Interface (AMI) erleichtert die Erstellung des Codes zum Message Handling. Der Code wird aus der Anwendung herausgenommen und direkt in die Middleware implementiert. Die Applikation kann somit direkt auf die Business-Logik zugeschnitten werden. Das Message-Handling sorgt dafür, dass Nachrichten an die richtige Adresse gelangen und bestätigt den Eingang der Nachricht beim Adressaten. Das neue AMI beinhaltet Message-Operationen, die Datenbearbeitung und Routing automatisieren. Spezielle Policy-Handler ermöglichen entsprechend den internen Vorgaben der einzelnen Anwender, Nachrichten automatisch zu verschlüsseln oder an spezielle Regeln anzupassen.

"MQSeries Integrator", Version 2.0, kann vorhandene Datenbanken effektiver in die Messaging-Infrastruktur einbinden. Das System sorgt automatisch für die Umsetzung firmeninterner Regeln, so dass die richtigen Informationen an die richtigen Arbeitsplätze und Anwendungsprogramme weitergeleitet werden. "MQSeries Workflow" V3.2 schließlich ermöglicht die interne und externe Integration sowie die Verwaltung von Geschäftsprozessen. Mit XML lassen sich auch externe Geschäftspartner und Lieferanten in den Workflow-Prozess eines Unternehmens integrieren. Der Standard erlaubt eine Ad-hoc-Kommunikation zwischen unterschiedlichen IT-Systemen. Beispielsweise kann eine Bestellung als XML-Dokument aus dem Web automatisch mit Auftragsbestätigung und Rechnung im XML-Format akzeptiert werden.

Message Broker erlauben eine schnell implementierte Lösung über eine zentrale Komponente entsprechend der Hub-and-Spoke-Architektur. Die Verteilung der Informationen erfolgt über einen Publish-and-Subscribe-Mechanismus. Es handelt sich um eine Lösung für einfachere Integrationsanforderungen, die keinen komplexen Workflow erfordern. Typische Anbieter sind laut CSA die Firmen Active Software, Neon, Fujitsu-Siemens Computers, Viewlocity, Tibco, Mercator, Vitria oder Seeburger.

Data Server ermöglichen eine Kommunikation zwischen Datenbanken mit Datentransformation entsprechend vorgefertigter Regeln zwischen Geschäftsobjekten. Für die Ereignissteuerung sorgen Polling-Mechanismen oder Trigger. Typische Anbieter sind Constellar, ETI oder STC.

'Die nächste Generation von EAI-Software ist verteilt, fehlertolerant ind multi-threaded.'

"E-Gate" von STC beispielsweise kombinierte in den frühen Versionen Message-Identifikation, -Übersetzung, -Queuing und -Routing fast in Echtzeit in einer Server-Anwendung. Geschäftsregeln wurden durch einfache Tabellen definiert, wiederverwendbare "E-Ways" fungierten als Adapter zu den Anwendungen. In der Version 3 (1996) wurde eine grafische Bedienoberfläche in die Software integriert, mit der Geschäftsregeln per Mausklick definiert werden konnten. Hinzu kamen dann auch E-Ways für R/3, Peoplesoft, Clarify, Vantive, Siebel sowie andere ERP- oder CRM-Anwendungen. Die "Intelligent Bridge" zwischen SAP und Siebel ist eine Out-of-the-box-Lösung, die mehr als 80 Prozent der Integrationsarbeit zwischen den Anwendungen erspart. Konten, Kontenhierarchien, Produkte, Produkthierarchien, -preise, -discounts, Verkaufsbestellungen und deren Status werden mit dieser Lösung synchronisiert.

Die Version 4.0 von E-Gate setzt auf einer skalierbaren Netzwerkarchitektur auf. Im Inter- und Intranet können alle Anwendungen miteinander Informationen austauschen und Aktionen entsprechend dem vorgegebenen Geschäftsmodell anstoßen. Alle Modelle und Regeln sind in einem zentralen Repository (Registry) gespeichert.

Das ist eine Folge der Verbindung von Anwendungen über eine Reihe von Programmen für Extration, Dateitransfer, Messaging und Ähnliches.

Die Prozessintegration ist die derzeit anspruchsvollste Lösung mit Einbeziehung von Applikationsservern, XML und Web-Integration. Automatisierter Workflow, Datentransformation nach vorgefertigten Regeln, Ereignissteuerung sowie Adapter sind einige der wesentlichen Funktionen. Komplexe Integrationsanforderungen zwischen mehreren unterschiedlichen Anwendungen (ERP, CRM, Legacy) via Messaging-Middleware oder Internet sowie der Einsatz von Standards wie XML oder auch branchenspezifische Definitionen wie Rosetta-Net sind damit realisierbar. Die Prozessintegration ist besonders günstig, wenn vorhandene Komponenten mit neuen Komponenten über CORBA oder DCOM verbunden werden können. Typische Hersteller sind Crossworlds, Forté Fusion, Dignos oder Jardix.

Crossworlds beispielsweise verbindet unterschiedlichste Anwendungen für Buchhaltung, Kostenkontrolle und Planung über vorkonfigurierte Module und Schnittstellen zu einem einheitlichen System. Die Synchronisierung der Daten erfolgt über einen XML-Connector und ein voreingestelltes Interface für die Verknüpfung von Applikationen. Aufbauend auf der Hub-and-Spoke-Architektur ist die Integration von XML-Daten in Legacy- und Standardanwendungen sowie für das Backoffice und SCM möglich.

"Collaborations" sind in diesem Konzept anwendungsunabhängige Geschäftsprozesse für die Integration von Anwendungen beim Kunden. Customer Interaction als EAI-Anwendung integriert Vertrieb und Kundenservice, wie beispielsweise von Aurum, Clarify, Siebel, Trilogy oder Vantive, im Frontoffice mit ERP-Kernanwendungen im Backoffice, zum Beispiel den Produkten von Baan, J.D. Edwards, Oracle, Peoplesoft oder SAP.

Sie basiert auf dem Client/Server-Prinzip und ist gut skalierbar.

Die Konnektoren-Kategorie Enterprise integriert Standard-, Legacy- und Individual-Anwendungen durch vorgefertigte Collaborations, um gemeinsame Informationen aus verschiedenen Anwendungen in ein einheitliches Format zu bringen und zu synchronisieren. E-Business unterstützt die Integration von Handelspartnern über das Internet. Supply Chain integriert die Logistik-Anwendungen wie "Manguistics" oder "IMI" mit Frontoffice- und ERP-Anwendungen. Telecom schließlich verbindet Legacy- mit Standard-Anwendungen im Bereich Telesales und Teleservice.

Als Infrastruktur kommt Standard-Software zum Zuge. "Wir setzen in unserer EAI-Software auf MQSeries als Messaging-System, denn mit über 60 Prozent Marktanteil handelt es sich dabei quasi um einen Standard, und darauf haben wir unsere Prozesslogik entwickelt. Wir können jedoch auch andere Systeme einsetzen, wenn der Kunde beispielsweise BEA bevorzugt. Wie bisher unterstützen wir alle weiteren Standards wie CORBA, DCOM, HTML oder XML, weil gerade für Integrationssoftware eine sehr offene Architektur erforderlich ist", erläutert Peter Prestele, General Manager Europe von Crossworlds. Im Bereich Industrie lassen sich mit dieser Software virtuelle Unternehmen oder "extended Enterprises" aufbauen, die datentechnisch eng miteinander kooperieren.

"Der erste Hersteller mit einem umfassenden EAI-Konzept war Crossworlds, der jetzt von Projekterfahrungen in komplexen Umgebungen profitieren kann. Forté ist ein weiterer Hersteller mit einem weitreichenden Konzept, das konsequent auf das Internet und XML ausgerichtet ist. Produkte von Active, Mercator/TSI, Tibco oder Vitria basieren auf einem starken Applikationsserver. Hier zeigt sich deutlich, dass EAI-Lösungen immer komplexer werden", erklärt CSA Consulting-Geschäftsführer Nußdorfer. "Rossetta-Net beispielsweise ist ein Konsortium, das branchenspezifische EAI-Standards definiert hat, die von den Herstellern Vitria und Crossworlds umgesetzt werden. Ein Quasi-Standard ist die Datentransformation von Mercator geworden, die Business-Objekte zwischen Anwendungen entsprechend den vorgegebenen Regeln umwandelt."

EAI unterscheidet sich deshalb von konventioneller Middleware, weil betriebswirtschaftliche Funktionen mitgeliefert werden. Das bedeutet, beim Transport können die Daten anhand vordefinierter Regeln umgewandelt werden. Damit versteht sowohl Anwendung A als auch B das Kundenobjekt. Deshalb bezeichnet man EAI-Software auch als lösungsorientierte Middleware. "Ob eine Datentransformation mit Hilfe von XML-Dokumenten oder eher herkömmlich stattfindet, ist eine Frage der technischen Umsetzung und kommt daher erst an zweiter Stelle. Zuerst muss die generelle Integrationsstrategie definiert werden, anschließend kommt die Betrachtung der möglichen Architekturen und erst dann folgen die technischen Lösungsmöglichkeiten", meint Nußdorfer. (sf)

Zur Person

Achim Scharf

arbeitet als freiberuflicher Fachjournalist in München. Seine Schwerpunkte sind unter anderem Internet und E-Commerce.