20 Jahre IBM-Prozessautomatisierung: was auf Container mitkommt

Im Portfolio von IBM stehen heute drei Prozessplattformen nebeneinander: Business Automation Workflow, Cloud Pak for Business Automation und Business Automation Manager Open Editions. Die naheliegende Annahme ist eine Ablösekette oder drei Ausbaustufen desselben Gedankens. Beides stimmt nicht. Es sind drei Antworten auf drei verschiedene Fragen, gestellt in drei verschiedenen Jahrzehnten, und die Reihenfolge, in der sie gestellt wurden, erklärt die Form der Produkte bis heute.

2002 bis 2005: Prozesse ziehen in den Application Server

Der Anfang liegt dort, wo damals alles lag, im WebSphere Application Server. Aus der Enterprise-Ausgabe wurde die WebSphere Business Integration Server Foundation, und darin steckte der Process Choreographer, die Komponente, die BPEL ausführte.

Für alle, die später dazugekommen sind: Die Business Process Execution Language (BPEL) war der Standard jener Jahre, um einen Geschäftsablauf als Abfolge von Web-Service-Aufrufen zu beschreiben und ausführbar zu machen. XML, maschinenlesbar, mit Verzweigungen, Fehlerbehandlung und Kompensation. Sie wird uns in diesem Text noch beschäftigen, und zwar bis ans Ende. Dazu kamen Business Rule Beans. Entwickelt wurde im WebSphere Studio Application Developer Integration Edition (WSAD IE), also im Eclipse-Werkzeug jener Zeit.

Parallel dazu lief eine zweite Linie, und die wird gern durcheinandergebracht. Im Januar 2002 schloss IBM die Übernahme von CrossWorlds Software ab, einem Anbieter für Anwendungsintegration aus Burlingame, dessen Nachrichtenschicht ohnehin auf MQSeries (heute MQ) von IBM aufsetzte. Daraus wurde der WebSphere InterChange Server (WICS) mit seinen Adaptern zu Bestandssystemen.

Zwei Erblinien also: die Prozessausführung aus dem Application Server, die Integration aus dem Zukauf.

2006: Der Höhepunkt der SOA-Idee

Der WebSphere Process Server 6 führte beides zusammen, und er verdient deutlich mehr als das Etikett „BPEL-Container“, das ihm nachträglich angehängt wurde.

Er brachte die Service Component Architecture (SCA) als Programmiermodell mit, mit der sich Komponenten unabhängig von ihrer Implementierung verdrahten ließen. Er brachte Mediation Flows und den WebSphere Enterprise Service Bus (WESB) mit, also die Schicht, die Nachrichten zwischen zwei Endpunkten umformt, weiterleitet und anreichert, damit beide Seiten nichts voneinander wissen müssen. Dazu Geschäftsregeln, Business State Machines, menschliche Aufgaben als eigene Komponentenart und die Adapter aus der CrossWorlds-Linie.

Im WebSphere Integration Developer (WID) ließ sich beides im selben Werkzeug bauen, der Ablauf und die Transformation zwischen zwei Endpunkten. Wer vorher zwei Produktwelten betrieb, den Application Server für Anwendungen und den damaligen Message Broker auf MQ-Basis für Integration, bekam hier eine.

Der Message Broker (WMB) war leistungsfähiger und blieb es. Er existiert heute noch, inzwischen als App Connect Enterprise (ACE). Aber er war eine eigene Welt mit eigener Werkzeugkette, und die Aussicht, alles in einem Application Server zu haben, hatte damals ihren Reiz.

Was BPEL nicht leisten konnte

BPEL entstand, als zwei Hersteller ihre Vorläufer zusammenlegten, IBMs WSFL und Microsofts XLANG. Später kamen weitere hinzu, die Standardisierung wanderte zu OASIS.

