Enterprise-Applikationsintegration mit zeitgemäßer Technik

Ein Enterprise Service Bus ist nicht genug

18. Dezember 2006, 01:15 Uhr   |  Thomas Egeling/jos Thomas Egeling ist Presales Consultant bei Vitria.

SOA beherrscht heute die Diskussion um das Design der Anwendungslandschaften in Unternehmen. Geht es um technische Grundfunktionen, steht ein Enterprise Service Bus (ESB) bereit. Die fachlichen Anforderungen des Business-Process-Managements bleiben dabei jedoch zunächst außen vor. Die Experten des Softwareherstellers Vitria betonen die Vorzüge eines umfassenden Business-Process-Managements.

Wird die Debatte um die "richtige" serviceorientierte Infrastruktur auch noch so heftig geführt:
Über einige Prinzipien und Grundmuster herrscht dennoch Einigkeit. Softwarebausteine bilden die
Grundelemente einer flexiblen Architektur. Eine Applikation setzt sich demnach aus einzelnen
Komponenten zusammen, die gemeinsam eine jeweils klar umrissene Aufgabe wahrnehmen. Im Idealfall
sind die einzelnen Elemente nur "lose" miteinander gekoppelt, und sie stellen ihre Funktionen in
Form von Services bereit.

Was zunächst kompliziert klingt, hat seine realen Vorbilder in den industriellen
Fertigungsprozessen. Speziell im Automobilbau setzen Unternehmen bereits bei der Produktplanung und
-entwicklung auf die System- und Modulbildung, und dieses Konstruktionsprinzip setzt sich bis in
die Fertigung fort. Als Module gelten komplette und funktionsfähige Einheiten, die einbaufähig
geliefert werden. Ein Bremssystem, die Klimaanlage oder der Fahrzeugantrieb entsteht, indem
Elemente aus mehreren Baugruppen, Komponenten und Modulen zusammenwirken. Solche
Standardkomponenten – die auch Pate standen für weite Teile einer serviceorientierten Architektur –
lassen sich auftragsneutral vorfertigen. Die auftragsabhängigen Bausteine (beim Automobil
beispielsweise die Ausstattung, die Farbe und das Zubehör) müssen abhängig von bestimmten
Ereignissen individuell geordert werden.

Webservices als Basistechnik

Der letzte Punkt, bei dem Konsens herrscht, ist die Basistechnik in Form von Webservices. Auf
Grund allgemein akzeptierter Internetstandards ermöglichen Webservices die Integration von
Applikationen, die früher nur schwer einzubinden waren. Das Prinzip der Webservices ist einfach:
Ein Service-User fordert von einem Service-Provider Dienste an, die der Provider als Funktionen
bereitstellt. Die Kommunikation erfolgt mithilfe der XML-basierten Beschreibungssprache WSDL (Web
Service Description Language). Die WSDL-Spezifikation geht von einer abstrakten Interaktion
zwischen Service-Provider und Service-User aus, bei der Provider und User Nachrichten übermitteln –
konkretisiert als Funktionsaufruf mit Rückgabewert.

So weit, so gut. Nun aber zeigen sich erste Differenzen. Nämlich dann, wenn das Konzept des
Enterprise Service Bus (ESB) in die Diskussion eingeführt wird. Die Gartner Group hat sich bereits
2002 zum Thema ESB geäußert. Als zentrale Eigenschaften eines ESB nannten die Marktforscher drei
Punkte:

Kommunikation via JMS (Java Messaging Service) oder über eine andere
Messaging-orientierte Middleware (MOM),

Konnektivität auf Basis von Webservices und

die Umsetzung von XML- und SOAP-Messages (Transformation zur Unterstützung
verschiedener XML-Formate) inklusive Routing.

Konzept mit Hub and Spoke

Ein Kernbestandteil ist die Messaging-Middleware, wobei der Großteil der Lösungen einem
Hub-and-Spoke-Konzept folgt. Dabei ist ein zentraler Broker (Hub) für die Zustellung der
Nachrichten an die integrierten Applikationen (Spokes) zuständig.

Ein ESB unterstützt viele Kommunikationsstandards, wie sie auch von EAI-Produkten bekannt sind.
Neben MOM sind dies Kommunikationsmuster wie Remote Procedure Calls, die wichtigsten
Webservices-Standards rund um Event Registration, Event Discovery und Event Notification. Lücken
existieren jedoch nach wie vor im Bereich Webservice-Management. Auf dieser Ebene enthält ein ESB
keine vergleichbaren Funktionen wie traditionelle EAI-Lösungen. Beiden gemeinsam ist die
Ausrichtung am SOA-Design. ESBs und moderne EAI-Plattformen wie beispielsweise Vitria BusinessWare
stellen die technische Basis zur Realisierung von SOA bereit.

ESB: Untermenge von Integrationsplattformen

