EINSATZMUSTER FÜR

BPM-PLATTFORMEN:

PROZESSORIENTIERTE

ANWENDUNGSINTEGRATION

IN DER PRAXIS

In diesem Artikel beantworten wir zweiFragen aus technischer Perspektive, die sichbezüglich des Einsatzes einer BPM-Platt -form in einer bestehenden Anwendungs -landschaft stellen:

■ Welche funktionalen Anforderungenbestehender und noch zu entwickelnderAnwendungen lassen sich sinnvoll übereine BPM-Plattform zentralisieren?

■ Welche technisch-architektonischenOptionen bestehen für die Anbindungdieser Anwendungen und wie könnensie realisiert werden?

Wir konzentrieren uns zunächst auf dieerste Frage. Anhand einer funktionalenReferenzarchitektur erläutern wir, welchetypischen Funktionen von BPMS sich fürdie Bereitstellung als Service einer Platt -form und zur Integration in andere An -wendungen eignen. Im zweiten Abschnittzeigen wir anhand von Architektur -mustern, welche Integrationsoptionen fürverschiedene Anforderungsprofile geeignetsind und wie Plattform und Anwendungdabei jeweils ineinandergreifen.

Die fortscheitende Prozessorientierung in Unternehmen stellt IT-Abteilungen vor neueHerausforderungen: Es gilt, Silos aus Prozessdaten zu integrieren, die Prozessbearbeitungtransparent zu gestalten und Abläufe kurzfristig zu ändern. Dieser Artikel beschreibt Musterzur schrittweisen Integration einer BPM-Plattform in bestehende Anwendungslandschaften. Erzeigt, wie eine BPM-Suite als unternehmensweite Plattform die Anwendungsentwicklung mitder Bereitstellung einheitlicher Services unterstützt und Synergieeffekte zwischen Projektenmit BPM-Anforderungen erschließt.

m e h r z u m t h e m a :http://www.enterprise-bpm.orghttp://soa-know-how.de/BPM

20 21

Sie fordern von der IT-Abteilung die Um -setzung in den Systemen. Dafür sind auf-wändige Anpassungen nötig, um BPM-Funktionen, wie Aufgabenverwaltung,Work flow-Steuerung oder Echtzeitüber -wachung der Prozessbearbeitung, in denvorhandenen Anwendungen zu implemen-tieren.

Hinzu kommt, dass in vielen Unterneh -men die Hoheit über das Budget für IT-Projekte auf den Fachbereich übergegangenist (vgl. [Cap13]). Unternehmens architek -ten erkennen, dass eine Vielzahl anProjekten, die vom Fachbereich initiiertwerden, bestehende Anwendungen umredun dant implementierte BPM-Funktio -nalität erweitern soll. Mit dem Blick auf dieAnwendungslandschaft als Ganzes mussdas Ziel jedoch sein, diese Redundanz zuverhindern, um Synergieeffekte zwischenProjekten mit BPM-Anforderungen undden darin implementierten Prozessen zuerschließen und fragmentierte Prozesssiloszu vermeiden.

Nach der Einführung einer BPMS stehtdie IT-Abteilung damit vor der Heraus -forderung, einerseits existierende Anwen -dungen mit BPM-Funktionalität zu migrie-ren oder zu integrieren, sowie andererseitsdas Entstehen von ungesteuert entwickel-ten, fragmentierten BPM-Erweiterungen inder Anwendungslandschaft zu verhindern.Das Etablieren einer BPMS als unterneh-mensweite Plattform zur Bereitstellungstandardisierter BPM-Services ist eineMöglichkeit, beides auf einen Nenner zubringen.

Im Kontext der Projekte bei unserenKunden stellen wir branchenübergreifendfest: Die Prozessorientierung schreitet vor-an. Die Rolle des Prozessverantwortlichenist Teil der üblichen Organisationsstrukturgeworden. Von Abteilungen wie der Be -triebs organisation oder dem Inhouse-Con -sulting aufgesetzte Programme zur Er -fassung und Optimierung von Prozessensind etabliert. Auch die Mitarbeiter, die die-se Prozesse leben, entdecken im Zuge derEntwicklung hin zu einem prozessorientier-ten Unternehmen immer neue Verbes -serungspotenziale.