Der Zweck war die Orchestrierung von Web Services. Ein Ablauf, der Dienste in einer Reihenfolge aufruft, mit Kompensation und Fehlerbehandlung. Maschine zu Maschine. Menschliche Arbeitsschritte waren im ursprünglichen Entwurf nicht vorgesehen. Sie kamen später über zusätzliche Spezifikationen nach, aber ein Standard für die Oberflächen setzte sich nie durch. Jeder Hersteller löste es anders, bei IBM war es das WebSphere Portal. Der Aufwand dafür war erheblich, und durchgängig funktioniert hat es selten.

Dazu kamen drei Dinge, die beim Einsatz des Process Servers schwierig waren. Weil der Standard aus zwei Vorläufern verschmolzen war, trug er beide Denkweisen mit, die graphbasierte und die blockstrukturierte. Das machte ihn mächtig und schwer zu lehren. Ein BPEL-Prozess war ausführbares XML, das eine Maschine verstand und ein Fachbereich nicht. Für die Abstimmung brauchte man ein zweites Bild und hatte damit zwei Artefakte, die auseinanderlaufen konnten. Und für Versionierung laufender Instanzen, Deployment und Migration gab es keinen Standard, also genau für die Fragen, die im dritten Betriebsjahr entscheiden. Der Process Server war somit nicht das Problem. Die Sprache darin war es.

2010: Lombardi und der Wechsel der Perspektive

Am 16. Dezember 2009 kündigte IBM die Übernahme von Lombardi Software an, am 26. Januar 2010 war sie abgeschlossen.

Deren Produkt Teamworks war in fast jeder Hinsicht das Gegenteil des Process Servers. Statt Artefakte strikt standardkonform im Dateisystem zu halten und über EAR-Dateien auszuliefern, gab es das Process Center, eine zentrale Anwendung, die alle Artefakte in einer Datenbank hält, mit Versionierung, Wiederverwendung über Toolkits und Auslieferung von dort auf die Server. Statt BPEL gab es BPMN, eine Notation, die zuerst ein Bild für Menschen war und erst danach eine Ausführungssemantik bekam.

Das ist der entscheidende Unterschied, und er erklärt den Rest: BPMN setzte bei der menschlichen Arbeit an, BPEL bei der Maschine.

Aus Teamworks wurde zunächst die WebSphere Lombardi Edition, im April 2011 dann der IBM Business Process Manager in den Ausgaben Express, Standard und Advanced. Advanced trug die alte Welt mit, BPEL und die SOA-Komponenten des Process Servers die über Advanced Integration Services (AIS) mit der Lobardi-Welt verbunden wurden. Eine Zeit lang liefen beide Modelle nebeneinander im selben Produkt.

2018: Prozess und Fall

Der Name Business Automation Workflow (BAW) entstand 2018, als IBM den Business Process Manager mit dem FileNet Case Manager zusammenlegte und damit die Prozesslinie mit der Fallakten-Linie, die aus der FileNet-Übernahme von 2006 stammt.

Zwei Traditionen, die sich lange getrennt entwickelt hatten: der strukturierte Ablauf und der Fall, dessen Verlauf sich erst während der Bearbeitung ergibt. Entwickelt wird seither webbasiert statt im Eclipse-Client. Der BPEL-Container lebt noch, aber es ist klar, dass er langfristig abgekündigt wird.

2019: Red Hat und die Frage der Portabilität

Die nächste Frage stellte nicht IBM, sondern der Markt. Das gesamte Portfolio war an seine Unterlage gebunden, an bestimmte Betriebssysteme, bestimmte Application Server, Lizenzen nach der Prozessorleistung einer konkreten Maschine. Das funktionierte, solange Software dort blieb, wo sie installiert worden war. Ende der 2010er Jahre stimmte diese Annahme nicht mehr.

Am 9. Juli 2019 schloss IBM die Übernahme von Red Hat ab, für rund 34 Milliarden Dollar. Erzählt wird sie gerne als Linux-Geschäft, einen Blick wert ist aber OpenShift: eine Kubernetes-Distribution, die im Unternehmensumfeld bereits etabliert war, im Rechenzentrum wie bei allen großen Cloud-Anbietern lief und als herstellerneutral galt. Diesen Ruf hätte IBM mit einer eigenen Plattform schwer erwerben können, und selbst bauen hätte Jahre gedauert.

Wie zielgerichtet die Sache war, zeigt der Zeitabstand. Drei Wochen später, am 1. August 2019, kamen die Cloud Paks, das eigene Portfolio containerisiert und für OpenShift optimiert, über hundert Produkte umgestellt. Fünf gab es zu Beginn: Data, Applications, Integration, Automation und Multicloud Management.

Cloud Pak for Business Automation (CP4BA) führt zusammen, was über zwei Jahrzehnte zugekauft worden war. Content Services aus FileNet, Workflow Services aus der Lombardi-Linie, Entscheidungsregeln aus ILOG, Dokumentenerfassung mit Datacap, dazu Process Mining und Robotic Process Automation (RPA). Vorher getrennte Produkte mit eigenen Werkzeugketten und eigenen Lizenzen, jetzt auf gemeinsamer Grundlage und mit einem Kontingent virtueller Prozessorkerne, das zwischen ihnen verschoben werden kann.

Dieselbe Frage, zweimal beantwortet: BAWoC und WfPS

Hier fehlt in den meisten Darstellungen ein Stück, und es ist das Stück, das BAW-Betreiber heute am direktesten betrifft. Die Container-Frage wurde nämlich nicht nur mit dem Cloud Pak und später mit BAMOE beantwortet, sondern zweimal innerhalb der BAW-Linie selbst.

Der Unterschied in einem Satz: BAW on Containers (BAWoC) nimmt das Produkt mit auf Kubernetes, Workflow Process Service (WfPS) schneidet es auf den Workflow-Kern zurück. Beides sind Antworten auf dieselbe Frage, aber sie sind verschieden gemeint, und sie passen zu verschiedenen Häusern.

Die erste Antwort heißt Business Automation Workflow on Containers, kurz BAWoC, und sie ist die konservative. Das Produkt bleibt, was es ist, und zieht auf Kubernetes um. Workplace und Process Portal sind da, Fälle sind da, die Process Admin Console ist da, Deployment aus Business Automation Studio online wie offline. Was sich ändert, liegt darunter: Lastverteilung, Clustering und Hochverfügbarkeit kommen jetzt von Kubernetes statt vom Application Server, und unter der Anwendung läuft WebSphere Liberty statt dem traditionellen WebSphere Network Deployment. Für den Betrieb heißt das, dass die vertrauten Werkzeuge weg sind. wsadmin gibt es nicht mehr, an seine Stelle treten Operations REST APIs mit Swagger-Definition.

Interessanter als die Liste dessen, was mitkommt, ist die Liste dessen, was zurückbleibt. IBM nennt sie selbst, und sie liest sich für jeden, der die ersten Abschnitte dieses Textes gelesen hat, wie ein Nachruf auf 2006:

Advanced applications, die im IBM Integration Designer entstanden sind, also BPEL-Prozesse, Mediation Flows und SCA-Anwendungen, laufen auf Containern nicht. Ebenso wenig das Performance Data Warehouse, die XML-Event-Ausgabe des Dynamic Event Framework, Integrationen über WebSphere MQ und JMS sowie XML-Validierung und -Transformation.

IBM Documentation
Feature support in Business Automation Workflow on containers
BAW 26.0.x, Stand 02.11.2026
IBM nennt als Grund „architectural differences in Liberty“

Das ist der eigentliche Befund. Was den Sprung auf Container nicht mitmacht, ist fast punktgenau das Erbe des Process Servers. Die Komponentenarchitektur, der Mediation Flow, der BPEL-Prozess. Diese Artefakte wurden für einen Application Server mit einem bestimmten Programmiermodell gebaut, und das Modell gibt es dort, wo das Produkt jetzt läuft, nicht mehr.

Wer also BAW betreibt und die Advanced-Bestände noch im Haus hat, hat keine Portierung vor sich, sondern zwei Vorhaben. Eines davon ist eine Umstellung der Infrastruktur, das andere ist eine Neuimplementierung von Fachlogik, die meist von Leuten geschrieben wurde, die nicht mehr da sind. Eine Nebenbemerkung, die in dieselbe Richtung zeigt: IBM weist in der Cloud-Pak-Dokumentation darauf hin, dass der Integration Designer dort nicht enthalten sei. Wer noch Advanced Integration Services bauen will, sollte also früh prüfen lassen, was der eigene Vertrag an dieser Stelle hergibt.

Zwei Dinge für die Betriebsplanung, die man kennen sollte. Deprecated-Artefakte aus dem Desktop Process Designer laufen auf Containern nicht, mit einer Ausnahme: Heritage Human Services gehen mit, die darin enthaltenen Heritage Coaches allerdings nur zur Laufzeit, nicht mehr im Werkzeug. Und BAW on Containers 26.0.0.0 unterstützt kein Upgrade von vorherigen Container-Ständen. Wer plant, plant also nicht nur den ersten Umzug.

Die zweite Antwort heißt Workflow Process Service, kurz WfPS, und sie geht den anderen Weg. Statt das Produkt zu portieren, wird der Umfang zurückgeschnitten. Übrig bleibt der Kern: Abläufe, die menschliche Aufgaben und Dienste orchestrieren. Es gibt eine Authoring-Umgebung und eine Laufzeitumgebung, jede als ein einzelner Container, dazu bei Bedarf Elasticsearch in einem weiteren. Dokumenten- und ECM-Unterstützung ist nicht dabei, und das ist Absicht, nicht Rückstand.

„Leichtgewichtig“ zeigt sich dabei nicht nur im Speicherbedarf, sondern auch im Lizenzkontingent. IBM führt die Capabilities im Cloud Pak mit unterschiedlichen Verhältnissen, und Workflow Process Service steht dort spürbar günstiger als Business Automation Workflow Enterprise. In der öffentlichen Tabelle zu Lizenzen und Entitlements lagen die Produktionsverhältnisse im Oktober 2026 um den Faktor fünf auseinander.

Mit dieser Zahl gehen wir vorsichtig um, und Sie sollten das auch tun. IBM-Lizenzierung ändert sich von Jahr zu Jahr, Verhältnisse werden angepasst, und größere Häuser haben ohnehin ausgehandelte Bundles, in denen ganz andere Werte stehen. Was hier steht, ist deshalb nur die Richtung: Der schlankere Dienst ist auch im Kontingent der schlankere. Was bei Ihnen gilt, steht in Ihrem Vertrag und nirgends sonst. Lassen Sie das von jemandem nachsehen, bevor eine Variante ausgewählt wird, und glauben Sie keinem Anbieter, der Ihnen Ihre Lizenzlage aus der Ferne erklärt. Wir können das auch nicht.

Dafür fehlt bei WfPS mehr als nur die Dokumentenverwaltung. In der Gegenüberstellung der Varianten führt IBM die ECM-Dokumentenunterstützung ausdrücklich für Business Automation Workflow und ausdrücklich nicht für Workflow Process Service. Wer Fallakten mit Dokumenten braucht, ist hier falsch, und wer sie nicht braucht, zahlt bei der anderen Variante dafür mit.

Zum Zeitdruck, der oft dazu behauptet wird

In Beiträgen zu diesem Thema steht regelmäßig, die Modernisierung sei unvermeidbar, weil der Unterbau auf Java 8 aufsetze und dessen Unterstützung 2030 ende. Wir haben versucht, das zu belegen, und es ist uns nicht gelungen. IBM nennt für WebSphere Application Server 8.5.5 und 9.0.5 kein geplantes Support-Ende und hat erklärt, diese Stände über das von Oracle genannte Datum für Java 8 hinaus unterstützen zu wollen. Die Angaben, die zu Liberty kursieren, widersprechen sich untereinander.

Daraus folgt nicht, dass man liegen bleiben sollte. Es folgt nur, dass das Datum das schwächste der verfügbaren Argumente ist. Die tragfähigen sind betrieblicher Natur: Wer seine übrige Landschaft auf Kubernetes fährt, betreibt mit dem traditionellen BAW eine Insel mit eigener Werkzeugkette, eigenem Betriebswissen und eigener Personalfrage. Das kostet jeden Monat etwas, unabhängig davon, wann ein Hersteller etwas abkündigt.

Die Frage, die hinter der Migrationsfrage steht

Noch eine Verschiebung gehört dazu, und sie fehlt in fast allen Darstellungen zu diesem Thema: „Wohin migriere ich“ ist die kleinere Frage. Sie wird in einem Projekt beantwortet, und ein Projekt hat ein Ende, eine Abnahme und eine Schlussrechnung. Die größere Frage lautet, wer sich danach über Jahre um den Ablauf kümmert. Wer bemerkt, dass ein Vorgang steht, obwohl kein System ausgefallen ist. Wer beantwortet, warum Vorgang 4711 in Schritt drei hängt und ob man ihn wiederholen darf.

Ein Hersteller beantwortet, ob die Plattform läuft. Ein Migrationsprojekt endet mit der Abnahme. Dazwischen liegt die Zeit, in der ein Prozess Geld verdient oder eben nicht, und genau dort entscheidet sich, ob die Umstellung sich gelohnt hat. Wer eine Variante auswählt, sollte deshalb nicht nur fragen, wie der Umzug aussieht, sondern wer danach zuständig ist und was das im Monat kostet.

2022: Prozessautomatisierung ohne Plattform darunter

Damit war die Container-Frage beantwortet, aber eine andere blieb offen. Im mittleren Marktsegment gewannen leichtgewichtige Anbieter mit Microservice-Mustern, während IBMs Angebot dort strukturell zu groß war. Ein Cloud Pak setzt einen Cluster voraus, und der ist für ein Haus mit ein paar hundert Mitarbeitern ein eigenes Projekt vor dem eigentlichen.

Die Antwort lag wieder im Red-Hat-Bestand. Drools für Regeln und jBPM für Prozesse gab es dort seit rund zwei Jahrzehnten, zusammen mit OptaPlanner als eine Projektfamilie. Ab 2019 entstand Kogito, kein Nachfolger, sondern dieselbe Technik, neu gebaut für Container: BPMN für Abläufe, DMN für Entscheidungstabellen, beides als Quarkus- oder Spring-Boot-Anwendung, mit Flexibilität, Startzeiten und Speicherbedarf eines Microservice statt denen eines Application Servers.

2022 wanderte der Red Hat Process Automation Manager zu IBM und erschien als Business Automation Manager Open Editions, IBMs erstes Open-Source-Produkt für Geschäftsprozessautomatisierung. Der Unterbau wurde dabei offener statt geschlossener. Drools, jBPM, OptaPlanner, Kogito und SonataFlow stehen heute als Apache KIE unter dem Dach der Apache Software Foundation. Die Abkürzung steht für „Knowledge Is Everything“ und ist seit Jahren der Sammelname dieser Projektfamilie, mit gemeinsamer Community, gemeinsamer Website und gemeinsamem Veröffentlichungsrhythmus. Die Version 10.1.0 erschien im Juli 2025 als erster Meilenstein nach dem Neustart dort. Die Bibliotheken liegen öffentlich im Maven Central.

Was IBM dazu beiträgt, ist das, was einer offenen Codebasis im Unternehmenseinsatz fehlt: ein versionierter, geprüfter Auslieferungsstand, zuverlässige Container-Images, ein Veröffentlichungsplan, Sicherheitsaktualisierungen und Support.

Was daraus folgt

Über zwanzig Jahre zeigt sich ein Muster. Zweimal kam der Richtungswechsel über eine Übernahme. Lombardi, weil dort bei der Arbeit von Menschen angesetzt wurde und nicht bei der Maschine. Red Hat, weil OpenShift bereits dort lief, wo die Kunden waren. Die technische Substanz aus der SOA-Zeit ist dabei nicht verschwunden, sie steckt bis heute in der DNA der Produkte.

Praktisch bleibt davon sechsmal etwas hängen, und das ist der Grund für diesen Text.

