11.07.2015 Aufrufe

Leitfaden “E- Business Erfolgreiches Management”

Leitfaden “E- Business Erfolgreiches Management”

Leitfaden “E- Business Erfolgreiches Management”

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

EAI – Enterprise Application Integration<strong>Leitfaden</strong> E-<strong>Business</strong><strong>Erfolgreiches</strong> Management20Thomas Winkeler, Ernst Raupach, Lothar WestphalEAI – Enterprise ApplicationIntegrationDie Pflicht vor der E-<strong>Business</strong>-Kür20


Die PricewaterhouseCoopers Unternehmensberatung GmbH ist ein Unternehmen der GruppePwC Deutsche Revision. PwC Deutsche Revision ist Mitglied von PricewaterhouseCoopers International,einer Company limited by guarantee, registriert in England und Wales.Autoren: Thomas Winkeler, Ernst Raupach, Lothar WestphalPricewaterhouseCoopers Unternehmensberatung GmbHFrankfurt am Main, Juni 2000Herausgeber:PwC Deutsche RevisionAktiengesellschaft WirtschaftsprüfungsgesellschaftAlle Rechte vorbehalten. Vervielfältigungen, Übersetzungen, Mikroverfilmungen, die Einspeicherungund Verarbeitung in elektronischen Medien sind ohne die Zustimmung des Verlages nicht gestattet.Gestaltung: H&J-Satz GmbH


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20Thomas Winkeler, Ernst Raupach,Lothar WestphalEAI – Enterprise ApplicationIntegrationDie Pflicht vor der E-<strong>Business</strong>-Kür


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20INHALT1. Einleitung 72. Aspekte der Anwendungsintegration 92.1 Mögliche Ziele der Anwendungsintegration und -tiefe 92.1.1 Integrationsbreite 92.1.2 Integrationstiefe 92.2 Wege zur Anwendungsintegration 112.2.1 Point-to-Point Verbindungen 122.2.2 ERP basierte Anwendungsintegration 132.2.3 Der Middleware-orientierte Integrationsansatz 152.3 Integrationsmechanismen 153. Enterprise Application Integration (EAI) 193.1 Der Lösungsansatz 203.2 Die Funktionale Betrachtung – die Vision von EAI 223.3 Mögliche Architekturen einer EAI-Lösung 273.3.1 Die „Hub-and-Spoke“-Architektur 273.3.2 Die Verteilte Architektur 293.4 Die Rolle von XML im Kontext der EAI-Diskussion 304. Betrachtungen zum EAI-Markt 314.1 Markttreiber 314.2 Markthemmnisse 344.3 Markterwartung 354.4 Anbieter/Produkte 365. Der Produktauswahlprozess 375.1 Das Schnittstellenproblem 375.2 Integrationsziele 385.3 Buy or Build? 396. Fazit 417. Literaturverzeichnis 433


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20ABBILDUNGSVERZEICHNISAbb. 1: Die Prozess-, Objekt-, und Datenebene 11Abb. 2:Beispiel einer Point-to-Point dominierten Netzwerkarchitektur(„Spaghettistruktur“) 12Abb. 3: Das ERP-System als Kernanwendung 14Abb. 4: Beispiel einer Hub-and-Spoke Architektur 21Abb. 5: Funktionale Übersicht einer EAI-Architektur 23Abb. 6: Der Adapter/Konnektor 24Abb. 7: Prozessmanagement 26Abb. 8: Eine EAI-Lösung in Hub-and-Spoke Architektur 28Abb. 9: Eine EAI-Lösung in verteilter Architekturumgebung 29Abb. 10:Kurzfristige Darstellung der Kosten einer EAI-Lösung inAbhängigkeit von der Anzahlzu integrierender Anwendungen 33Abb. 11: Die Markterwartungen 355


<strong>Leitfaden</strong> E-<strong>Business</strong> | 201. EINLEITUNGDas Thema Applikations- und Systemintegrationrückt immer dann inden Fokus der technologischen undbetriebswirtschaftlichen Betrachtung,wenn die Erweiterung, Migrationoder Erneuerung einer bestehendenSystemlandschaft diskutiert werden.Dies ist in Zeiten sich immerschneller ändernder Anforderungenan die Geschäftsprozesse immerhäufiger der Fall und hat insbesonderevor dem Hintergrund der Entwicklungenauf dem E-<strong>Business</strong>-Sektor einen neuen Höhepunkt erreicht.<strong>Erfolgreiches</strong> E-<strong>Business</strong> kannnur mit Geschäftsprozessen erreichtwerden, die sich durch hohe Geschwindigkeitund Flexibilität auszeichnen.Derartige Geschäftsprozessebenötigen Informationsflüsseohne Zeitverzögerungen, d.h. dieunterstützende IT muss hochgradigintegriert werden. Vor der E-<strong>Business</strong>-Kürbesteht insofern die Pflichtzur Integration und Konsolidierungder unternehmensweiten IT-Infrastruktur.Wird diese Pflicht bei den E-<strong>Business</strong>-Aktivitätenvernachlässigt, istfolgendes Szenario wahrscheinlich:Eine Kundenanfrage hat sich mitHochgeschwindigkeit über die weltweitenDatenautobahnen ihren Wegzum potentiellen Anbieter gesucht,da dieser bspw. über einen sehr eindrucksvollenWeb-Auftritt verfügt.Die Erfassung der Anfrage wirdkurzfristig durchgeführt, aber derInformationsfluss für die Bearbeitungder Anfrage oder eines Auftragsverliert sich in Batchläufenoder manuellen Schnittstellen. DerKunde sucht sich spätestens bei seinernächsten Anfrage einen Anbieter,der kurzfristiger reagiert.Die Zeitspanne zwischen Wahrnehmungeiner Kundenanfrage undihrer Befriedigung wird zu einemder wichtigsten Erfolgskriterien desE-<strong>Business</strong> werden.Unter dem Begriff EnterpriseApplication Integration (EAI)werden Technologien zusammengefasst,welche automatisiert die Kom-7