Gleichzeitig stoßen rein organisatorischeMaßnahmen an ihre Grenzen, da die beste-henden Anwendungssysteme die neuenSollprozesse nicht abbilden können. Für dieErschließung weiterer, immer noch reich-lich vorhandener Optimierungspotenzialemüssen diese Systeme angepasst werden.Sie sollen Arbeitsabläufe besser unterstüt-zen, diese wenn möglich automatisierenund sich nach den Geschäftsregeln derFachbereiche richten.

Den ersten Schritt in diese Richtunghaben die IT-Abteilungen meist schon voll-zogen: Eine Machbarkeitsstudie oder einPilotprojekt auf Basis einer vorher ausge-wählten Business Process ManagementSuite (BPMS) oder eines BPM-Frameworksist erfolgreich abgeschlossen und es wurdenerste Erfahrungen damit gesammelt.Trotzdem steht die IT-Abteilung unterZugzwang: Endanwender und Fach -bereiche haben erkannt, wo veraltete An -wen dungen ihre neuen Prozesse blockieren.

schwerpunk t

Hanno Hüther

(hanno.huether@capgemini.com)

vertritt Capgemini als Managing Consultant in den

Bereichen BPM und Softwareentwicklung.

Kundenorientierte Modellierung, Optimierung und

Implementierung von Geschäftsprozessen sind sei-

ne Spezialgebiete.

Dr. Tobias Walter

(tobias.walter@capgemini.com)

ist Senior Consultant im Bereich Banken bei

Capgemini. Seine beruflichen Schwerpunkte sind

die Industrialisierung von Geschäftsprozessen und

die digitale Transformation von Unternehmens -

architekturen.

d i e au toren

6/2013

Services einer BPM-PlattformUnsere funktionale Referenzarchitektur ist indie drei Schichten Präsentation, Funk tionenund Datenhaltung gegliedert. Damit ist esleichter möglich, die jeweiligen Services derBPM-Plattform den Kompo nenten von An -wendungssystemen in gängigen Drei-Schich -ten-Architekturen zuzuordnen. Die gewählteDarstellung konzentriert sich bewusst aufdiejenigen Komponenten, die das größtePotenzial für eine unternehmensweite Nut -zung im Zusammenspiel mit anderen An -wendungssystemen aufweisen. Von BPMSlediglich intern genutzte Komponen ten wer-den ebenfalls nicht dargestellt (für eine voll-ständigere, aber auch sehr komplexe Re fe -renz architektur verweisen wir auf [Med13]).

Abbildung 1 stellt diese Schichten mitihren Komponenten in einer BPM-Platt -form dar. Die Komponenten implementie-ren Services, die über Schnittstellen ange-boten und genutzt werden. Services könnenzum Beispiel über eine API angeboten undals Web-Services über SOAP- oder REST-Protokolle realisiert werden.

Präsentation: Benutzerzugriffund MonitoringEine BPM-Plattform bietet ein Portal alsWeb-Applikation an, über das Anwender

sowie Prozessverantwortliche und -analys -ten auf Prozessinformationen zugreifen.Dieses Portal kann verwendet werden, umvorhandene Oberflächen anderer Anwen -dungssysteme zu ergänzen oder zu integrie-ren.

Anwender können über das Prozess -portal den aktuellen Status von Prozessenabfragen und bearbeiten. Dazu gehört dasEinsehen, Durchführen und Delegieren vonzugewiesenen Aufgaben. Zum Lesen undManipulieren von Prozessinformationengreift das Prozessportal auf die Prozess-Engine zu.

Das Monitoring-Portal nutzen die Pro -zessverantwortlichen, um in Echtzeit dengesamten Ablauf von Prozessen zu überwa-chen. Alle Ereignisse sowie die Statuswertejeder Aufgabe können dort verfolgt wer-den. Der Einhaltung von Vereinbarungen,die mit internen oder externen Kundengetroffen wurden, gilt dabei besondereAufmerksamkeit. Diese Service LevelAgreements (SLAs) betreffen z. B. Reak -tionszeiten auf Anfragen oder die Bear -beitungsdauer bestimmter Aufgaben. Dash -boards fassen Informationen zu SLAsübersichtlich und prägnant in Form vonDiagrammen oder Ampeldarstellungenzusammen. Die Daten für das Monitoring

