Service-orientierte Architekturen (SOA) und Business-Process-Management (BPM) gehören zu den wichtigsten Entwicklungen in der IT-Branche. Während SOA heute noch weitgehend ein IT-Thema ist, das eine bessere Handhabung von historisch gewachsenen, heterogenen Anwendungslandschaften verspricht, liegt der Schwerpunkt von BPM stärker auf der Fachseite. Diese befasst sich mit der Analyse, Planung, Steuerung und Optimierung von Geschäftsprozessen.

BPM verbessert das Alignment von Business und IT

Unter dem Begriff BPM wird heute außerdem vermehrt die IT-basierende Automatisierung von Prozessen verstanden. Prozessorientierung verspricht verschiedene Vorteile: Neben einer höheren Flexibilität ermöglicht BPM eine bessere Nachvollziehbarkeit und Kontrolle durch die Fachseite. Darüber hinaus entsteht die Chance einer kontinuierlichen Verbesserung der Geschäftsprozesse. Aus der IT-Perspektive verspricht die Prozessorientierung, mehr Struktur auf höchster Ebene in die Anwendungslandschaften zu bringen und so das Zusammenspiel von IT und Business zu verbessern.

Für die effiziente Anwendung von BPM ist ein Verständnis der Prozess-Charakteristika wichtig. BPM entfaltet insbesondere dann sein volles Potenzial, wenn es sich um hoch dynamische Prozesse oder um Prozesse mit hohem Optimierungspotenzial handelt. Eine weitere wichtige Frage ist, inwiefern die aus dem Blickwinkel von BPM betrachteten Prozesse heute eher explizit oder implizit definiert sind: Generelles Ziel des BPM-Ansatzes ist es, Prozesse explizit zu machen, beispielsweise durch Dokumentation oder Abbildung auf eine IT-Lösung. Allerdings findet sich heute nur in den wenigsten IT-Systemen eine zentrale Stelle, an der die Prozesssteuerung verwaltet wird. Vielmehr ist die Prozesslogik normalerweise implizit in der Präsentations-, Mid-Tier-, Backend- und Datenbanklogik enthalten.

Das explizite Sichtbarmachen von Prozessen findet häufig über mehrere Jahre und in mehreren Evolutionsstufen statt. Business-Intelligence- (BI-)Tools ermöglichen Aussagen über die Performance impliziter Prozesse, da sie ja die Daten analysieren, die das Resultat dieser Prozesse sind. Werkzeuge für das Business Activity Monitoring (BAM) ermöglichen zudem das Überwachen von Prozessen in Echtzeit. BAM ist vor allem deshalb interessant, weil es nachträglich und nichtinvasiv in implizite Prozess-Implementierungen eingebettet werden kann. Die letzte Ausbaustufe ist der Einsatz eines Business Process Management Systems (BPMS), das eine echte Prozessdigitalisierung ermöglicht (siehe Grafik "Die BPM-Vision").

Digitale Prozesse - die BPM-Vision

In den letzten Jahren bedeutete Prozess-Implementierung häufig den langen und kostspieligen Umweg von Visio-Diagrammen über UML (Unified Modeling Language) nach J2EE oder vergleichbaren Mitteln. In der BPM-Vision entwickeln sich formale Prozessbeschreibungen zur gemeinsamen Sprache von Business und IT. Das BPM-System unterstützt ein nahtloses Prozessdesign, ferner Ausführung, Monitoring, Analyse und Redesign. Eine Prozessanpassung bedarf in diesem Szenario keines IT-Projektes mehr, sondern kann sofort ausgeführt werden.

Auch wenn etliche Plattformanbieter heute viel in die Realisierung dieser Vision investieren, muss das dafür nötige Zusammenspiel der unterschiedlichen Komponenten sehr genau verstanden werden, wie im Folgenden erläutert wird. Das Zusammenspiel von BPM, SOA und verwandten Techniken wird heute häufig unter dem Begriff "Enterprise SOA" zusammengefasst (siehe gleichnamige Grafik). Im obersten Layer (1) dieses Schichtenmodells liegen Portale zur Prozessausführung sowie zum Monitoring und der Analyse von Prozessen. Dabei werden sowohl implizite Prozesse (BI, Stand-alone BAM) als auch explizite Prozesse (BPM mit BAM) unterstützt.