20| <strong>Leitfaden</strong> E-<strong>Business</strong>munikation und Interoperabilitätzwischen unterschiedlichen Anwendungenund Geschäftsprozessen innerhalbund zwischen Organisationenermöglichen. EAI-Lösungen ermöglichenes, einem nicht zuletztim Zuge der zunehmenden E-<strong>Business</strong>-Verbreitunggestiegenen undveränderten Integrationsanspruchgerecht werden zu können. Sie sindsomit den „E-<strong>Business</strong> EnablingTechnologies“ zuzuordnen.8


<strong>Leitfaden</strong> E-<strong>Business</strong> | 202. ASPEKTE DER ANWENDUNGSINTEGRATIONBevor die Funktionsweise vonEAI-Lösungen erläutert wird, werdenzunächst mögliche Ziele einerAnwendungs- bzw. Systemintegrationdargestellt. Ferner wird ein vereinfachterAbriss der historischenEntwicklung von Integrationsszenarieneinen Einblick in die Problematikder Anwendungsintegration geben.Den Abschluß dieses Abschnittesbildet ein Überblick über technologischeIntegrationsmechanismen.2.1 Mögliche Zieleder Anwendungsintegration:Integrationsbreite und -tiefeBei jeder Integrationsmaßnahmeist zunächst das Ausmaß der Veränderungzu definieren. Diese kanndurch die zu erreichende Integrationsbreiteund -tiefe beschriebenwerden.2.1.1 IntegrationsbreiteUnter Integrationsbreite verstehtman das Ausmaß, in dem Anwendungen,welche verschiedene Prozesseeines Unternehmens unterstützen,integriert werden.Die reine Integration der systemseitigenUnterstützung der C-Teile-Beschaffung wäre ein Beispiel fürgeringe Integrationsbreite, währenddie Integration aller die gesamteWertschöpfungskette unterstützendenSysteme eine maximale Integrationsbreitedarstellt. Mit zunehmenderIntegrationsbreite steigtfolglich die Komplexität der zu bewältigendenHerausforderung.2.1.2 IntegrationstiefeDie Integrationstiefe entsprichtdem Grad der semantischen Integrationund lässt sich in drei Ebenenunterteilen:●Integration auf Datenebene: Hierwird durch Einsatz von Datentransferprotokollendafür gesorgt,dass Daten von einem System inein anderes übertragen werdenkönnen. Die Integration auf Datenebenestellt den geringsten se-9


20| <strong>Leitfaden</strong> E-<strong>Business</strong>●mantischen Integrationsanspruchdar und kann in dem hier diskutiertenZusammenhang als dieeinfachste Form der Integrationbezeichnet werden.Verwendet man für die Darstellungder Systemintegration dasBild eines Engländers und einesFranzosen, die sich unterhaltenwollen, so würde auf der Datenebenegewährleistet sein, dassbeide Gesprächsteilnehmer sowohlsprechen als auch jedes Wort desanderen hören könnten. Integrationauf Datenebene bedeutet jedochnoch nicht, dass sie einanderauch verstehen können.●Integration auf Objektebene:Folgen wir unserer bildlichenDarstellung, geht es auf derzweiten und damit nächst höherenEbene der semantischen Integrationdarum, dass die übertragenenWörter vom Angesprochenenauch verstanden werden. Inder systemtechnischen Welt werdenzu diesem Zweck sog. Objektedefiniert. Ein Objekt bestehtaus Daten und einer standardisiertenSchnittstelle, densog. Methoden, mit denen auf dieDaten zugegriffen werden kann.In einem Geldinstitut könnte manz.B. das Objekt „Kundenkonto“definieren, welches die DatenKontonummer, Kontoinhaber, Kontostandetc., beinhaltet, auf diedann mittels der Methoden„Kontostand auslesen“, „Kontostandändern“ etc. zugegriffenwerden kann.Integration auf Prozessebene:Die Integration auf Prozessebeneumfasst die anspruchsvollste Variantesemantischer Integrationsmaßnahmen.Diese beschreibtdie Unterstützung von Prozessen,in deren Verlauf ggf. verschiedeneObjekte be- und verarbeitetwerden. Im Bild der miteinandersprechenden Personen heißt das,die verstandenen Worte und Sätzewerden nun in einen Kontextgebracht, um konkrete Kommunikationszielezu verfolgen. Beispielsweisekann der gesprocheneSatz „das Ergebnis bewerte10


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20ich positiv“ im Kontext der Diskussioninterpretiert werden.In Abb. 1 sind die drei Ebenenschematisch dargestellt. Eine vollständigeEAI-Lösung deckt die gesamteIntegrationstiefe ab. ZumVergleich ist auch die Abdecktiefeherkömmlicher Middleware-Produktedargestellt.InformationsaustauschGemeinsameMetadatenLösungIntegration aufProzeßebeneBedeutungProzeßdefinitionWert der IntegrationIntegration aufObjektebeneMessagesVokabularEAIIntegration aufDatenebeneBitsDatentransferprotokollMiddlewareAbb. 1: Die Prozess-, Objekt-, und Datenebene (Quelle Ovum 1999)2.2 Wege zur AnwendungsintegrationDie Integration der internen Anwendungenkann bis hin zur umfassendenProzessunterstützung überunterschiedliche Wege realisiertwerden. Die Realität zeigt vieleMischformen der folgenden Szenarien,zumal die Integration im Allgemeinennicht auf einmal, sondernin mehreren Schritten durchgeführtwird. Im Folgenden werden zweiBeispiele auf dem Weg der historischenEntwicklung von Integrationsbestrebungenaufgegriffen und dargestellt.11