werden über die Schnittstelle zum BusinessActivity Monitoring automatisch geladenund aufbereitet.

Funktionen: Ausführen,Steuern und MessenDie Prozess-Engine wird zur Steuerung undKontrolle von Prozessabläufen genutzt.Integriert in die Anwendungslandschaft,koordiniert sie die Interaktion verschiedenerAnwendungen innerhalb eines Gesamt -prozesses. Sie gliedert sich in Teil kompo -nenten für Aufgabenverwaltung, Pro zess -ausführung und Prozessproto kol lierung.

Die Aufgabenverwaltung steuert dasBearbeiten von Aktivitäten mit Benut zer -interaktion für alle Prozessinstanzen. Siestellt für berechtigte Anwendergruppenund Manager Listen mit Zuständigkeitenund Prioritäten bereit und ermöglicht dasAnlegen und Weiterleiten von Aufgaben.

Den Ablauf der Prozesse regelt dieKomponente zur Prozessausführung. AufGrundlage des Prozessmodells werden dasErstellen von Aufgaben und das Zuweisenan Anwender angestoßen, Ereignisse zurInter-Prozess-Kommunikation ausgelöstund abgefangen sowie Entscheidungen anVerzweigungsknoten getroffen. Die Pro -zessausführung stellt die Daten bereit, die

schwerpunk t

Abb. 1: Bestandteile einer BPM-Plattform aus funktionaler Sicht.

Kopplung von Anwendungen und BPM-Plattformen.

Von Erfolgen profitierenErfolgreiche BPM-Plattform-Projekte zeich - nen sich typischerweise dadurch aus, dass sieTeil einer Strategie zur Prozess orientierungdes gesamten Unternehmens sind, klar defi-nierte Ziele verfolgen und von einer BPM-Governance gestützt werden, die regelt, wiedie Plattform eingesetzt wird. Aus diesenProjekten stammen die folgenden, nachah-menswerten Muster (Patterns) für eine pro-zessorientierte Inte gration, aufbereitet inAnlehnung an [Fow03]. Auf die Darstellungder Inte grations infra struktur, die üblicher-weise in Form eines ESB vorliegt, haben wirin den folgenden Architekturskizzenbewusst verzichtet, um die Interaktion vonPlattform und Anwendungen in denVordergrund zu stellen.

Muster 1:„Integration von BPM-Services“Ziel dieses Musters ist es, Services derBPM-Plattform in existierende oder nochzu entwickelnde Anwendungen zu integrie-ren. Auf diese Weise wird einerseits eineredundante Implementierung von in derPlattform verfügbaren Komponenten, wieAufgabenverwaltung und Rules-Engine,ver mieden, andererseits lässt sich ein

22 23

Funktionsumfang besitzt. Die meistenBPMS bieten daher Konnektoren für denZugriff auf selbstständige Portalsystemeoder zur Integration der Benutzungs -schnittstellen anderer Anwendungen in dasPortal der BPMS.

Der Funktionsumfang der in BPMS mit-gelieferten Rules-Engines variiert zwischenden verschiedenen Produkten sehr stark, oftist er aber eher rudimentär. Eine Inte grationexterner Lösungen, wie z. B. „IBMWebsphere Operational Decision Manage -ment“ oder „JBoss Drools“, ermöglicht es,eine leistungsfähige Rules-Engine in diePlattform aufzunehmen und die Verwa l tungvon Geschäftsregeln durch speziell dafürvorgesehene Oberflächen zu erleichtern.

Während Portal und Rules-Engine eherlose mit der BPMS gekoppelt sind, ist dieAbhängigkeit zwischen Prozess-Engine undBusiness Activity Monitoring stärker. Einenahtlose Integration beider Komponentenist notwendig, um die Übertragung vonProzessinformationen von der Prozess-En -gine an die Komponente für das Moni -toring in Echtzeit zu gewährleisten.

Für die beschriebenen funktionalenKom po nenten zeigen wir im nächstenAbschnitt Muster für die Integration mitanderen Systemen der Anwendungs -landschaft auf. Sie stehen dem IT-Archi -tekten als Referenz zur Verfügung undunterstützen ihn bei der Wahl der richtigen