Der Prozess-Layer (2) umfasst neben dem Prozess-Management auch das zentrale Erstellen und Verwalten von Geschäftsregeln, häufig auf Basis eines Business-Rules-Management-Systems (BRMS). Dieses übernimmt die Entscheidungssteuerung für das Prozess-Management und erlaubt schnelle und direkte Änderungen der Regeln durch den Fachbereich.

BPM-Systeme nutzen Geschäftslogik in SOA-Services

Um Prozessschritte ausführen zu können, muss das BPMS auf Anwendungslogik zugreifen, die in Form von SOA-Services bereitgestellt wird. Basic Services (4) liefern dabei existierende Anwendungslogik (5) und einen einheitlichen Zugriff auf operative Daten (6). Zugreifen kann das BPMS darauf über den Enterprise Service Bus (7). Auch viele Data Warehouses spielen heute die Rolle von operativen Datenquellen, auf die zunehmend über SOA-Services zugegriffen werden kann (8).

Häufig ist es sinnvoll, existierende Anwendungslogik in höherwertige und stärker fachbezogene Composite Services (3) zu aggregieren. Viele BPMS unterstützen hierzu die Serviceorchestrierung. Dabei handelt es sich häufig um eine technische Orchestrierung. Daher ist es sinnvoll, diese technischen Orchestrierungen - häufig mehrere hundert - im BPMS von den rein fachlichen Prozessen - normalerweise weniger als hundert - zu trennen.

Das lässt sich beispielsweise mit unterschiedlichen Namespaces regeln. Ein Geschäftsprozess ist dadurch gekennzeichnet, dass er für den Fachbereich verständlich ist, potenziell lange läuft und Benutzerinteraktion enthält. Eine Orchestrierung dagegen aggregiert elementare Operationen, läuft in der Regel sehr kurz (Millisekunden) und enthält nur Interaktionen zwischen Maschinen.

Neben dem Zusammenwachsen von SOA, BPM und BRM spielt Business Intelligence (BI) eine weitere wichtige Rolle in der Enterprise SOA: Im Kontext von BI werden SOA-Konzepte zunehmend genutzt, um historisch gewachsene, komplexe BI-Umgebungen besser in den Griff zu kriegen. So genannte Analytic SOA Services (3) werden als Strukturierungsmittel und grundlegende Bausteine für analytische Anwendungen verwendet (semantische Integration). Innovative Hersteller erlauben zusätzlich die flexible Kombination von klassischen Data-Warehouse-Analysen mit dem Echtzeitzugriff auf operative Daten (9) über Web Services.

Wie die Elemente zusammenspielen

Das Einbinden der BI in die Enterprise SOA ermöglicht außerdem die effizientere Steuerung von Prozessen im BPM über KPIs (Key Performance Indikatoren, 10). Dies ist bedeutend, weil KPIs Aussagen über die Prozess-Performance machen und damit einen wichtigen Input für die Prozesssteuerung und -optimierung liefern.

Eines der wichtigsten Ziele beim Strukturieren der SOA ist die Trennung von Anwendungslogik mit verschiedener Charakteristik. Dabei sind Änderungshäufigkeit und die Person, die die Änderung vornimmt, wichtige Kriterien (siehe Tabelle "Elemente der Enterprise SOA"). Die Unterschiede lassen sich anhand der Politik für die Kostenerstattung in der privaten Krankenversicherung erläutern: Der generelle Prozessablauf, der von der Poststelle über die medizinische und gebührenrechtliche Prüfung der einzelnen Fälle bis zur Auszahlung reicht, ist durch die Aufbauorganisation und die grundsätzliche Arbeitsteilung in der Schadensabteilung relativ fest vorgegeben. Eine langfristige Prozessanalyse und -optimierung lässt sich hier am besten mittels BPM erreichen.