20| <strong>Leitfaden</strong> E-<strong>Business</strong>2.2.1 Point-to-Point VerbindungenAls Point-to-Point Verbindungwird eine Verbindung zwischenzwei gleichberechtigten Systemenbzw. Anwendungen bezeichnet. ZurIntegration mehrerer Systeme bzw.Anwendungen besteht also jeweilseine eigene Verbindung. Abb. 2zeigt eine Point-to-Point dominierteNetzwerktopologie.Abb. 2: Beispiel einer Point-to-Point dominierten Netzwerkarchitektur („Spaghettistruktur“)Diese Architektur ist häufig dasResultat von im Zeitablauf gewachsenenStrukturen im Sinne regelmäßigerErgänzung der Systemlandschaftum weitere Applikationenund Anwendungen. Mit anderenWorten ist die vorhandene Systemlandschaftzu keinem Zeitpunktumfassend neu organisiert worden,vielmehr wurden neue Systeme indie bereits existierende Architektureingefügt.12


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20Die Nachteile dieses Ansatzessind u.a.:Geschwindigkeit der Informationsflüssein Verbindung mit der Bereitstellungvon Daten in Echtzeitund●●●●●●hoher Betriebsaufwand für dieWartung der Schnittstellenhoher Aufwand bei der Integrationzusätzlicher Anwendungensuboptimale Nutzung der Ressourcendas oftmals entstehendes „Spaghettisystem“macht eine reibungsfreieIntegration der Informationteilweise unmöglichinhomogene und inkonsistenteDatenzeitliche Verzögerungen bei derDatenbereitstellung● Flexibilität bei der Integrationneuer Anwendungenkann eine Point-to-Point Anbindungaufgrund ihrer Komplexität in Verbindungmit der Vielzahl vonSchnittstellen nur in seltenen Ausnahmengenügen.2.2.2 ERP basierte AnwendungsintegrationSehr große Fortschritte bei derAnwendungsintegration haben vieleUnternehmen in den letzten Jahrenmit der Einführung von ERP-Systemenvon SAP, Peoplesoft, Oracleu.a. erzielt. Diese Systeme unterstützenhäufig wesentliche Geschäftsprozesse.Den E-<strong>Business</strong>-Anforderungen●Es ist jedoch davon auszugehen,dass auch zukünftig selten mehr alsvierzig Prozent der benötigten Anwendungsunterstützungdurch ERP-Systeme abgedeckt werden 1 . Bran-1 Vgl. Conspectus 1999, EAI-Report13


Web20| <strong>Leitfaden</strong> E-<strong>Business</strong>chen- oder unternehmensspezifischeAnforderungen werden durch spezielleLösungen ergänzt. Außerdemzeigt sich, dass neue Anbieter, diesich auf die Unterstützung speziellerProzesse konzentrieren, in derLage sind, schneller auf neuartigebranchenübergreifende Anforderungenzu reagieren. Daher ist nicht zuerwarten, dass die IT-Anforderungenin Zukunft ausschließlich durchERP-Systeme abgedeckt werdenkönnen. Vielmehr werden diese Systemebei vielen Unternehmen indie Rolle einer Kernanwendunghineinwachsen. Ergänzend zu denERP-Systemen werden Einzelanwendungenfür bestimmte Bedarfeerhalten bleiben. Diese Situationwird in Abb. 3 schematisch dargestellt.Custom Built…ERPDWCRMAbb. 3: Das ERP-System als KernanwendungDer ERP-basierte Integrationsansatzist im Zweifel nur dann ausreichend,wenn zwischen den Satellitenanwendungenkein direkter Informationsaustauschbenötigt wird.Ist diese Voraussetzung gegeben,stellt der abgebildete Ansatz eineLösungsmöglichkeit dar, die imHinblick auf die zunehmende Öffnungder ERP-Systeme durch wei-14


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20tere standardisierte Schnittstellendurchaus attraktiv ist. Sollen jedochSysteme in den Informationsflussmit aufgenommen werden, die zusätzlichdirekt miteinander kommunizierenmüssen, entsteht häufigeine unübersichtliche IT-Landschaftmit einer hohen Anzahl von Schnittstellen.Die Ergebnisse solcher Integrationsversuchesind dann für eineerfolgreiche E-<strong>Business</strong> Strategieggf. nicht ausreichend.2.2.3 Der Middleware-orientierteIntegrationsansatzKlassische Middlewareprodukteverfolgen den Ansatz, die Integrationverschiedener Systeme in relativstandardisierter Form zu ermöglichen.Middlewareprodukte werdenzwischen zwei oder mehrere Systemegeschaltet und ermöglichen es,Systemen und Anwendungen unterschiedlicherHersteller ggf. plattformunabhängigzu kommunizierenund Daten auszutauschen. Middlewareproduktewerden vielfach inder oben dargestellten Point-to-Point-integrierten Systemlandschaft(Point-to-Point Middleware) eingesetzt.Das Leistungsspektrum vonMiddlewareprodukten erstreckt sichim wesentlichen auf die Integrationauf Datenebene (siehe Abb. 1).Eine Weiterentwicklung derMiddlewareprodukte stellen dieMessage Broker dar, mit deren Hilfedie Objektintegration über mehrererSysteme ermöglicht wird. Hierkönnen an zentraler Stelle Formatierungs-oder Geschäftsregeln hinterlegtwerden.2.3 IntegrationsmechanismenEs existiert eine Vielzahl vonMechanismen, um die Übertragungvon Informationen zwischen verschiedenenSystemen, Applikationenund Anwendungen zu realisieren.Im folgenden werden die dreiam häufigsten diskutierten Kategorienexistierender Integrationsmechanismenerläutert. Diese sind inder Praxis vielfach als Mischformenanzutreffen.15


