Ein Überblick 35 % des gesamten IT-Budgets werden für EAI ausgegeben Aussage der Gardner Group zu EAI Einflussfaktoren Die Entwicklung von Enterprise Application Integration (EAI) zu einer eigenständigen IT- Disziplin mit einer Fülle von Produkt- Dienstleistungsanbietern ist ganz entscheidend durch drei Faktoren beeinflusst worden: Internet, Globalisierung, damit verben, ebusiness. Die mit hoher Geschwindigkeit fortschreitende Entwicklung des Internets hat zu einem drastischen Wandel der Geschäftsmodelle damit verben zu einem weitgehenden Paradigmenwechsel in der Informationsverarbeitung geführt. Während sich im traditionellen Business-Modell EDV-Unterstützung Automatisierung fast ausschließlich auf geschäftsinterne Prozesse erstreckte die Kommunikation mit Geschäftspartnern, Ken Lieferanten mit mehr oder weniger manuellen Verfahren wie Post, Fax, Telefon oder e-mail abgewickelt wurden, werden im ebusiness bei der Abbildung der Geschäftsprozesse auch die Prozesse der beteiligten Geschäftspartner in die Automatisierung einbezogen. Diese Entwicklung hat deutlich vermehrte Integrationsanforderungen hervorgerufen. Ferner hat die im Rahmen der Globalisierung zunehmende Zahl von Unternehmensübernahmen -zusammenschlüssen zu einer Vielzahl heterogener IT-Landschaften mit hohem Integrationsbedarf geführt. Nicht zuletzt ist es zudem der Kostendruck, der durch überflüssige manuelle Eingriffe in die Geschäftsprozessabläufe hohen Wartungsaufwand wegen fehlender oder unzureichender Integration entsteht, der nach professionellen Integrationslösungen verlangt. Nutzen Der wohl wichtigste Nutzen liegt in der Erschließung neuer Geschäfts- Umsatzmöglichkeiten durch die Nutzung des Internets. Nach Einschätzung der Gartner Group wächst der weltweite Online-Umsatz zwischen Unternehmen von 0,8 Billionen DM im Jahre 2000 bis 2004 auf ein Volumen von umgerechnet 7 Billionen Euro. Die dazu benötigte IT-Infrastruktur ist ohne Einsatz von EAI-Werkzeugen nicht denkbar. Zudem ergeben sich erhebliche Einsparpotenziale durch die Optimierung Integration interner unternehmensübergreifender Geschäftsprozesse, da viele manuelle Eingriffe Mehrfacherfassung von Daten entfallen. So müssen zum Beispiel über das Internet eingegebene Bestelldaten nicht erneut in ein Auftragserfassungssystem beim Lieferanten eingegeben werden sondern stehen dort durch die Integration der Systeme direkt zur Verfügung. Partner Server Datenbanken Ken Distribution Lieferanten Internet Anwendungen Integrierte Architekturen Lösungen Infrastrukturen Content Provider Service Provider TSM V6 03.09
Weitere Kostensenkungen können erzielt werden, wenn bestehende wartungsintensive Punkt-zu-Punkt-Verbindungen zwischen verschiedenen Anwendungen durch eine einheitliche Integrationsplattform (Prinzip Drehscheibe) ersetzt werden. Eine weitere Form ist die Frontend Backend Integration (B2C). Auf der Frontend Seite handelt es sich sehr häufig um einen Internet-Client, auf der Backend-Seite um ERP-Systeme wie zum Beispiel SAP eigene Entwicklungen, sogenannte Legacy-Systeme. Diese stellen häufig die Kernanwendungen eines Unternehmens dar laufen in der Regel auf Mainframes unter den dort vorhandenen TP-Monitoren Datenbanken wie CICS oder IMS DB/DC. Application Integration Point-to Point Integration Integrationsformen Im Folgenden werden die drei wichtigsten Integrationsformen dargestellt. Eine Form ist die Integration verschiedener Anwendungen innerhalb eines Unternehmens (A2A). Ein Beispiel dafür ist die Verwendung von Kenstammdaten in verschiedenen Anwendungen. Hier müssen bei Änderungen, zum Beispiel Neugewinnung eines Ken, entsprechende Informationen allen betroffenen Anwendungen zur Verfügung gestellt werden. Dieses Problem existierte auch schon vor EAI wurde üblicherweise durch sogenannte Schnittstellenprogramme gelöst mit dem Ergebnis, dass sich im Laufe der Zeit eine beachtliche Menge solcher Programme ansammelte, was wiederum zu einem erheblichen Wartungs- Entwicklungsaufwand führte. Hier führt der Einsatz eines EAI-Werkzeugs zu deutlichen Verbesserungen. In diesen Fällen ist die Integration ohne entsprechende Integrationssoftware fast nicht möglich. Die dritte anspruchsvollste Form ist die Integration unternehmenseigener Geschäftsprozesse mit denen von Geschäftspartnern (B2B). Beispielanwendungen sind hier eprocurement, Supply Chain Management sowie Customer Relationship Management. Dieser Ansatz beginnt oft mit der (Neu)modellierung der Geschäftsprozesse, der Festlegung der Kommunikation mit internen externen Partnern bzw. den Geschäftsprozessen anderer Unternehmen geht damit über die reine Integration hinaus.
Daten Integration Zentraler EAI-Architekturen Üblicherweise wird zwischen folgenden Architekturen unterschieden: Datenintegration Message Broker Zentraler Integrationsserver Middleware Integration Welcher Architekturtyp am besten geeignet ist, kann nicht allgemein beurteilt werden sondern hängt von der jeweiligen Aufgabenstellung ab. Die Festlegung der optimalen Architektur ist einer der wichtigsten Bestandteile in jedem EAI-Projekt. Die im Folgenden stellenweise aufgeführten Hinweise auf Hersteller sind weder vollständig noch als Empfehlung anzusehen sondern nur als Beispiele zu betrachten. Datenintegration Bei diesem Ansatz werden Daten aus verschiedenen Datenhaltungssystemen, im allgemeinen Datenbanken, selektiert anderen Datenbanken oder Anwendungen zur Verfügung gestellt. Dabei wird die Selektion sehr häufig über in einem Repository hinterlegte Geschäftsprozess-Regeln gesteuert. Beispiel für diese Form der Integration ist das Zero Latency Enterprise (ZLE), wo über einen solchen Mechanismus Daten aus verschiedenen Systemen in Realzeit extrahiert in einem Operational Data Store (ODS) zur weiteren Verarbeitung zur Verfügung gestellt werden. Message Broker Message Broker (Network-Centric) Middleware Integrtion Dieser Architekturtyp besteht aus dezentralen Funktionsbausteinen, die auf jedem zu integrierenden Knoten im Netz installiert sind (Netzwerk-zentriert). Wichtigste Funktion eines solchen Systems ist ein regelbasiertes Message-Routing. Hinzu kommen bei verschiedenen Herstellern weitere Funktionen, wie Bereitstellung von Konnektoren/Adaptern für verschiedene ERP- Legacy-Systeme oder Mechanismen zur regelbasierten Datentransformation. Zentraler Integrationsserver Im Mittelpunkt steht bei diesem Integrationstyp ein zentraler Server (Server-zentriert), der sowohl die Funktionalität eines Application Servers unterstützt als auch als Container für die EAI- Bausteine dient. Häufig enthält er auch sogenannte Processware zur Modellierung von Geschäftsprozessen der Integrationslogik mit anschließender Generierung ablauffähigen Codes. Er ermöglicht gemeinsame Nutzung von Geschäftslogik (z.b. CORBA-Objekte) durch unterschiedliche Anwendungen. Ebenfalls enthalten sind im allgemeinen eine Regelmaschine, Einrichtungen zur Datentransformation sowie vorgefertigte Adapter für ERP- Legacy-Systeme. Wichtige Hersteller dieses Typs sind Mercator, SUN One (iplanet), webmethods. Middleware Integration Dieser Integrationstyp ist durch die Erweiterung eher technisch orientierter Middleware wie zum Beispiel Application Server oder Object Request Broker um Komponenten zur Lösung von Integrationsproblemen gekennzeichnet. Solche Komponenten sind zum Beispiel Adapter zu ERP- Legacy-Systemen. Weiter existieren Rahmenwerke zur Entwicklung anspruchsvoller Internet-Portal Lösungen. Wichtige Hersteller sind hier BEA, IONA, IBM.
Unsere Vorgehensweise in EAI Projekten Entwicklung, Implementierung Test der Softwarekomponenten Analyse Ermittlung des Bedarfs Konzept Entwicklung eines EAI -Konzeptes Auswahl der EAI-Werkzeuge Entwicklung Implementierung Inbetriebnahme Beratung Schulung Support Bedarfsanalyse Wie jedes Softwareentwicklungsprojekt beginnt auch ein EAI-Projekt mit der Analyse des Bedarfs, in diesem Fall in Bezug auf EAI. Dies geschieht im allgemeinen im Rahmen eines halb- bis zweitägigen Ken-Workshops. Dabei werden eine Bestandsaufnahme der Ist- Situation vorgenommen, die EAI-Problematik analysiert potenzielle Lösungsansätze aufgezeigt. Entwicklung eines EAI-Konzepts Im Anschluss an die Bedarfsanalyse wird, ebenfalls zum Teil in Ken-Workshops, ein EAI-Konzept (Vision) entwickelt. Es wird geklärt, welche Systeme eigene oder fremde zu integrieren sind. Die Integrationsebenen werden festgelegt der Architekturtyp wird definiert. Danach steht die einzusetzende Technologie fest es liegt eine Grobarchitektur vor. Auswahl der EAI-Werkzeuge Feinspezifikation der EAI-Architektur Anhand eines gemeinsamen Kriterienkatalogs Vorschläge dazu werden von uns unterbreitet werden die zur Implementierung der vorgeschlagenen Architektur benötigten EAI-Werkzeuge die jeweiligen Hersteller ausgewählt. Dieser Schritt entfällt, soweit bestimmte EAI- Werkzeuge bereits im Einsatz sind. Nachdem nun die Werkzeuge ihre Eigenschaften bekannt sind, wird die bis jetzt vorliegende Architektur weiter verfeinert. Im nächsten Schritt wird durch die Herstellung eines Prototyps die Zulässigkeit Tragfähigkeit der Architektur auch im Hinblick auf nicht-funktionale Anforderungen wie Performance, Sicherheit Verfügbarkeit verifiziert. Weiter werden Adapter entwickelt bzw. konfiguriert. Fehlende Softwarekomponenten werden individuell entwickelt. Es wird eine ausführliche Dokumentation aller Prozesse, Integrationskomponenten sowie der neuen Infrastruktur erstellt. Gleichzeitig werden bei Bedarf Schulungspläne unterlagen entwickelt Anwenderschulungen durchgeführt. Diese Phase endet mit den erfolgreichen System Abnahmetests. Inbetriebnahme Auch während nach der Inbetriebnahme stehen wir für Beratung Einsatzunterstützung zur Verfügung. Beispiele aus unseren Referenzprojekten Aufbau eines Internet-basierten Logistik-Systems: Tracking-& Tracing-Anwendung Anbindung aller Datenquellen ( timestamps ) über eine einheitliche XML-Schnittstelle, Datenexport B2B-Anbindung ebenfalls über XML Datenanlieferung- Integration über Data- Stage mit Konvertierung nach XML Performante Verarbeitung der XML-Daten über XML/Castor-Framework in Java Persistenz über EJB 2.0 JDBC
Anbindung an kommerzielle Rules-Engine (YasuTech) Anbindung an Ken-internes, Javabasiertes Präsentations-Framework Clusterfähige Java-Application auf der BEA Weblogic Server-Basis Entwicklung eines PDF-Reporting- Systems einer B2B-Schnittstelle auf Basis von Web-Services zur Anbindung an eine Basel II Rating-Anwendung Anbindung wurde generisch für zwei unterschiedliche Core-Anwendungen entwickelt Rein generativer Ansatz Generierung der technischen Dokumentation / B2B-Spezifikation aus Meta-Daten des Systems Komplett XML basiert PDF-Generierung über XSLT/FO Kernanwendung als Java-Application unter BEA WLS auf IBM Regatta Einsatz von Systinet WASP als B2B SOAP-Server Implementierung eines Web-Clients für ein Customer-Relationship-Management-System (CRM) Komplett XML-basiert Variabler Workflow, Mandantenfähigkeit Mehrsprachigkeit durch XML/XSLT Layer CRM (Java)-Application - Anbindung über Java auf Tuxedo BEA Weblogic Enterprise Komfortable PDF-Formular Generierung Internet-Client Internet-ClientXML/XSLT Layer BEA WLE Tuxedo & J2EE Clustered Application Server CRM Connector CRM-System PDF-Engine Oracle B2B-Zugang Reports Dialog Technical Documentation Engine for B2B (HTML) Meta- Data Rating Core-Anwendung Rating- B2B Reporting Applikation Interface Engine Web- (PDF) Frontend Rule- Engine- Data Interface J2EE Application Cluster DB2 Rating- Formeln DB2