Im Rahmen dieses Prozesses möchte man aber auch auf Tagesbasis Steuerungskriterien beeinflussen. Tritt beispielsweise vermehrt Missbrauch im Zusammenhang einer bestimmten Diagnose auf, wird das Unternehmen zielgerichtet in diesem Bereich prüfen wollen. Dadurch wird der grundsätzliche Prozessablauf nicht verändert, aber die Verteilung verschoben, welche Fälle maschinell reguliert werden und welche vorher manuell zu prüfen sind. Eine solche taggenaue Steuerung wird durch das Anpassen entsprechender Regeln in einem BRM-System ermöglicht. Dieser Beitrag des BRM für die Enterprise SOA rückt auch für die Hersteller von BRM-Plattformen immer stärker in den Mittelpunkt der Produktentwicklung.

Metadaten halten die SOA zusammen

Ein gutes Verständnis der unterschiedlichen Artefakte einer Enterprise SOA (Prozesse, Regeln, Aktivitäten, Services) und deren Zusammenspiel ist elementar für den Erfolg. Für das Management der SOA-Artefakte nutzen Unternehmen idealerweise ein Metadaten-Repository. Damit lassen sich Informationen über die Syntax und Semantik der verschiedenen SOA-Artefakte verwalten, ferner Zusammenhänge aufzeigen, analysieren und visualisieren. Die Daten im Repository geben den Nutzern wichtige Informationen über die operationalen Abhängigkeiten und Auswirkungen im Änderungsfall.

Eine Enterprise SOA ist fast ausnahmslos in einem heterogenen Systemumfeld angesiedelt. Häufig wird auch die zugrunde liegende Plattform nicht aus einem Guss sein, sondern Produkte von mehreren Herstellern umfassen. In diesem Fall ist es wichtig, dass das Metadaten-Repository für den Einsatz in einem solch heterogenen Umfeld geeignet ist. Marktführende Produkte zeichnen sich durch große Offenheit und Anpassbarkeit aus.

Repositories verwalten Artefakte der SOA

Spezielle SOA-Repositories konzentrieren sich auf die Verwaltung von grundlegenden SOA-Artefakten wie WSDL, Policy-Metadaten oder XML Schemas. Das Anwendungsfeld für Metadaten in einer Enterprise SOA ist allerdings wesentlich breiter; es umfasst beispielsweise Informationen über das Zusammenspiel von Prozessdefinitionen via BPML (Business Process Modeling Language), Business Rules und SOA-Services. Auch die SOA-basierende Komponentisierung und Entflechtung von großen Mainframe-Anwendungen lässt sich mit Hilfe eines Metadaten-Repositories steuern, indem beispielsweise Informationen über die Implementierung "hinter" den SOA Interfaces verwaltet werden. Dabei kann es sich etwa um interne Interfaces und Call-Dependencies handeln, aber auch um Datei- und Tabellenzugriffe.

Viele Unternehmen fangen heute damit an, verschiedene Metadaten-Repositories föderiert einzusetzen, um so eine umfassende Sicht auf planungsrelevante Informationen in der IT zu erhalten. Weitere Repository-Klassen, die hier eine Rolle spielen, umfassen beispielsweise Configuration Management Databases (CMDB), EAM Repositories (Enterprise Architecture Management) und PPM Datenbanken (Projekt-Portfolio-Management). Aufgrund der vielen Abhängigkeiten ist die größte Herausforderung für ein erfolgreiches SOA-Metadaten-Management die organisatorische Disziplin. Ohne ein solches Metadaten-Management fehlt indes die Voraussetzung dafür, Geschäftsprozesse in einer Enterprise SOA auf den verschiedenen Abstraktionsebenen sichtbar zu machen, und damit die notwendige Kontrolle über sie zu gewinnen.

Wege zur Enterprise SOA - Bottom-up oder Top-down?