20| <strong>Leitfaden</strong> E-<strong>Business</strong>MessagingDie Übertragung von Informationenerfolgt durch den Versand vonsog. Messages (vgl. zu Messagesden Abschnitt Integrationstiefe).Die Integration via Messaging basierti. d. R. auf asynchroner Kommunikationin einer verteilten Systemumgebung.Ein bekanntes Beispiel für dieseArt von Kommunikation stellt dasProdukt MQSeries von IBM dar.Ein Quellsystem schreibt einen Datensatzin seine Output-Warteschlange(„Queue“). MQSeries liestdiese „Queue“ aus und stellt denDatensatz in die „Input-Queue“ desZielsystems. Dieses liest dann seine„Queue“ in Echtzeit oder zeitverzögertaus.Datenzugriff und FiletransferEin Beispiel für die Integrationdurch Datenzugriff stellen Leseund/oderSchreibzugriffe auf eineentsprechende Datenbank dar. Beispiel:Das ausgelagerte Call-Centereiner Unternehmung benötigt Zugriffauf Kundendaten. Der vomCall-Center verwendeten Applikationwird dann eine Kundendatenbankzur Verfügung gestellt, aufwelche sie direkt zugreift. DieseDatenbank wird dann ggf. durch Replikationsmechanismenoder Batch-Routinen mit der zentralen Kundendatenbankabgeglichen.Ein einfaches Beispiel für Filetransferbesteht in der Ablage einerDatei auf einem Netzwerkverzeichnisdurch Mitarbeiter A und dasHerunterladen dieser Datei durchMitarbeiter B.Call InterfacesApplikationen stellen sog. CallInterfaces („Aufruf-Schnittstellen“)bereit. Diese werden auch als ApplicationProgramming Interfaces(API) bezeichnet und beinhalten●Objektschnittstellen (u. a. COM,CORBA, Java Beans),16


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20●Schnittstellen für Packaged Applications(u. a. SAP BAPI) oder● Transaktionsschnittstellen (u.a.IBM CICS, BEA Tuxedo).Das folgende Beispiel soll diegenerelle Funktionsweise der CallInterfaces erläutern: Applikation Astellt bestimmte Funktionen (z.B.Datei speichern oder Datei drucken)zur Verfügung. Applikation B ruftdiese Funktion über die existierendeSchnittstelle (Call Interface) auf,greift diese ab und nutzt die Funktionin der Applikation B.Der wesentliche Vorteil bestehtdarin, dass die Funktionsintegrationin Echtzeit erfolgen kann. Der Nachteilbesteht in z.T. komplexen Programmieraufwendungenfür die entsprechendeRealisierung.17


<strong>Leitfaden</strong> E-<strong>Business</strong> | 203 ENTERPRISE APPLICATION INTEGRATION (EAI)Der vorherige Abschnitt hat verdeutlicht,dass mit dem Thema Anwendungsintegrationeine sehr komplexeHerausforderung verbundenist. In diesem Zusammenhang istfestzustellen, dass die Anforderungenan Integrationsunterstützunginsbesondere vor dem Hintergrundfolgender Trends kontinuierlich ansteigen:●●E-<strong>Business</strong> setzt integrierte Prozessevoraus, die einen Datenaustauschzwischen Unternehmengewährleisten.Datenintegration in Real-time anstellevon Datenaustausch undReplikationsmechanismen bringtGeschwindigkeitsvorteile.● Globale Vernetzung erfordert 24-Stunden-Verfügbarkeit der beteiligtenSysteme bzw. Daten.●●●●●Immer kürzere Realisierungszyklen:die funktionalen Anforderungenmüssen zeitnah umgesetztwerden.Die Zahl zu integrierender Blackbox-Softwarepaketewächst.Der technologische Anspruch anRealisierungsvorhaben ist spürbarangestiegen.Prozess- und Systemlebenszyklenwerden zunehmend verkürzt.Neue technologische Trends müsseneffizient integrierbar sein.EAI-Produkte bieten einen hochentwickeltenLösungsansatz zur Bewältigungder hier dargestelltenHerausforderung und ermöglichengleichzeitig eine spürbare Komplexitätsreduzierung.●Ständige Veränderung der Geschäftsprozesse,die eine Integrationin neue oder bestehende Applikationenerfordern.Die folgende Darstellung des generellenLösungsansatzes wird durcheine detaillierte funktionale Betrachtungvon EAI-Produkten ergänzt.Erläuterungen hinsichtlich der phy-19


20| <strong>Leitfaden</strong> E-<strong>Business</strong>sikalischen Systemarchitektur, welcheeiner EAI-basierten Lösung zugrundeliegt,schließen diesen Abschnittab.3.1 Der LösungsansatzEAI-Lösungen sind Softwareprodukte,die es Individualentwicklungenund/oder standardisierten Geschäftsapplikationenvollständig oderteilweise ermöglichen, automatisiertgeschäftsrelevante Informationen ineinem Format und Kontext auszutauschen,das von den betroffenenSystemen verstanden wird.Der Lösungsansatz einer EAI-basiertenSystemlandschaft baut daraufauf, die Kommunikation zwischenverschiedenen Systemen undAnwendungen innerhalb einer Systemlandschaftu.a. durch Standardisierungder Schnittstellenkonzeptionzu vereinfachen und zu beschleunigen.Eine vollständige EAI-Lösung bietetferner einen Prozesssteuerungsmechanismus,welcher die zentraleKoordination der entsprechendenTransaktionen übernimmt. Darüberhinaus besteht ein wesentlichesMerkmal von EAI-Lösungen darin,dass unter Verwendung dieser speziellentwickelten Produkte Integrationsmaßnahmendurchgeführt werdenkönnen, ohne dass dabei die zuintegrierenden Systeme selbst verändertwerden müssen. Anbieter bezeichnendieses Attribut als „Non-Invasive“.Die Lösungskonzeption lässt sicham einfachsten am Beispiel einerHub-and-Spoke Architektur erläutern.Obgleich verschiedene architektonischeRealisierungsmöglichkeitenfür EAI bestehen (Siehe Abschnitt5), zählt die im folgendenDargestellte zu den häufigsten:Beispiel:Die Hub-and-Spoke-ArchitekturEntgegen der in Abschnitt 2 dargestelltenLogik einer Point-to-Point basierten Systemlandschaftfußt die Konzeption einer Hub-and-Spoke basierten EAI-Lösung dar-20


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20auf, alle Anwendungen und Systemegleichberechtigt mit einer zentralenInformationsdrehscheibe zuverbinden. Diese Informationsdrehscheibe,über die alle Kommunikationswegeder einzelnen Anwendungenlaufen, wird als Hub-and-Spoke-(Nabe und Speiche)-Architekturbezeichnet.So wird im Vergleich zum zuvorgezeigten ERP-basierten Integrationsansatzauch das ERP-Systemnur als eine unter mehreren Anwendungenangesehen, welches wie alleanderen an den zentralen Hub angeschlossenist.Abb. 4 zeigt schematisch eineHub-and-Spoke Architektur:ERP 2ERP 1DWCRMEAIWeb…SCMLegacyAbb. 4: Beispiel einer Hub-and-Spoke Architektur21