für das Monitoring in Echtzeit benötigtwerden.

Für die Serviceorchestrierung bietenBPM-Plattformen eine Reihe von Kon -nektoren, um Services anderer Systeme ein-zubinden, zum Beispiel als Web-Serviceüber einen Enterprise Service Bus (ESB). Inden Prozessmodellen werden die einzelnenServices in ihre logische Ablaufreihenfolgegebracht und im Prozessablauf entspre-chend aufgerufen.

Die historische Prozessprotokollierungsammelt Daten aller Prozessabläufe und -zugriffe und legt sie in dafür vorgesehenenDatenbanken ab, die ebenfalls Bestandteilder BPM-Plattform sind. Diese Daten kön-nen für ein nachgelagertes Reporting, bei-spielsweise in einem Data-Warehouse,wiederverwendet werden und ermöglichendie Ausgabe eines Audit-Trail für Revi -sionsprüfungen.

Die Rules-Engine dient zur Definition,Ablage und Auswertung von Geschäfts -regeln. Sie wird verwendet, um Prozess -abläufe zu steuern und eine regelbasierteLogik zu implementieren. Trifft dieProzessausführung auf eine Regelaktivität,so greift sie auf die Rules-Engine zu, umdas Ergebnis einer Regelauswertung zuerhalten.

Die Komponente für das Business Acti -vity Monitoring ermöglicht die Überwa-chung, Analyse und Messung vonProzessen in Echtzeit und stellt die funktio-nale Basis für das Monitoring-Portal dar.

Daten: Persistieren und BereitstellenDie BPM-Plattform verwendet eine eigeneDatenhaltung zum dauerhaften Speichernvon Prozessinformationen, wie den Zu -stand eines Prozesses oder die Belegung vonProzessvariablen. Diese Komponente istnicht direkt wiederverwendbar, kann aberals Quelle für ein externes Reporting her-angezogen werden.

Die Plattform an dieAnforderungen anpassenBestimmte Komponenten von BPMS sindmodular einsetzbar, d. h. sie können durchandere Produkte ersetzt oder ergänzt wer-den, um eine funktional den Anfor derun -gen entsprechende BPM-Plattform zuerhalten.

Viele BPMS beinhalten standardmäßigein Portal, das auf die Darstellung der inprozessorientierten Anwendungen üblichengeführten Dialoge ausgerichtet ist und dar-über hinaus nur einen eingeschränkten

schwerpunk t

Abb. 2: Integration von BPM-Services.

6/2013

schwerpunk t

Abb. 4: Plattformzentrierte Anwendungsentwicklung.

durchgängiges Monitoring des Gesamt -prozesses erreichen. Einsatzszenarien fürdieses Muster sind:

■ Erweitern von Altanwendungen umBPM-Funktionen.

■ Realisieren von BPM-spezifischen An -for derungen über die Nutzung vonServices der BPM-Plattform bei derNeuentwicklung von Anwendungen.

■ Einbetten von Anwendungen in einsystemübergreifendes Monitoring vonGeschäftsprozessen.

Die betreffende Anwendung nutzt dasApplication Programming Interface (API)der BPM-Plattform, um dem BenutzerBPM-spezifische Funktionen bereitzustel-len, ohne diese selbst zu implementieren.Diese APIs werden üblicherweise in Formvon Web-Sevice-Schnittstellen über SOAP-oder REST-Protokolle bereitgestellt (vgl.z. B. [Alf13] und [Ora12]).

Wie in Abbildung 2 zu sehen, ruft dieAnwendung dazu beispielsweise eineOperation stelleAufgabenlisteDar der Platt -form auf und zeigt diese Liste dem Benutzeran. Als Integration auf der Ebene der Prä -sentation entspricht dies einem reinenWeiterleiten des Anwenders auf die Benut -zungsoberfläche der BPM-Plattform. EineAnpassung des Layouts ist denkbar, aber eineDatenmanipulation findet nicht statt.

Die meist flexiblere Alternative besteht