Das erfolgreiche Einführen einer Enterprise SOA hängt von vielen Faktoren ab. Einerseits ist es hilfreich, ein Sponsoring auf der Ebene der IT Executives zu erhalten. Andererseits wird es immer nötig sein, auch dem Business schnell die Vorteile aufzuzeigen. Es gilt daher, Quick Wins zu erreichen und einzelne Erfolge zu dokumentieren und zu kommunizieren, bevor ein Durchsetzen der Enterprise SOA auf globaler Ebene möglich ist. Dazu gibt es zwei prozesszentrische Umsetzungsmodelle: den BPM-getriebenen Top-down-Ansatz und den BAM-getriebenen Bottom-up-Ansatz.

Ein Top-down-Vorgehen lässt sich umsetzen, wenn eindeutige Ziele existieren, einhergehend mit einer klaren Vorstellung der umzusetzenden Prozesse. In diesem Falle wäre das vereinfachte Vorgehen wie folgt: Zunächst werden Prozesse identifiziert, das heißt Namen und Kurzbeschreibungen festgelegt, allerdings keine Detaildiagramme. Im zweiten Schritt definiert das Projektteam für jeden Prozess Aktivitäten, das heißt Namen und Kurzbeschreibungen. Auch hier sind noch keine Details gefragt, die Reihenfolge der Aktivitäten im Prozess ist noch irrelevant.

Prozesse auf SOA-Domänen abbilden

Im nächsten Schritt werden die Aktivitäten auf die SOA-Domänen-Architektur abgebildet: Welche Prozessaktivität benötigt Services aus welcher Domäne? Es folgt ein globaler Abgleich über alle zur Implementierung anstehenden Prozesse (Synergien identifizieren). Danach können die Mitarbeiter Services unter Berücksichtigen von Wiederverwendung im Detail entwerfen, ferner Prozesse und Aktivitäten ebenfalls detailliert modellieren. Was bleibt, ist die technische Implementierung. Last, but not least sollten BPM-Fähigkeiten ausgenutzt werden, um Prozesse zu optimieren.

Ein Bottom-up-Vorgehen ist sinnvoll, wenn es bereits viele implizite Prozesse gibt, die Transparenz aber unzureichend und der Business Case oder der Prozessfokus nicht ganz klar ist. In diesem Falle würden Unternehmen mit den Mitteln des Business Activity Monitoring (BAM) anfangen, Transparenz zu schaffen, indem die impliziten Prozesse sichtbar gemacht werden. Unabhängige BAM-Hersteller erlauben das nichtinvasive Umsetzen von Echtzeit-Prozess-Dashboards durch den Einsatz so genannter "Probes", die sich einfach in die existierende Systemlandschaft integrieren lassen. Insbesondere wenn dieser Ansatz mit dem Erstellen eines Bebauungsplanes kombiniert wird, der den Zusammenhang zwischen Prozessen und Anwendungen aufzeigt, kann schnell ein gutes Verständnis für die Ist-Umsetzung der Geschäftsprozesse in der Systemlandschaft erzielt werden.

Auf Basis der so gewonnenen Informationen lässt sich eine aussagekräftige Analyse des Potenzials für die Prozessoptimierung erstellen und dadurch letztendlich ein besserer Business Case. Anhand des Ist-Bebauungsplanes entwickeln Projektverantwortliche schließlich einen Soll-Bebauungsplan, der den fachlichen Schnitt möglicher SOA Services beinhaltet. (wh)

Elemente der Enterprise SOA

Enterprise SOA Artefakt Container / Plattform Verantwortlichkeit Person Änderungshäufigkeit

SOA Service Transaktionscode (Java, COBOL, etc) IT-Abteilung Technischer Entwickler Quartal

Orchestrierung Transaktionscode oder BPMS IT Abteilung Technischer Entwickler Quartal / Monat

Prozess, Aktivität BPMS IT Abteilung Fachbereichskoordinator Monat

Technische Regeln BRMS IT-Abteilung Fachbereichskoordinator Woche

Fachliche Regeln BRMS Fachbereich Fachbereich Tag