Moderne Anforderungen an Workflow, Transparenz und Kundenservice können auf Basis der traditionellen Großrechner-Datenhaltung nicht mehr erfüllt werden. Deswegen sind zahlreiche Unternehmen - ein Vorreiter waren hier die Banken - aus der Mainframe- in die Client-Server- beziehungsweise die Internet-Welt gewechselt und haben ihre Großrechner zugunsten von Server-Parks aufgegeben.

Große Unternehmen müssen schnell und flexibel auf Input von außen reagieren. Dabei kann es sich um Serviceanfragen, Verkaufszahlen, neue Gesetze und Ähnliches handeln. Außerdem konzentrieren sich zahlreiche Unternehmen auf ihre Kernkompetenzen und lagern Dienstleistungen aus, kaufen Vorprodukte hinzu etc. Dieser Trend, auch als vertikale Desintegration bezeichnet, zwingt Firmen dazu, ihre Wertschöpfungsketten auf das Outsourcing von ganzen Prozessschritten auszurichten.

Für die Softwareentwicklung bedeutet das: Sie muss Veränderungen kurzfristig abbilden und externe Elemente flexibel integrieren können. Große proprietäre Lösungen können dies heute kaum mehr leisten, ebenso wenig einzelne Softwareentwickler oder arbeitsteilige Ketten von Programmierern. Der Weg in die Zukunft ist deshalb klar vorgezeichnet: Möglichst viele Prozesse müssen automatisiert werden.

Die IT-Architektur eines Unternehmens muss der Motor dieser Entwicklung sein. Unternehmen, die sich dem Workflow-Gedanken verschreiben und ihre IT bereits in Services organisieren, sind auf dem richtigen Weg, Business Process Management (BPM) Realität werden zu lassen. Wer noch nicht reagiert hat, ist dringend gefordert, jetzt in seine Infrastruktur zu investieren. Mit BPEL (Business Process Execution Language, siehe unten) zeichnet sich ein großer informationstechnischer Sprung ab.

Arbeitsabläufe in IT abbilden

BPEL ermöglicht Geschäftsprozess-Management. Arbeitsabläufe in Unternehmen können schnell und kostengünstig in IT abgebildet werden. Insbesondere Veränderungen von Arbeitsprozessen lassen sich problemlos in der IT-Struktur nachvollziehen. Die Standardisierungsorganisation Oasis (Organization for the Advancement of Structured Information Standards) wird im ersten Halbjahr 2006 die BPEL-Version 2.0 veröffentlichen. Ab dann wird BPEL der von allen großen Softwareanbietern unterstützte Standard im Bereich BPM sein.

Vorläufige Funktionen aus BPEL 1.1 und 2.0 stecken bereits in Produkten wie dem "BPEL Process Manager" von Oracle oder IBMs "Websphere Process Server". Oracle baut beispielsweise auf einem Produkt des Unternehmens Collaxa auf und besteht aus einem Designer, einer Process Engine und einer Monitoring-Komponente. Das Produkt ist auf fast allen kommerziellen und Open-Source-Applikations-Servern einsetzbar; so kann es beispielsweise in den Oracle-10g-Applikations-Server, Bea Weblogic oder auch Jboss integriert werden.

Geringere Marktdurchdringung

BPEL ist also herstellerunabhängig. Deswegen hat diese Sprache auch gute Chancen, sich in diesem Bereich als Standard am Markt durchzusetzen. Anwendungen mit BPEL fehlte in Deutschland bislang noch die Marktdurchdringung. Doch das ändert sich gerade. Das Thema ist aus der Theorie in der Praxis angekommen.

Ein näherer Blick auf die BPEL-Welt von Oracle ermöglicht einen ersten Eindruck des komplexen Hintergrunds: Technisch ausgedrückt ist BPEL eine normierte XML-Sprache für die Ablaufumgebungen (Process Engines), die in der Lage sind, BPEL-Files als Steuerungsinformation zu nutzen, um Geschäftsprozesse ablaufen zu lassen. Ausgangspunkt ist ein BPEL-Designwerkzeug, mit dem man den Prozessfluss modellieren kann. Das Ergebnis dieses Vorgangs ist dann ein bpel.xml-File. Dieses gibt man nun in die BPEL-Engine, die, wenn man sie von außen anstößt, den Prozess in der Engine ausführt. Über die BPEL-Konsole kann man zusätzlich mit verschiedenenen Funktionen die Prozesse überwachen und verbessern.

Prozess-Design und -Tuning

Um sich die Abläufe klar zu machen, hilft eine Analogie aus dem Maschinenbau: An einem Produktionsprozess sind viele einzelne Roboter beteiligt. Schaltet man sie in sinnvoller Weise hintereinander, wird aus einzelnen Robotern eine zusammenhängende Produktionsstraße. Man kann in diesem Produktionsprozess eine Innovation erreichen, indem man alte Roboter gegen bessere, schnellere austauscht.

In diesem Beispiel steht der Roboter für die genutzten Services. Doch auch der Produktionsfluss lässt sich verändern, weil eine neue Technologie zur Verfügung steht oder in der Produktionsstraße ein neues Produkt herzustellen ist. Dies entspricht der Anpassung des Prozesses im BPEL-Prozessdesigner.