in der Integration auf Funktionsebene, die im Beispiel mit der OperationliefereAufgabenliste verdeutlicht werden soll.Hier übernimmt die Anwendung dieAufbereitung zur Darstellung, die BPM-Plattform liefert lediglich strukturierteDaten. Über eine solche Schnittstelle kanndie Anwendung auch Aufgaben erzeugen,die von Anwendern anderer Systeme bear-

beitet werden sollen, sofern diese ebenfallsmit der Plattform integriert sind.

Ein durchgängiges Monitoring und dieSteuerung des Geschäftsprozesses über Sys -tem grenzen hinweg werden dadurch erreicht,dass die betreffende Anwendung an geeigne-ten Stellen innerhalb der eigenen Verar bei -tung einen Aufruf zur BPM-Platt form absetzt,der den eingetretenen Fort schritt kommuni-ziert. Das Abschließen eines bestimmtenDialogs oder die Änderung des Status einesGeschäftsobjekts sind typische Verarbei -tungs schritte, die einen Aufruf wieschließeAufgabeAb auslösen können. Auchwenn die Anwendung selbst nicht prozesso-rientiert abläuft, können so der Prozess ver laufüber die Plattform verfolgt und nachgela gerteVerarbeitungs schritte angestoßen werden.

Muster 2:„Integration von Anwendungsservices“Im Unterschied zum ersten Muster ist hierdie BPM-Plattform das führende System. DerAnwender meldet sich am Prozess portal an,über das er – für ihn transparent – auf ver-schiedene Anwendungen zugreifen kann.Diese Anwendungen stellen Services bereit,die von der Plattform aufgerufen werden.Einsatzszenarien für dieses Muster sind:

■ Integrieren von bestehenden oderReali sieren von neu zu erstellendenprozessorientierten Anwendungen.

■ Bereitstellen einer einheitlichen Umge -

Abb. 3: Integration von Anwendungsservices.

24 25

bung für Benutzer, die andernfalls zurErledigung ihrer Aufgaben auf eineVielzahl unabhängiger Anwendungs -systeme zugreifen müssten.

Der Anwender meldet sich einmalig amProzessportal (oder an einer übergeordne-ten Portalanwendung des Unternehmens,die dieses enthält) an. Von dort aus bear-beitet er im Idealfall alle Aufgaben, dieinnerhalb der Geschäftsprozesse, an denener beteiligt ist, für ihn anfallen.

Technisch wird dies möglich gemacht,indem eine zentrale Aufgabenverwaltung inder BPM-Plattform auf Dialoge der betref-fenden integrierten Anwendung zugreiftund diese direkt innerhalb der eigenenBenutzungsoberfläche darstellt oder aufeinem anderen geeigneten Weg für denAnwender öffnet. In Abbildung 3 wird diesdurch den Aufruf der OperationstelleFormularDar angedeutet. Die entspre-chende Schnittstelle stellt das Anwen -dungssystem bereit. Häufig werden zu die-sem Zweck Oberflächenservices auf Basisvon Web-Technologien, wie beispielsweisePortlets, eingesetzt. Die Möglichkeit zurVerwendung einer vom Prozessportalabweichenden Technologie zur Reali -sierung der Anwendungsoberflächen bleibtdabei, anders als im folgenden Muster 3,erhalten.

Reihenfolge, Verantwortlichkeiten undAufrufzeitpunkte der Dialoge werden imUnterschied zum ersten Muster nicht mehrinnerhalb der einzelnen Anwendung, son-dern von der Prozessdefinition festgelegt, diein der Prozess-Engine der BPM-Plattformhinterlegt ist. Die Prozess-Engine kann dar-über hinaus auch Services der An wendungansteuern, die keine Benutzer inter aktionerfordern, die aber zum Erbringen desGeschäftsprozesses erforderlich sind, wiebeispielsweise eine Berech nung starten odereine Rechnungsstellung veranlassen.

Zur Realisierung des Monitorings desProzessablaufs sind im Unterschied zumersten Muster keine zusätzlichen Maß -nahmen außerhalb der BPM-Plattform not-wendig, da die Prozessausführung direkt inder Prozess-Engine gesteuert wird.