20| <strong>Leitfaden</strong> E-<strong>Business</strong>Mit einer EAI-basierten Systemarchitektursind die folgenden Vorteileverbunden:●●●●●●●●Klare Verantwortlichkeiten für InformationsobjekteMinimale Anzahl von SchnittstellenEindeutige, definierte SchnittstellenEinheitliches SchnittstellenmanagementOrientierung an Unternehmensprozessenstatt an Systemen, Applikationenund DatenbankenIsolierte Einführung, Änderungoder Ablösung von SystemenMöglichkeit der Einbindung bestehenderSystemeStufenweise und teilweise Realisierungvon IntegrationsvorhabenWelche Funktionen im Detail fürdie Realisierung der Lösungskonzeptionerforderlich sind, wird imfolgenden Abschnitt dargestellt.3.2 Die Funktionale Betrachtung– die Vision von EAIEAI-Produkte stellen eine Erweiterungklassischer Middlewareproduktedar. Während unter Verwendungvon Middleware-Produkten vornehmlichdie Verbindung von Applikationenauf Daten- und Objektebenerealisiert wird (Point-to-PointMiddleware oder Message Broker),erfolgt der Einsatz von EAI-Produktenim Integrationsumfeld multiplerApplikationen und unter Verwendungvon Prozesssteuerungsmechanismen.Damit erweitert EAI dasLeistungsspektrum klassischer Middlewareum die Integration auf ObjektundProzessebene und damit auf diesemantische Integration über dreiStufen.Abb. 5 zeigt den Aufbau einervollständigen EAI-Lösung:22


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20Management ServicesEntwicklungsunterstützungProzessmanagementTransformationAdapterMiddlewareAbb. 5: Funktionale Übersicht einer EAI-ArchitekturIm folgenden werden die einzelnenBausteine einer EAI-Lösungdargestellt:Die AdapterPotentielle Integrationsobjektesind Packaged Applications, Datenbanken,Dateien, Individualapplikationen,Middleware etc. Vor diesemHintergrund stellt sich bei der Realisierungvon Integrationsszenarienzunächst die Frage, wie die Kommunikationzwischen verschiedenenSystemen auf der physikalischenEbene realisiert werden kann. Hierzuwerden sog. Konnektoren oderAdapter verwendet, welche die Art,wie Zugang und Interaktion mit denIntegrationsobjekten erfolgen, „normalisieren“.Der Adapter eines Herstellersunterstützt dabei vorgefertigtden Verbindungsaufbau vomEAI Run-time System zum angebundenenSystem. Vereinfacht gesprochenhandelt es sich bei denAdaptern um standardisierte Schnittstellen,welche die Kommunikationzwischen der EAI-Software und derjeweiligen Applikation durch Zwischenschaltungsicherstellen. MancheEAI-Lösungen halten bis zu23


20| <strong>Leitfaden</strong> E-<strong>Business</strong>150 unterschiedliche Adapter vorund ermöglichen damit die Kommunikationmit allen gängigen Systemenund Anwendungen.Dieser Sachverhalt ist in Abb. 6schematisch dargestellt:CoCoApplication 1nneEAIRun-time-SystemnneApplication 2ccttoorrAbb. 6: Der Adapter/KonnektorEin wesentlicher Vorteil bei derVerwendung dieser Adapter liegtdarin, dass die Exportschnittstelledes zu integrierenden Systems nichtverändert werden muss, um dieKommunikation mit der „Außenwelt“gewährleisten zu können.Die zentrale MiddlewareDie Middleware, als ein Bestandteilder EAI-Lösung, unterstützt dieIntegration auf Datenebene. Informationenwerden aus einer Applikationunter Verwendung der Adapterextrahiert und in eine andere übertragenund umgekehrt. Die Middle-24


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20ware regelt die Art, wie diese Kommunikationerfolgt (synchron oderasynchron). Ferner steuert dieMiddleware die Adressierungsmechanismen(Point-to-Point, broadcast/multicastoder publish-and-subscribe)und unterstützt unterschiedlicheSicherheitsanforderungen.Der Transformations ServiceTransformationsdienste unterstützendie Integration auf Objektebene.Hier werden die bereitgestellten Datenin Formate umgewandelt, welchedas Zielsystem interpretierenkann. Neben der reinen Transformationsleistungerfolgt hier die Identifikationund Validierung von Informationsflüssen.Zur Identifikationder eintreffenden Informationen stehenu.a. Repositories über Metadaten(Kataloge zur Datenbeschreibung)zur Verfügung.Synchronisierungsdienste steuernauf der Transformationsebene denzeitlichen Ablauf bzw. das zeitlicheZusammenspiel bei der Abarbeitungvon Transformationen im Sinne vonTransaktion A kann erst beginnen,wenn Transaktion B bereits erfolgreichausgeführt wurde. Der Outputder Transformationsdienste muss –ggf. auch in Abhängigkeit vom Inhaltder Message – an unterschiedlicheZielsysteme versandt werden.Routing Services unterstützen dies.Transaction Processing Services,als ein weiterer Bestandteil des Transformationsdienstes,überwachen undunterstützen die Durchführung, Vollständigkeitund Konsistenz bei komplexen,ggf. mehrere Systeme betreffendenOperationen.Das ProzessmanagementDer Prozessmanagement-Servicestellt ein Kernstück jeder EAI-Lösungdar. Hier wird das automatischeZusammenspiel komplexerTransaktionen basierend auf entsprechendenGeschäftsprozessen definiertund gesteuert. So kann beispielsweiseeine vollständige undkomplexe Auftragsbearbeitung überverschiedene Systeme hinweg automatisiertwerden.25


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20Management ServicesDer Management Service unterstütztdie Administration des EAI-Systems.Er verwaltet außerdem die Metadatenspeicherungsowie das sog.Load Balancing. Insbesondere diezunehmende Nutzung des Internetsresultiert in teilweise unkalkulierbarerTransaktionslast. Load Balancingverteilt die Arbeitslast je nachSystemauslastung auf verschiedeneServer, um die Überlastung einzelnerServer zu verhindern. Der gleicheMechanismus greift dann, wenneiner von mehreren Servern ausfallensollte.Der Management Service bietetweiterhin die Möglichkeit, die einzelnenServices – architektonischgesehen – an unterschiedlichen Stellenzu stationieren und zu steuern.3.3 Mögliche Architektureneiner EAI-LösungDie Funktionsbausteine einerEAI-Lösung können architektonischauf verschiedene Weisen angeordnetwerden. Im folgenden wird aufdie zwei am häufigsten ausgewähltenarchitektonischen Varianten, dersog. „Hub-and-Spoke“- sowie derverteilten oder „Federated“-Architektur,eingegangen.3.3.1 Die „Hub-and-Spoke“-ArchitekturDie Mehrzahl der EAI Lösungenbasiert, wie im Abschnitt 3.1 skizziert,auf einer Hub-and-Spoke Architektur,d. h. alle integrierten Anwendungensind über eine zentraleSchnittstelle, den sog. „Hub“, miteinanderverbunden (siehe Abb. 8).Als Hub kann hier z.B. ein ApplicationServer verwendet werden.Transformationsfunktionen sowiedas Prozessmanagement werden indiesem Falle ebenfalls zentral verwaltet.27


20| <strong>Leitfaden</strong> E-<strong>Business</strong>Trading & ReportingBackoffice TradingMarktdatenReportingAuftragsabwicklungAbrechnungClearing & SettlementAdapterMiddlewareMiddlewareAdapterProzessmanagementTransformationMiddlewareAdapterMiddlewareMiddlewareAdapterWertpapiergesellschaftAuftrags- undHandelsabwicklungWertpapiergesellschaftBestandsführungBuchhaltungAbb. 8: Eine EAI-Lösung in Hub-and-Spoke Architektur●●Vorteile dieser Architektur sind:Minimale SchnittstellenanzahlZentrale und damit redundanzfreieProzessverwaltungFolgende Nachteile können sichergeben:●Performance- und Verfügbarkeitsengpässein der zentralen Schnittstelle●Einheitliche, funktionsgruppenübergreifendeProzessabbildung●Keine flexible Prozessanpassungeinzelner verbundener Funktionseinheiten28


<strong>Leitfaden</strong> E-<strong>Business</strong> | 203.3.2 Die Verteilte ArchitekturHier werden die Transformationsfunktionensowie das Prozessmanagementdezentral, d. h. auf dieintegrierten Funktionseinheiten aufgeteilt,verwaltet (siehe Abb. 9).Zwischen den einzelnen Anwendungenwerden je nach Integrationsbedarfdirekte, einheitlich definierteSchnittstellen geschaffen.Trading & ReportingBackoffice TradingMarktdatenReportingAuftragsabwicklungAbrechnungClearing & SettlementProzessmanagementTransformationProzessmanagementTransformationAdapter Middleware Middleware AdapterProzessmanagementTransformationProzessmanagementTransformationAdapterMiddlewareMiddlewareAdapterWertpapiergesellschaftAuftrags- undHandelsabwicklungWertpapiergesellschaftBestandsführungBuchhaltungAbb. 9: Eine EAI-Lösung in verteilter ArchitekturumgebungDie Vorteile:●Eine flexiblere Reaktion auf Performance-und Verfügbarkeitsanforderungenist möglich.●Die integrierten Funktionseinheitenkönnen ihre Geschäftsprozesseselbständig und von den anderen„unsichtbar“ („gekapselt“)verwalten, was z.B. bei der Sys-29


20| <strong>Leitfaden</strong> E-<strong>Business</strong>temintegration über verschiedeneUnternehmen zum Tragen kommt.3.4 Die Rolle von XML imKontext der EAI-DiskussionDie Nachteile dieser Architekturliegen in● höherem Implementierungsaufwand,●●größerer Anzahl Schnittstellensowieggf. redundanter TransformationsundProzessverwaltung.In jedem Falle gilt: Soll ein Teilder Prozesskette durch neue Anwendungenoder Hardwarekomponentenunterstützt werden, müssen wederdie Transformationsdienste nochdas Prozessmanagement angepasstwerden. Dies wird nur bei einer Änderungder Geschäftsprozesse notwendig,was wiederum nicht unbedingteine Anpassung der unterstützendenAnwendungen erfordert.XML ist eine Strukturbeschreibungssprache,die zum Datenaustauschin heterogenen Umgebungenverwendet wird. Die Standardisierungdes Sprachumfangs ermöglichtdie Interoperabilität der Anwendungenverschiedener Anbieter. Datenwerden inkl. ihrer Metadaten alsXML-Dokument versendet undvom Zielsystem interpretiert. Esgibt mittlerweile viele Programmbibliothekenzum Parsen, Konvertierenund Darstellen von XML-Dokumenten.Im Kontext der EAI-Diskussionerleichtert der XML-Standard dieKommunikation zwischen Systemeninsbesondere vor dem Hintergrundder Datenidentifizierung und -validierungim Rahmen der Transformationsdienste.Hier ist jedoch festzustellen,daß XML keinesfalls dieFunktionen und Aufgaben einervollständigen EAI-Lösung ersetzenkann.30


<strong>Leitfaden</strong> E-<strong>Business</strong> | 204 BETRACHTUNGEN ZUM EAI-MARKT4.1 MarkttreiberDie Einführung von EAI-Produktenwird aus unterschiedlichenGründen in Erwägung gezogen.Hier sind nicht nur die unmittelbarenE-<strong>Business</strong>-Notwendigkeiten zubetrachten; auch ohne aktuelle E-<strong>Business</strong>-Vorhaben gibt es guteGründe, in die Anwendungsintegrationzu investieren:●Kostenersparnis gegenüber Eigenentwicklungen.Geschäftsprozessoptimierung:Schnellere Verfügbarkeit fehlerfreierDaten sowie hoher Automatisierungsgradder Datenverarbeitungschaffen Optimierungspotentialeund die Möglichkeitzur kontinuierlichen Geschäftsprozessoptimierung.●●●Investitionsschutz: Unternehmen,die sehr viel Geld in die Jahr-2000-Fähigkeit investiert haben,wollen diese Systeme nun auchüber die nächsten Jahre erhalten.Operative Integration von Unternehmennach Fusionen oderÜbernahmen: Hier kann einEAI-Ansatz zu erheblichen Einsparungenbei der IT-Integrationführen.Integration extern entwickelterBlack-Box Software: Es bestehtein gesteigerter Bedarf an externentwickelter „Black-Box Software“aufgrund der Zeit- und●●„Best of Breed“-Ansatz: Ausstrategischer Sicht ermöglichenEAI-Produkte bzgl. der Auswahlvon EDV-Systemen die Lösungvon der Anbietermacht einzelnerHersteller und die Auswahl der„besten Lösung der Art“ für diejeweiligen Anforderungen.Zeitersparnis bei der Einführungneuer Systeme: Produkteund Dienstleistungen, deren Bereitstellungdurch die jeweiligenSysteme unterstützt werden, könnenschneller auf den Markt gebrachtwerden; die Unternehmenkönnen somit schneller auf Veränderungenam Markt reagieren.31