Die IT-Architektur eines Unternehmens muss also entsprechende Services bereithalten, die genau definierte Anforderungen umsetzen. BPEL ist eine Sprache, mit deren Hilfe sich diese einzelnen Services in die gewünschte Ablaufreihenfolge bringen lassen. Diesen Vorgang nennt man "orchestrieren". Die Ablaufreihenfolge entspricht letztlich dem zu unterstützenden Geschäftsprozess. Durch ein solches koordiniertes Zusammenspiel wird "Business Process Management" möglich - eine flexibel veränderbare Produktionsstraße entsteht.

Variabel verkettete Services

Sobald sich auf der Geschäftsprozessebene eine Änderung ergibt, verkettet man einfach die Services in einer anderen Art und Weise. Abstraktions-Frameworks sind in der BPEL-Engine so verallgemeinert angelegt, dass nicht nur Web-Services, sondern auch beliebige andere Technologien in den Ablauf der Prozesse integriert werden können: Java, J2EE, Enterprise Java- beans (EJBs), Messaging-Systeme, E-Mails, Datei- und Datenbankzugriffe etc. All diese Technologien kann man in der BPEL-Engine "andocken". Für den Mitarbeiter des Fachbereichs, der einen Prozess verändern will, sieht jedoch jeder Service "von oben" immer so aus wie ein Web-Service. Das ist ein wichtiger Normierungsschritt.

Um diesen Gedanken zu verdeutlichen, hilft eine Analogie zur Weiterentwicklung von neuen Rennwagen in der Formel 1: Vor jeder neuen Saison designen die Techniker eines Rennstalls neue Motorfunktionen. Sie implementieren diese in den aktuellen Boliden und gehen damit auf die Teststrecke. Unterwegs werden laufend Details wie Kurven- und Bremsverhalten oder Treibstoffverbrauch gemessen. Diese Daten werden anschließend ausgewertet und für die Verbesserung der Leistungsfähigkeit herangezogen.

IT prüft nur noch das Design

Übertragen auf das Design von Geschäftsprozessen bedeutet dies: Es gibt einen Kreislauf zwischen dem Design eines Prozesses, dessen Implementierung über eine BPEL-Engine und dem Monitoring. Am Ende steht das Optimieren des Prozesses. Die BPEL-Engine ist der Ort, an dem diese Änderungen vorgenommen werden.

Dieser Ansatz ermöglicht es den Mitarbeitern, die sich mit der fachlichen Analyse von Geschäftsprozessen beschäftigen, tatsächlich ausführbare BPEL-Prozesse auf einer technisch abstrakten Ebene zu modellieren und anschließend über einen Generator an die IT zu übergeben. Hierdurch vermindert sich der "Engineering Gap" erheblich, und die IT muss "nur noch" das Design prüfen, überarbeiten und den BPEL-Prozess ausführen.

Sobald sich auf der Geschäftsprozessebene eine Änderung ergibt, verkettet man einfach die Services in einer anderen Art und Weise. So hat man sofort reagiert, ohne einen kompletten Lifecycle in der Softwareentwicklung einschieben zu müssen. Geeignete qualitätssichernde Maßnahmen werden selbstverständlich vorausgesetzt.

Die Nutzung von BPEL fördert in zweierlei Weise die innerbetriebliche Innovation. Einerseits handelt es sich um eine informationstechnische Innovation: Mit BPEL entwickelt man automatisierte Prozesse besser und schneller und kann die fachlich notwendigen (Web-)Services effektiver identifizieren. Der zweite Innovationstreiber ist der Fachbereich: Wenn er den Arbeitsprozess anders organisieren möchte, modelliert er den Arbeitsfluss auf einer grafischen Ebene neu. Die BPEL-Engine ändert dann automatisch, basierend auf dem neuen BPEL-File, den auszuführenden Prozessfluss und nutzt die unterstützenden unterlagerten Services und Systeme.

Dieser Ansatz begreift Software nicht mehr als ein in sich abgeschlossenes "Werk"; ein System besteht vielmehr nur noch aus einer Ablaufumgebung, die fertige, lose gekoppelte Komponenten nutzt, die wiederum flexibel und schnell einzelne Aufgaben erledigen.

Der Aufwand schrumpft

Erste Praxistests in Deutschland haben ergeben: Mit einer BPEL-Engine gesteuerte Prozesse funktionieren sehr stabil. Bei einem Lasttest der Oracle BPEL Engine mit 500 gleichzeitigen Usern lief die Prototyp-Anwendung stabil und sogar schneller als gefordert. Und dies sowohl im Oracle-eigenen Application Server als auch in einer zu Testzwecken aufgesetzten Bea-Umgebung.

Die Hoffnung ist also berechtigt, dass durch den Einsatz von BPEL-Engines der Aufwand für das Programmieren neuer Services in Zukunft auf einen Bruchteil der heute benötigten Zeit schrumpfen könnte. Für Geschäftsprozesse bedeutet dies, dass Prozessveränderungen oder die Integration externer Services viel schneller als bislang realisiert werden können. (hv)