Muster 3:„PlattformzentrierteAnwendungsentwicklung“Anders als in den Mustern 1 und 2 wird hierdie Präsentationsschicht komplett innerhalbdes Funktionsumfangs der BPM-Plattformrealisiert. Voraussetzung hierfür ist, dass dieverwendete BPMS über ein entsprechend lei-stungsfähiges Prozessportal verfügt.Einsatzszenarien für dieses Muster sind:

■ Realisieren von primär prozessorien-tierten Anwendungen, deren Ober -flächen im Wesentlichen auf aufgaben-bezogene Oberflächen beschränkt sind.

■ Bereitstellen einer einheitlichen Umge -bung für Benutzer, die andernfalls zurErledigung ihrer Aufgaben auf eineVielzahl unabhängiger Anwendungs -systeme zugreifen müssten.

BPMS beinhalten in ihrem Lieferumfangüblicherweise einen visuellen Editor für dieImplementierung von Prozessschritten, dieeine Benutzerinteraktion erfordern. Diesensetzt der Entwickler ein, um dem An -wender innerhalb des ProzessportalsOberflächen bereitzustellen, über die er mitder Prozess-Engine interagieren kann, diewiederum entsprechende Operationen derintegrierten Anwendungen aufruft.

In Abbildung 4 ist eine OperationliefereOperationsdefinition angedeutet, dieeine Schnittstellenbeschreibung mitBezeich nun gen, Datentypen und zulässigenWertebereichen zurückgibt. Der Entwicklerkann diese Beschreibungen nutzen, bei-spielsweise in Form einer WSDL-Datei, um

mittels Oberflächengeneratoren Eingabe -formu lare von der BPMS vorbereiten zulassen, und diese dann anpassen.

Verglichen mit dem Einsatz von univer-sellen Benutzungsoberflächen-Frameworkslässt sich durch die aufeinander abge-stimmten Schnittstellen von Prozessportalund Prozess-Engine innerhalb einer BPMSein Effizienzgewinn erzielen, solange dieAnforderungen der Benutzer bezüglich derzu realisierenden Oberflächen mit demStandardfunktionsumfang der BPMSerfüllt werden können. Sobald funktionaleErweiterungen des Prozessportals notwen-dig sind, muss mit einem stark steigendemAufwand gerechnet werden.

Potenziale erkennen undFehler vermeidenUm Schwachstellen in der eigenen Anwen -dungslandschaft zu erkennen, die mittelsder dargestellten Muster behoben werdenkönnen, oder um Fehler im Integrations -design schon während der Entwurfsphaseentsprechender Projekte zu vermeiden, hilftdie Betrachtung von Anti-Mustern (AntiPatterns).

Die drei folgenden, in Abbildung 5 sym-bolhaft dargestellten Beispiele für proble-matische Integrationsarchitekturen sindaus realen Kundensituationen abgeleitetund jeweils in dem Bestreben entstanden,Anwendungssysteme prozessorientiert zuverknüpfen. Sie weisen jedoch signifikanteNachteile auf.

Anti-Muster 1:„Manuelle Schnittstellen“Wenn innerhalb eines GeschäftsprozessesDaten nicht über Schnittstellen integrierterAnwendungen, sondern von den Benutzernaus einem System A in ein System B über-tragen werden, liegt dieses Anti-Mustervor. Dazu gehören beispielsweise:

■ E-Mails, auch wenn sie automatischgeneriert werden, über die einAnwender Anweisungen oder Datenerhält, anhand derer er anschließendden Prozess in einem Anwendungs -system weiterführt.

■ Das Abtippen oder Kopieren von Datenüber die Zwischenablage von einer An -wen dung in eine andere.

■ Das manuelle Ausgleichen von Medien -brüchen, beispielsweise die Eingabenvon Daten aus Papierdokumenten ineine Anwendungsmaske.

schwerpunk t

Abb. 5: Häufig anzutreffende Anti-Muster zur prozessorientierten Integration vonAnwendungssystemen.

6/2013

schwerpunk t

Manuelle Schnittstellen erzeugen hoheZeitaufwände bei den zuständigen Mitar -beitern und stellen aufgrund potenziellerEingabefehler ein Risiko für die Qualitätder Prozessverarbeitung dar. Ein Reportingüber den Verlauf des Gesamtprozesses istwiederum nur mit manuellem, zusätzli-chem Aufwand möglich, da eine kausaleund zeitliche Zuordnung von Verarbei -tungsschritten in verschiedenen Anwen -dun gen nicht automatisch erfolgen kann.