20| <strong>Leitfaden</strong> E-<strong>Business</strong>●●Kostensenkungen durch zentraleSchnittstellenverwaltung:siehe ROI-Betrachtung in Kapitel5.1.1Unterstützung des E-<strong>Business</strong>:Der Kunde wird nur dort seineWare über das Internet bestellen,wo die Bestellung unkompliziertund schnell abgewickelt wird.Dieser Forderung nachzukommen,ist bei steigender Konsumentenzahlunter Beibehaltungder „herkömmlichen“ IT-Infrastrukturund den zugrundeliegendenIntegrationsansätzen häufignicht möglich. Erst skalierbareund hochgradig integrierte Systemeermöglichen den heutzutagegeforderten Informationsflussohne Zeitverlust.Der Return on InvestmentBei der Entscheidung, ob einEAI-System eingeführt werden soll,spielt das Kosten-/Nutzenverhältniseine entscheidende Rolle.Kurzfristig können bei Nutzungeines EAI-Systems Einsparungenvor allem durch die deutliche Verringerungder Schnittstellen realisiertwerden. In Abb. 8 sind die Kosteneiner Point-to-Point- und einerEAI-basierten IT-Architektur alsFunktion der Anzahl zu integrierenderAnwendung gegenübergestellt.Im Bereich 1 liegen die kurzfristigenKosten für eine EAI-Lösungaufgrund hoher Anfangsinvestitionenüber denen einer Point-to-Pointdominierten Architektur. Ab einergewissen Anzahl von Anwendungenist jedoch auch kurzfristig eineEAI-Lösung kostengünstiger (Bereich2).Während zur vollständigen Integrationvon n Anwendungen in Pointto-Point-Topologien(n-1) Schnittstellenexistieren, reduziert sich dieseAnzahl in Hub-and-Spoke-Topologieauf n. Das heißt, dass Einsparungspotentialwird umso größer,je mehr Anwendungen zu integrierensind.32


<strong>Leitfaden</strong> E-<strong>Business</strong> | 204.3 MarkterwartungDer prognostizierte Marktanteilvon EAI an den gesamten Ausgabenfür Integrationssoftware und -dienstleistungenwird Analysten zufolgein den kommenden Jahren überproportionalsteigen. Abb. 9 zeigt einePrognose von Ovum, welche einMarktvolumen von etwa 30 MilliardenUS $ im Jahre 2004 voraussagt.MilliardenUS-$120Ausgaben für Integrationssoftware- und -dienstleistungen100EAI8060Rest4020019992004Abb. 11: Die Markterwartungen (Quelle Ovum 1999)Potentielle Projektinhalte umfassendabei alle Phasen einer EDV-Einführung mit den SchwerpunktenIT-Infrastruktur sowie Hard- undSoftwareschnittstellen.Darüber hinaus setzt eine EAI-Realisierungsmaßnahme die gründlicheAnalyse und Modellierung allerbetroffenen Geschäftsprozessevoraus. Hier eröffnen sich vielfachPotentiale für eine Geschäftsprozess-35


20| <strong>Leitfaden</strong> E-<strong>Business</strong>optimierung („Performance Improvement”).4.4 Anbieter/ProdukteDie Angebotsseite des EAI-Marktes ist sehr breit gefächert. VonMarktdominanz einzelner Anbieterkann derzeit noch nicht gesprochenwerden. Eine Vielzahl von Anbieternverschiedener Herkunft bietenProdukte unter dem EAI-Label an.Dabei reicht die Herkunft der Anbietervom Lieferanten klassischerMiddleware bis hin zu Anbieter fürExtract-Transform-Load-Werkzeugeaus dem Bereich Datawarehouse.Laut einer Studie von Forrester(1999) wird in den nächsten Jahrenmit einer deutlichen Marktbereinigungin Form eines Konzentrationsprozessesgerechnet.36


<strong>Leitfaden</strong> E-<strong>Business</strong> | 205 DER PRODUKTAUSWAHLPROZESSDie Stärken und Schwächen derverschiedenen EAI-Lösungen variierenmit dem Integrationsszenariound beeinflussen insofern den Produktauswahlprozess.Das Integrationsszenarioist einerseits dadurch gekennzeichnet,welches Schnittstellenproblemgelöst werden soll undwird andererseits durch den Gradder semantischen Integrationsanforderungbeschrieben.5.1 Das SchnittstellenproblemBei der Integration bereits bestehenderEDV-Systeme stößt man inder Praxis auf unterschiedliche Artenvon Schnittstellen.Beispielhaft sind im folgendendrei Schnittstellenszenarien beschrieben:●Schnittstellen zu Packaged Applications:Unter Packaged Applicationsversteht man Softwarepakete,die größtenteils fertig programmiertgekauft werden unddurch die Einstellung von Parametern(das sog. Customizing)●●auf spezifische Anforderungenangepasst werden. Ein Standardbeispielist das R/3-System vonSAP. Packaged Applications sindi.d.R. mit genau definierten unddokumentierten Schnittstellen ausgestattet,an die sich relativ problemlosKonnektoren „andocken“lassen.Schnittstellen zu passiven Ressourcen:Passive Ressourcen(z.B. ein Datenspeicher) werdenim allgemeinen von einem Betriebssystemgesteuert. Hier kannder Konnektor an den Schnittstellendes Betriebssystems ansetzen.Schnittstellen zu Custom-builtApplications: Custom-built Applicationssind Eigenentwicklungendes Unternehmens oder einesexternen Dienstleisters, die meistsehr spezifische Anforderungenabdecken, für die keine Standardsoftwareexistiert. Hier gibtes oft keine definierten Beschreibungender Schnittstellen, wasdie Integration von Custom-builtApplications erschwert.37


