Integration Suites vs. ESB

Ein ESB ist nicht genug
Kommentare

SOA beherrscht heute die Diskussion um das Design der Anwendungslandschaften in Unternehmen. Geht es um technische Grundfunktionen, steht ein Enterprise Service Bus bereit. Die fachlichen Anforderungen des Business Process Management bleiben dabei jedoch außen vor.

Wird die Debatte um die „richtige“ serviceorientierte Infrastruktur auch noch so heftig geführt, über einige Prinzipen und Grundmuster herrscht dennoch Einigkeit. Softwarebausteine bilden die Grundelemente einer hoch 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 ja 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.

Web Services als Basistechnologien

Der letzte Punkt, bei dem Konsens herrscht, ist die Basistechnologie in Form von Web Services. Aufgrund allgemein akzeptierter Internetstandards ermöglichen Web Services die Integration von Applikationen, die früher nur schwer einzubinden waren. Das Prinzip der Web Services 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 Services 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 nannte die Gartner Group [1] drei Punkte:

  • Kommunikation via JMS (Java Messaging Service) oder eine andere Messaging-orientierte Middleware (MOM)
  • Konnektivität auf Basis von Web Services
  • Umsetzung von XML- und SOAP-Messages (Transformation zur Unterstützung verschiedener XML-Formate) inklusive Routing

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 vielfältige Kommunikationsstandards, wie sie auch von EAI-Produkten bekannt sind. Neben MOM sind dies Kommunikationsmuster wie Remote Procedure Calls, die wichtigsten Web-Services-Standards rund um Event Registration, Event Discovery und Event Notification. Lücken existieren jedoch nach wie vor im Bereich Web-Service-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 [2] stellen die technologische Basis zur Realisierung von SOA bereit.

Abb. 1: Beurteilung der Gartner Group bez. Stärken und Schwächen unterschiedlicher Produktkategorien
ESB: Untermenge von Integrationsplattformen

Ein ESB baut in vielerlei Hinsicht auf den EAI-Fundamenten auf und erweitert sie um moderne Technologien wie Web Services. Anders ausgedrückt: Ein Enterprise Service Bus konzentriert sich auf die technologischen 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 Weges, denn eine der Herausforderungen lautet: Wie kann eine bestehende Systemlandschaft in eine Service-Architektur überführt werden? Häufig sind die bestehenden Systeme nämlich noch gar nicht servicefähig. Hier bleibt auch weiterhin 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) 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 Annnahme – 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. Das gilt für alle Branchen, egal, ob ein Unternehmen Produkte herstellt oder Dienstleistungen anbietet. 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. Das ist eines der zentralen Kennzeichen von Business Process Management.

Modellieren statt kodieren

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 kodieren, 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. Das 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 ESB 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. Ein solcher Leitstand, wie ihn voll ausgestattete Integrationsplattformen bieten, präsentiert idealerweise 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. Die Nutzung derartiger Prozesskennziffern ist in einem traditionellen 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.

Abb. 2: Integration Suites bieten mehr als ein ESB (Quelle: Gartner Group)
BPM ist mehr als ein ESB

Integrationsplattformen sind der Gartner Group zufolge eine Obermenge von ESBs: Sie enthalten deren Messaging-Funktionen plus eine Reihe weiterer Business-Funktionen. 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 weitgehend 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. Eine Integrationsplattform unterstützt demnach den gesamten Lebenszyklus von Geschäftsprozessen – von der technischen bis auf die fachliche Ebene.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -