Wo BPM-Tools an Grenzen stoßen

08.05.2007
Von Thomas Hummel, Stefan Thurow 
Für das Zusammenspiel von Prozess-Management und SOA reichen herkömmliche Werkzeuge nicht aus.
BPM liefert die Basis für eine erfolgreiche Geschäftsstrategie. Die darunter liegende Service-orientierte Architektur ermöglicht eine optimale Nutzung der IT.
BPM liefert die Basis für eine erfolgreiche Geschäftsstrategie. Die darunter liegende Service-orientierte Architektur ermöglicht eine optimale Nutzung der IT.

Geht es um Service-orientierte Architekturen (SOA), herrscht mittlerweile eine enorme Erwartungshaltung. Dabei verliert sich die aktuelle Diskussion häufig in technologieorientierten Detailfragen. Gleiches gilt für BPM-Tools (Business-Process-Management), die zur Modellierung und zum Monitoring von Geschäftsprozessen dienen. Eine Rückbesinnung auf die ursprünglichen Ziele und Visionen von SOA und BPM ist deshalb geboten.

Hier lesen Sie ...

- wo BPM-Tools ihre Grenzen haben;

- warum eine Enterprise Architecture für SOA und BPM unverzichtbar ist;

- wie IT-Business-Alignment zum Erfolg beiträgt.

Mehr zum Thema,www.computerwoche.de/

588732: Wer schnürt die besten BPM-Pakete?

591187: Vorgehensmodell für BPM-Projekte;

590017: Mit SOA zielt Air France KLM auf schlanke Prozesse.

SOA-Expertenrat:

http://www.computerwoche.de/soa-expertenrat

Agilität ist das Ziel

Die Transformation der IT in eine Service-orientierte Architektur kann die Agilität einer Organisation erhöhen - ohne die bestehenden Systeme und Anwendungen zu ersetzen. Vereinfacht ausgedrückt bedeutet SOA: Aus lose gekoppelten Services werden geschäftsrelevante Funktionen zusammengestellt, die in einem Service-Repository, das heißt einer Datenbank, hinterlegt sind. Auf Basis einer entsprechenden Technikplattform können diese Services zu immer neuen geschäftsrelevanten Prozessen zusammengesetzt werden, die am Backend auf bestehenden Legacy-Systemen aufsetzen.

An dieser Stelle kommen die BPM-Tools ins Spiel. Sie sollen sowohl das Zusammensetzen als auch das Monitoring der Bausteine drastisch vereinfachen. Gängige BPM-Produkte entschärfen das Problem in Applikationen eingebetteter Prozesslogik, indem sie diese abstrahieren und in eine neue Schicht von Software-Tools integrieren. Diese Werkzeuge lösen die Integrations- und Prozessschritte von darunter liegenden funktionalen IT-Applikationen, so dass sie effizienter angepasst, administriert und optimiert werden können. Durch den Einsatz von BPM-Tools und die Orchestrierung der Interaktion zwischen den einzelnen Bausteinen lässt sich eine Prozessautomatisierung erreichen. Mittels Business Activity Monitoring (BAM) können Unternehmen zudem ein automatisiertes Monitoring und Reporting von Prozessmetriken in Workflows und BPM-Prozessen aufsetzen.

Die Realität sieht leider meist anders aus. Noch konnte die Kluft zwischen IT und Fachabteilungen nicht dadurch überwunden werden, Letzteren einfach ein Werkzeug zur Prozessmodellierung und programmierfreien Ausführung in die Hand zu geben. Dafür gibt es mehrere Gründe: Vielfach sind die Hersteller von BPM-Tools nicht identisch mit den Lieferanten der SOA-Technik. Die daraus entstehenden Probleme heißen mangelnde Kompatibilität, fehlende Integration der Modellierungs- und Entwicklungs-Tools und Herstellerabhängigkeit trotz einheitlicher technischer Standards. Außerdem stammen viele der bekanntesten BPM-Tools aus den frühen 90er Jahren und haben daher oft beim Umgang mit den aktuellen SOA-Standards mit ihrer eigenen Legacy zu kämpfen. So wird beispielsweise der BPEL-Standard (Business Process Execution Language) von vielen Tools zwar unterstützt, doch beschränkt sich diese Unterstützung in den meisten Fällen auf die Möglichkeit, BPEL zu importieren und zu exportieren.