1. BAW ist schwer, weil es für große Organisationen mit tiefer Integration gebaut wurde. Der Application Server darunter war kein Zufall, sondern eine Entscheidung aus der Zeit. Diese Entscheidung ist inzwischen zurücknehmbar, aber nicht umsonst.
2. Die BAW-Linie hat zwei Container-Antworten, und sie sind verschieden gemeint. BAWoC nimmt das Produkt mit, WfPS schneidet es zurück. Wer Fälle und Dokumente braucht, hat nur eine Wahl. Wer sie nicht braucht, zahlt bei der falschen Variante im Kontingent erheblich mehr als nötig. Wie viel genau, steht in Ihrem Vertrag und sollte vor der Auswahl nachgesehen werden.
3. Cloud Pak ist breit, weil es ein Portfolio vereinheitlichen sollte. Für ein Haus mit Container-Strategie ist die Plattform kein Preis, sondern ohnehin vorhanden. Für ein Haus ohne eine steht vor dem eigentlichen Vorhaben ein zweites.
4. BAMOE ist leichtgewichtig, weil es für Installationen gebaut wurde, die Sie selbst entwickeln. Es bringt im Auslieferungszustand keine Fachanwendung mit, sondern Dienste. Die Oberfläche, mit der ein Sachbearbeiter arbeitet, baut jemand anderes, zum Beispiel wir.
5. BPEL-Bestände sind kein Randthema, sie sind die Abbruchkante. Die Laufzeitumgebung wird es langfristig nicht mehr geben, und auf Container nimmt IBM ihn ausdrücklich nicht mit, zusammen mit Mediation Flows und SCA. Wer diese Artefakte im Haus hat, hat eine Neuimplementierung vor sich und sollte sie als solche planen und nicht als Umzug.
6. Die Frage nach laufenden Instanzen entscheidet Migrationen. Sie lassen sich unter bestimmten Voraussetzungen zwischen den Welten bewegen, aber nur unter klaren Bedingungen und mit genau einem Versuch. Wer sie erst im Projekt stellt, stellt sie zu spät.

Wer vor der Auswahl steht, kommt mit diesen sechs Sätzen hoffentlich weiter als mit jeder Gegenüberstellung von Funktionslisten. Die Frage ist nicht, welches Produkt mehr kann. Sie lautet: für welche Sorte Haus wurde es gebaut, und ist es das Ihre. Und direkt danach: Wer kümmert sich darum, wenn das Projekt vorbei ist.

Wo wir stehen

Wir betreiben und entwickeln alle Varianten: BAW auf WebSphere, BAW auf Containern, Cloud Pak auf Kubernetes und OpenShift, BAMOE als Grundlage unserer eigenen Fachanwendung. Unsere Leute haben diese Produkte über zwanzig Jahre seit ihrem Bestehen eingesetzt, betrieben und unterrichtet: von den Application Servern der frühen Jahre bis zu den Containern von heute.

Dass auf unserer Ausführungsseite nur IBM steht, ist keine Einschränkung, sondern das Ergebnis dieser zwanzig Jahre. Wer eine Produktlinie von BPEL im Application Server bis Quarkus im Container begleitet hat, kennt die Stellen, an denen eine Migration weh tut, und zwar bevor sie weh tut. Diese Kenntnis entsteht durch Tiefe und lässt sich nicht über acht Technologien verteilen.

Offenlegung, gehört dazu: Wir sind IBM-Partner und verdienen an diesen Produkten. Und zur Klarheit, weil es regelmäßig durcheinandergeht: BAW und Cloud Pak betreiben wir und entwickeln darauf. Was wir verkaufen, ist die Fachanwendung auf BAMOE und der Betrieb dazu.

Wenn Sie vor einer Migration stehen: Nennen Sie uns einen Ablauf, bei dem Sie nicht sicher sind, ob er den Sprung mitmacht. Daran lässt sich die Lage schneller beurteilen als an einem Architekturbild. Wir sagen Ihnen auch, wenn keines der Produkte die Antwort ist.