Anti-Muster 2:„Punkt-zu-Punkt-Integration“Geschäftsprozesse erstrecken sich meistüber mehrere Anwendungssysteme, beispielsweise vom Auftragseingang überdie -verarbeitung bis hin zur Rechnungs -stellung. Eine naheliegende Variante derIntegration besteht darin, jeweils an denÜbergängen von einem System zum nächs -ten Schnittstellen zu implementieren, dieeine weitere Verarbeitung anstoßen.

Wendet man dieses Anti-Muster konse-quent an, entsteht eine Struktur, die derMesh-Topologie aus der Netzwerktechnikähnelt. Die hohe Anzahl resultierenderSchnittstellen sorgt für hohe Wartungs -aufwände bei Änderungen an den Systemenaufgrund wechselseitiger Abhängigkeiten.Der Zeit- und Kostenaufwand für eineOptimierung des Prozessablaufs wirddurch die potenziell große Zahl notwendi-ger Änderungen in der Kommunikationzwischen den beteiligten Systemen starkerhöht.

Anti-Muster 3:„Workflows im ESB“Eine gängige Methode, die Nachteile vonPunkt-zu-Punkt-Integrationen zu vermei-den, liegt im Einsatz einer Bustopologie,beispielsweise durch den Einsatz eines ESBin einer serviceorientierten Architektur.Dies ist eine geeignete Vorgehensweise,Anwendungslandschaften zu strukturieren,und empfiehlt sich auch als Grundlage füreine prozessorientierte Integration. Ent -sprechend bieten einige SoftwarehäuserBPMS und ESB auch als Paket an oderempfehlen den gemeinsamen Einsatz (vgl.z. B. [Nel11]).

Bezüglich der Anforderungen prozesso-rientierter Integration eignen sich aktuellverfügbare ESB für sich allein vor allem fürdie Serviceorchestrierung sowie die Imple -mentierung von kurz laufenden Dunkel -verarbeitungsprozessen, also als technischeInfrastruktur im Zusammenspiel mit einerBPM-Plattform. Nicht empfehlenswert istihr Einsatz als Ablaufumgebung für langlaufende Geschäftsprozesse mit intensiverBenutzerinteraktion (Workflows) und fürderen Monitoring (vgl. [Alm11]). Den gän-gigen ESB fehlen dazu notwendigeFunktionen, insbesondere zur BPMN-kon-formen Prozessmodellierung, Aufgaben -verwal tung und der Unterstützung vonSLAs, um einige Beispiele zu nennen.

Es hat es sich bewährt, Integrationslogikund Adapter zu systemspezifischen Schnitt -stellen innerhalb des ESB zu implementie-ren. Aus den Geschäftsprozessen in der

BPMS wird dann mittels einer einheitlichenTechnologie über den ESB auf die Anwen -dungssysteme zugegriffen. So wird einerVermischung von Integrations- und Ge -schäftslogik vorgebeugt, die auch aufgrundder unterschiedlichen Änderungszyklenvermieden werden sollte, damit es nicht zuungewollten Abhängigkeiten bei Weiterent -wicklung und Wartung kommt.

Schritt für Schritt zumEnd-to-End-ProzessArchitekten und Entwickler können diedargelegten Muster als Ausgangspunkt ein-setzen, um mit ihren Partnern imFachbereich zukunftsfähige Lösungen fürdie Forderung nach prozessorientiertenAnwendungen zu erarbeiten. Sie sind ausunseren eigenen Erfahrungen und denenunserer Kollegen in Entwicklungs- undBeratungsprojekten entstanden, haben sichalso in der Praxis bewährt. Dort hat sichauch gezeigt, dass für jede Konstellationvon Anwendungssystemen neu ermitteltwerden muss, ob die von den Musterngeforderten Schnittstellen tatsächlich vor-handen sind oder gegebenenfalls ergänztwerden können. Dies gilt insbesonderebeim Einbinden von Standardsoftware, dahier in vielen Fällen herstellerseitig Grenzenbezüglich der Erweiterbarkeit gesetzt sind.Ein Blick auf Konzepte und Adapter, dievon einigen Herstellern beispielsweise fürdie Integration von SAP ERP angebotenwerden (vgl. z. B. [IBM13] oder [PEG12]),kann sich als lohnenswert herausstellen.