Ein ESB baut in vielerlei Hinsicht auf den EAI-Fundamenten auf und erweitert sie um moderne
Techniken wie Webservices. Anders ausgedrückt: Ein Enterprise Service Bus konzentriert sich auf die
technischen Fundamente zur Einführung von SOAs im Unternehmen. Bei einem ESB geht es um technische
Grundfunktionen und weniger um unternehmensspezifische Services und Geschäftsprozesse. Mehr noch:
Die Integrationsarbeit ist dadurch noch nicht gelöst, dass eine serviceorientierte Architektur zum
Leitprinzip erkoren wird. Vielmehr beginnt dann erst der größte Teil des Wegs, denn eine der
Herausforderungen lautet: Wie kann eine bestehende Systemlandschaft in eine Servicearchitektur
überführt werden? Häufig sind die bestehenden Systeme nämlich noch gar nicht servicefähig. Dabei
besteht auch weiter die Aufgabe, eine Integration der vorhandenen Applikationen zu erreichen. Die
Vorgabe lautet nun, die Anwendungen einem übergeordneten Prozessablauf als Ressource (Service)
bereitzustellen.

Dazu bedarf es jedoch weitergehender Funktionen, wie sie die meisten gegenwärtigen ESBs bieten.
Sie fokussieren auf Messaging ergänzt um Konnektoren, um den Anschluss an vorhandene Applikationen
herzustellen. Nur genügt das bei weitem nicht für die Steuerung und Kontrolle von
Geschäftsprozessen – sprich: Business Process Managament (BPM). Auf diesem Feld sind
Integrationsplattformen (Integration Suites in der Terminologie der Gartner Group) wie "Business
Ware" den ESBs einige Schritte voraus. Als Differenzierungsmerkmale nennt die Gartner Group in dem
Zusammenhang Funktionen wie eine Business Rule Engine, Business Event Management und Business
Activity Monitoring.

Steuerung und Kontrolle von Geschäftsprozessen

Mit einer Business Rule Engine definieren Anwender Regeln die festlegen, was beim Auftreten (oder auch Ausbleiben) bestimmter Business-Events zu geschehen hat. Im Normalfall – so die Annahme – läuft ein Geschäftsprozess glatt. Was aber passiert, wenn Ausnahmen auftreten? Beispiel: Ein Logistikunternehmen oder ein anderer Partner liefert beim Supply-Chain-Management zu spät, in mangelhafter Qualität oder die falschen Waren. Denn zu Ausnahmen kommt es insbesondere an den Schnittstellen, an denen der Material- und Informationsfluss von Geschäftsprozessen von einer Applikation zur nächsten weitergeleitet wird beziehungsweise mehrere Zulieferer und Partner eines Unternehmens involviert sind. Ein systematisches und effektives Exception-Management, wie es Integration-Suites standardmäßig oder über integrierte Add-ins bieten, erkennt die Sonderfälle dort, wo sie entstehen. Ein solches Business-Event-Management dagegen fehlt bei ESBs.

Das gleiche gilt für Funktionen wie Business Activity Monitoring. Geschäftsprozesse sind die operativen Treiber für Umsätze, Gewinne und Verluste. Dies gilt für alle Branchen – gleichgültig, ob ein Unternehmen Produkte herstellt oder Dienstleistungen anbietet.

Leistungskennzahlen gefordert

Wer wissen will, wie gut, wie schnell und wie teuer die Geschäftsprozesse seines Unternehmens
tatsächlich sind, benötigt Leistungskennzahlen. Solche Kennziffern, wie sie vielerorts bereits
genutzt werden, sind wichtige Indikatoren für die Leistungsstärke eines Unternehmens. Voraussetzung
für die Nutzung solcher Key Performance Indicators (KPIs) sind genau definierte und in einer
Integrationsplattform modellierte Geschäftsprozesse, deren Abläufe die Basis zur Messung der
notwendigen Werte bilden. Durch eine kontinuierliche, automatische Überwachung der ablaufenden
Prozesse lassen sich die ermittelten Werte als Frühwarnindikatoren nutzen. Sie liefern dann eine
Entscheidungsgrundlage für steuernde Eingriffe in die Prozesse. Spürbare Effekte bei der
Optimierung von Geschäftsprozessen stellen sich nur dann ein, wenn ein ständiges Monitoring
stattfindet. Dies ist eines der zentralen Kennzeichen von Business-Process-Management.

Modellieren statt codieren