Etliche der heute laufenden SOA-Projekte erscheinen stark technikgetrieben. Nicht selten sind es die IT- und nicht die Fachabteilungen, die SOA-Projekte initiieren. Ausgangspunkt einer SOA-Strategie sollten aber die Kernkompetenzen des Unternehmens sein, nicht die Applikationen.

Enterprise Architecture

Der Effekt einer SOA: Anstatt wie bisher IT-Systeme auf Prozesse zu setzen, werden die IT-Systeme in eine übergeordnete Unternehmensarchitektur eingebettet, Geschäftsprozesse konsequent in IT-Services übersetzt. Hierzu ist eine Gesamtunternehmensarchitektur (Enterprise Architecture) notwendig, welche die Anwendungsarchitektur in den Kontext der Geschäftsprozesse setzt. Prozess- und funktionale Grenzen innerhalb der Organisation sind zu durchbrechen.

Heute werden IT-Projekte meist aus funktionalen Organisationseinheiten heraus budgetiert und getrieben und dabei regelmäßig nur über mehr oder weniger eingehaltene IT-Standards auf eine gemeinsame Architektur hin abgestimmt. Auch wenn dieser Ansatz historisch verständlich ist - er macht es schwierig, wenn nicht unmöglich, die Konsistenz von Services und zugehörigen Daten in einer SOA sicherzustellen. Aus diesem Grund müssen IT- und Fachabteilungen kooperieren und die Unternehmensstrukturen in einer Unternehmensarchitektur definieren, die die organisatorischen und technologischen Möglichkeiten, das heißt die Geschäftsprozesse mit der Unternehmens-IT, verbindet.

Nur auf dieser Basis können die Beteiligten gemeinsam festgelegen, welche Services zu entwickeln sind und wie diese mit vorhandenen Systemen interagieren können. Auf Basis der gemeinsam mit dem Business-Management entworfenen Unternehmensarchitektur definiert der CIO dann die notwendigen Anwendungs-, Technologie- und Informationsarchitekturen und sorgt für deren Umsetzung. Die Unternehmensarchitektur dient außerdem als Grundlage für die BPM-Modellierung. Dieses konsequente IT-Business-Alignment sollte als grundlegendes Management-Konzept hinter jeder prozessorientierten SOA stehen. Für die Fachabteilung als Kunde bedeutet das, dass die IT nunmehr einen durchgängigen Geschäftsprozess liefert statt partieller IT-Unterstützung.

Systemlandschaft bereinigen

Wird die IT beim Übergang zu einer SOA an den Geschäftsprozessen ausgerichtet, erfordert dies zunächst eine Bereinigung der Systemlandschaft. Denn typischerweise gab und gibt es eine Applikation für jeden neuen Prozess - und zwar zu verschiedenen Zeitpunkten, mit unterschiedlichen Zielen, auf verschiedenen Plattformen und für verschiedene Benutzer. Damit verbunden sind wiederum unterschiedliche Service-Level-Agreements (SLAs) sowie Wartungs-, Modernisierungs- und Budgetzyklen. Die Integration derartiger Applikationen und Systeme ist mühsam und teuer, sowohl beim Einführen als auch im Betrieb. Tatsächlich steht die Bereinigung allerdings ohnehin in vielen Organisationen an, weil IT-Kosten und Komplexität stetig zunehmen.

Ist der Zielzustand erreicht, bleibt das Architektur-Management dennoch ein permanenter Prozess. Um auch künftig die IT an den Geschäftsprozessen auszurichten, ist daher ein Anforderungs-Management dringend zu empfehlen. Dabei geht es vor allem um IT-Effektivität, sprich "die richtigen Dinge zu tun". Beim Umsetzen der Anforderungen liegt der Schwerpunkt hingegen auf IT-Effizienz, also "die Dinge richtig zu tun". Die bestehende Unternehmensarchitektur wird in diesem Kontext permanent weiterentwickelt. (wh)