Mit dem Einsatz der Muster werden dreizentrale Anforderungen aus Geschäftssichtberücksichtigt:

■ Anwendungsübergreifendes Monito -ring von Geschäftsprozessen als Grund -lage der Etablierung von SLAs undkontinuierlicher Verbesserung.

■ Für die Benutzer transparente Integra -tion neuer und bestehender Anwen -dungen zu durchgängigen Arbeitsab -läufen.

■ Effizientere Anpassbarkeit neuer An -wendungen durch Extraktion undExplikation der Geschäftsprozesse inModellen.

Das Zielbild für die prozessorientierteIntegration ist die End-to-End-Betrachtungvon Geschäftsprozessen, also das kontinu-ierliche, durchgängige Monitoring bei-spielsweise vom Auftragseingang bis hin

Abb. 6: End-to-End-Betrachtung von Prozessen.

26 27

zur Auslieferung einer Ware. Das Zu -sammenwirken der beteiligten Anwen -dungs systeme und der BPM-Plattform zumErreichen dieses Ziels ist in Abbildung 6dargestellt.

Die zunehmende organisatorische Pro -zessorientierung von Unternehmen wirddazu führen, dass auch die Anzahl prozess -orientierter Anwendungssysteme starkzunimmt. Daraus ergeben sich aus archi-tektonischer Sicht weitere wichtigeArgumente für den Einsatz einer BPM-Plattform in Einklang mit den vorgestelltenMustern:

■ Vermeidung redundanter Funktions -kompo nenten innerhalb der Anwen -dungslandschaft.

■ Reduktion der Komplexität der Inte -grationsarchitektur.

■ Effizientere und zentral gesteuerteImple mentierung von prozessorientier-ten Anwendungen.

■ Geringere Aufwände zur Anpassungvon Anwendungssystemen in Prozess -optimierungsprojekten.

Wenn die IT-Abteilung es schafft, sich alskompetenter Partner für prozessorientierteAnwendungsintegration zu positionieren,

schwerpunk t

Literatur & Links

[Alf13] Alfresco, Activiti – Engine 5.12 API, 2013, siehe: http://www.activiti.org/javadocs/index.html

[Alm11] M. Almenta Reca, ESB or BPM, 2011, siehe:

http://blogs.mulesoft.org/why-bpm-and-esb-need-to-work-together/

[Cap13] Capgemini, IT-Trends 2013, siehe:

http://www.de.capgemini.com/sites/default/files/resource/pdf/capgemini-studie_it-trends_2013.pdf

[Fow03] M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley 2003

[Hoh11] J. Hohwiller, D. Schlegel, Integration of UI services into SOA based BPM applications,

in: Proc. of 4th International Conference on Business Process and Services Computing, 2011

[IBM13] IBM, Understand and Monitor your SAP Processes, siehe:

http://www-01.ibm.com/software/integration/business-process-manager/sap-integration/process-discovery/index.html

[Med13] R. Medina, A BPM Reference Architecture with Glossary, siehe:

http://www.richardmedinadoculabs.com/1/post/2013/04/a-bpm-reference-architecture-with-glossary.html

[Nel11] M. Nelson, What BPM adds to SOA Suite, 2011, siehe:

http://redstack.wordpress.com/2011/01/15/what-bpm-adds-to-soa-suite/

[Ora12] Oracle, Introduction to Building Clients for Workflow Services, 2012, siehe:

http://docs.oracle.com/cd/E23943_01/dev.1111/e10224/bp_worklistcust.htm#CIHGEABG

[Peg12] Pegasystems, Pega Process Extender for SAP Business Suite, 2012, siehe:

http://www.pega.com/fr/resources/pega-process-extender-for-sap-business-suite

kann sie eine gestaltende und ordnendeRolle in dieser Entwicklung einzunehmen.Dass dies gelingt, hängt maßgeblich davon

ab, ob sie ihre Möglichkeiten kennt undden Fachbereichen die richtigen Lösungs -vorschläge und Konzepte liefern kann. ■