Die Unterschiede zwischen einem ESB und einer Integrationsplattform lassen sich recht
anschaulich an einem Beispiel verdeutlichen. Angenommen, ein Versicherungsunternehmen, das in
mehreren Sparten tätig ist, will seine fachlichen Geschäftsprozesse optimieren und in neuen
technischen Abläufen abbilden. Dazu entwerfen die Fachbereiche mit einem Modellierungs-Tool die
neuen Prozesse. Statt die Abläufe mit programmiertechnischen Methoden zu codieren, kommen hier
vielmehr grafische Objekte und Workflows zum Einsatz, mit denen der Datenfluss nachgezeichnet wird.
Eingebettet ist das Werkzeug in ein ganzheitliches Vorgehensmodell für das
Geschäftsprozessmanagement. Das Muster erstreckt sich vom Design der Geschäftsprozesse, deren
technischen Umsetzung und der operativen Ausführung bis zum kontinuierlichen Monitoring, dessen
Ergebnisse dann wieder in ein Update des Geschäftsprozessdesigns eingehen.

Ein ESB befasst sich lediglich mit der technischen Abbildung der Geschäftsprozesse, genauer: mit
den technischen Konnektoren. Dies betrifft die technische Anbindung aller in einen Geschäftsprozess
involvierten internen und externen Applikationen, die Transformation von Datenformaten und die
Vereinheitlichung aller Schnittstellenspezifikationen. Insbesondere im Versicherungssektor mit
seiner langjährigen IT-Historie sind auf dieser Ebene eine große Vielfalt unterschiedlicher
Hardwareplattformen, Betriebssysteme und Applikationen betroffen. Nicht selten reicht das Spektrum
vom Mainframe über Unix und Linux bis hin zu Windows. Grundlage für die Umsetzung der technischen
Infrastruktur bilden die durch die Fachabteilungen modellierten Prozesse. Die Aktivitäten und das
Einsatzspektrum eines ESBs sind an dieser Stelle erschöpft. Alles was danach kommt, fällt nicht
mehr in sein "Revier."

Für das gesamte Monitoring der Geschäftsprozesse bedarf es anderer Funktionen. Die Möglichkeiten
zur Realisierung sind an dieser Stelle vielfältig. Denkbar ist, dass einzelne Prozesse wie die
Übernahme von Versicherungsanträgen der unterschiedlichen Sparten jeweils getrennt behandelt werden
oder auch gebündelt in einem Portal.

Leitstand von Integrationsplattformen

Ein solcher Leitstand, wie ihn voll ausgestattete Integrationsplattformen bieten, präsentiert im
Idealfall in einer Listendarstellung und in grafischer Form die zuvor definierten
betriebswirtschaftlichen und prozessbezogenen Kennziffern. Beispiele dafür sind die Durchlaufzeiten
von der Unterzeichnung des Antrags bis zum Eintreffen der Police beim Versicherungsnehmer, der
Anteil der ohne weitere manuelle Eingriffe ablaufenden Anträge, die Herkunft der Anträge (eigene
Vertriebsorganisation, unabhängige Makler, direkt über das Internet), die Datenqualität der
eingespielten Anträge, die Weitergabe der Daten an Archivierungssysteme oder auch die Dauer der
Schadens- und Leistungsabwicklung bei Sach- oder Krankenversicherungen.

ESB: Fixierung auf technische Abläufe

Die Nutzung derartiger Prozesskennziffern ist in einem traditi-onellen ESB nicht vorgesehen.
Denn er ist nahezu ausschließlich auf die technische Abbildung der Abläufe fixiert. Eine
Business-Process-Management-Plattform dagegen befasst sich mit eindeutig definierten und wieder
verwendbaren fachlichen und technischen Bausteinen. Nur so lässt sich auch der Feedback-Kreislauf
vom Design über die Ausführung und Monitoring bis zum Tuning schließen.

Integrationsplattformen sind der Gartner Group zufolge eine Obermenge von ESBs: Sie enthalten
deren Messaging-Funktionen plus eine Reihe weiterer Business-Funktionen.

SOA-Unterstüzung auf drei Ebenen

Eine Integrationsplattform unterstützt SOAs auf drei Ebenen: Sie ermöglicht erstens, vorhandene
Softwarebestände als wieder verwendbare Bausteine beziehungsweise Services zu behandeln. ESBs
beschränken sich weit gehend auf diese Ebene. Zweitens können derartige Services mithilfe
unternehmensweiter Business-Process-Management-Funktionen zu neuen, komplexen Geschäftsprozessen
zusammengestellt werden. Solche neu modellierten Prozesse lassen sich dann unter Einbeziehung von
Elementen ereignisgesteuerter Architekturen gemeinsam mit vorhandenem einsetzen und ausführen.
Drittens schließlich ermöglicht eine Integrationsplattform serviceorientierte Designprinzipien mit
übergeordneten Management-Services wie Exception Handling, Logging und Auditing sowie Business
Activity Monitoring zu kombinieren.

Jörg Schröper.

Auf Facebook teilen Auf Twitter teilen Auf Linkedin teilen Via Mail teilen

Das könnte Sie auch interessieren

Verwandte Artikel

Default