20| <strong>Leitfaden</strong> E-<strong>Business</strong>5.2 IntegrationszieleDie Produktauswahl sollte wiebei allen IT-Projekten maßgeblichvon den Integrationszielen abhängen,welche vor der Auswahl derProdukte sorgfältig und vollständiganalysiert werden sollten.Bei einem Integrationsszenario,dessen semantischer Schwerpunktauf dem Austausch von Informationenauf Datenebene liegt, sollte einProdukt gewählt werden, das einenleistungsfähigen Adapter für alle zuintegrierenden Systemen beinhaltet.Dieses Szenario ist häufig dann anzutreffen,wenn der Datenaustauschzwischen Standardsoftwareproduktenrealisiert werden soll. Beispiel:der SAP-Zugriff auf eine OracleDatenbank.Produkte für eine Objektintegrationmüssen neben Adaptern füralle zu integrierenden Systeme übereinen hoch entwickelten Transformationsserviceverfügen. Ein typischesSzenario für diese Form derIntegration bietet der Austausch vonKundendaten über mehre Systeme(zentrale Kundendatenbank,Call-Center,Auftragsbearbeitung etc.) hinweg.Die soeben genannten Integrationsszenarienwerden bislang primärvon klassischen Middlewareproduktenabgedeckt.Sollen auch die Geschäftsprozesseabgebildet werden, wird vonden eingesetzten Produkten Prozessmodellierungs-und Managementunterstützungüber unterschiedliche,heterogene Systeme verlangt. EinBeispiel stellt hier die elektronischeAuftragsbearbeitung dar. In diesemProzessverlauf werden Informationenaus unterschiedlichen Systemen(Bonitätsprüfung, Lagerbestände,Rabattinformationen etc.) abgefragtund in der Prozesskette verarbeitet.Die Prozessintegration stellt hoheAnforderungen an die semantischeIntegrationsfähigkeit der Lösung undkann insofern als das eigentlicheSpielfeld der EAI-Anbieter bezeichnetwerden.38


<strong>Leitfaden</strong> E-<strong>Business</strong> | 20Sollen Prozessketten über mehrereUnternehmen hinweg integriertwerden, ist zusätzlich ein hoher Standardisierungsgradnotwendig, der dieIntegration vielfältiger Teile der Gesamt-IT-Infrastrukturggf. über Unternehmensgrenzenhinweg gewährleistet.oder werden die derzeitigen Anforderungennicht durch fertige Softwarepaketeabgedeckt, muss einentsprechend größerer Eigenleistungsanteilerbracht werden. Fürdiesen Fall bieten viele HerstellerEntwicklungshilfen („Toolkits“) an.5.3 Buy or Build?Darüber hinaus ist zu entscheiden,in welchem Ausmaß der Kundebzw. der IT-Dienstleister die jeweiligeLösung in Eigenleistungenmodifizieren bzw. zukünftig in derLage sein möchte, Modifizierungenvorzunehmen.Ist in Zukunft mit gleichbleibendenLeistungsanforderungen zu rechnen,welche durch Standard-Softwarepakete(„Packaged Solutions“)abgedeckt werden können, so sinddiese i. d. R. die zeit- und kostengünstigsteAlternative.Werden sich die Anforderungenwährend der Lebensdauer des EAI-Produktes voraussichtlich ändern39


<strong>Leitfaden</strong> E-<strong>Business</strong> | 206FAZITDie Unternehmen finden sichderzeit in einem Umfeld globalerWettbewerbe und kontinuierlicherÄnderung einerseits der Geschäftsprozesseinnerhalb der Wertschöpfungsketteund andererseits der EDVtechnischenMöglichkeiten zu derenUnterstützung wieder.Diese Veränderungen werdenmomentan maßgeblich durch denTrend zur weltweiten Vernetzunggetrieben, wobei technische und organisatorischeVernetzung Hand inHand gehen.Um die Möglichkeiten dieser Entwicklung(Marktpotentiale, Automatisierungvon Kauf- und Verkaufsprozessen,Beschleunigung von Prozesskettenetc.) optimal nutzen zukönnen, ist IT-seitig ein möglichstreibungsloser Informationsfluss vomKunden bis zum Lieferanten notwendig.Dieser Anforderung kann nurdurch eine hochgradig integrierte IT-Infrastruktur entsprochen werden,welche über die notwendige Flexibilitätverfügt, um die ständigenVeränderungen zeitnah und effizientzu unterstützen.Diesem Ziel steht in der Realitätoft eine historisch gewachsene undfolglich suboptimal integrierte IT-Infrastruktur entgegen.Die Auswahl und Entwicklungeiner EAI-Lösung setzt eine sorgfältigeAnalyse der Anforderungen aufder einen Seite und eine genau Untersuchungder bestehenden Anwendungslandschaftauf der anderenSeite voraus.Wesentliche Anforderungen zuGrundsätzen und Verfahren beimDatenmanagement, zur Sicherheit,und insbesondere zum Managementund zur Optimierung von Geschäftsprozessensind vor einer Auswahlvon Produkten zu analysieren.Komplexe Integrationsproblemelassen sich z.Z. selten mit einemeinzigen Produktpaket zufriedenstellendlösen, so dass meist eine41


20| <strong>Leitfaden</strong> E-<strong>Business</strong>Kombination verschiedener Lösungstechnologiennotwendig wird.EAI stellt unter den genanntenVoraussetzungen den vielversprechendstenLösungsansatz dar, dertechnisch und – trotz relativ hoherInvestitionskosten – wirtschaftlichsinnvoll, wenn nicht mittelfristigunumgänglich ist. Allerdings ist zubedenken, dass es sich bei den z. Z.am Markt erhältlichen Produktenum eine neue und insofern nur geringfügigerprobte Generation vonLösungskomponenten handelt.42


<strong>Leitfaden</strong> E-<strong>Business</strong> | 207 LITERATURVERZEICHNISE-<strong>Business</strong> TechnologieForecast, PricewaterhouseCoopersTechnologie Center California,Mai 1999;Ovum Report, Juni1999;The Forrester Report; Building ACommerce API, August 1999, by:Frank E. Gillett with Ted Schadler,Ben Worthen, Amanda J. Ciardelliand Stephanie SmithConspectus 1999, EAI-Report43

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!