IBM Cloud Pak for Business Automation: Betrieb, Einführung, Migration
IBM Cloud Pak for Business Automation läuft auf Containern. Damit ist es kein Nachfolger von BAW auf WebSphere, sondern eine andere Welt – mit allem, was das an Möglichkeiten und an Fallstricken mit sich bringt.
Wir betreiben diese Umgebungen auf Kubernetes und OpenShift, entwickeln darauf und begleiten Organisationen, die eine solche Plattform aufbauen. Cloud Pak selbst kennen unsere Spezialisten seit 2019 – die Grundlage darunter deutlich länger: wir entwickeln seit 2014 cloud-native Software auf Kubernetes und OpenShift.
Für uns ist ein Cloud Pak deshalb eine Anwendung auf vertrautem Boden – und keine Plattform, die wir aus der Broschüre kennen.

01
Betrieb auf OpenShift und Kubernetes
Wir übernehmen den Betrieb auf Kubernetes wie auf OpenShift. Für beides haben wir die Kenntnisse im Haus, und zwar nicht nur für die Installation, sondern für den Zustand danach: Ressourcenverhalten unter Last, Verfügbarkeit einzelner Komponenten, Nachvollziehbarkeit im Fehlerfall.
Auch in kritischen Umgebungen. Unsere Leute kommen aus Häusern, in denen Anwendungen unter Last laufen und ein Ausfall unmittelbar spürbar ist.
02
Fachlicher Support
Bevor wir Verantwortung übernehmen, sehen wir uns Ihre Prozesse an und arbeiten uns ein. Erst danach übernehmen wir den Support – und zwar nicht nur den technischen.
Der Unterschied zeigt sich, wenn ein Vorgang steht. Ein System kann technisch einwandfrei laufen und trotzdem das Falsche tun: eine Freigabe, die niemand mehr erteilt, ein Vorgang in einem Zustand, den beim Entwurf niemand bedacht hat. Wer nur die Plattform kennt, sieht davon nichts.
Auf Wunsch schärfen wir die bestehende Implementierung nach: Monitoring der Prozessschritte und Überwachung der Fachdaten, damit ein stehender Vorgang zum Ticket wird, bevor er im Fachbereich auffällt.
03
Einführung und Architektur
Wenn Sie ein Cloud Pak aufbauen wollen, ist die Software der einfachere Teil.
Die Entscheidungen, die tragen müssen, liegen darunter und daneben: Wie ist der Cluster geschnitten, wie werden Zustände persistiert, wie sieht die Trennung zwischen Umgebungen aus, was passiert bei einem Update mit laufenden Vorgängen, wie kommt die Anbindung an Ihre Bestandssysteme in eine Form, die auch in drei Jahren noch wartbar ist. Dazu Speicher, Netz, Sicherung, Rechte.
Unsere Leute verstehen die Kette vom Dienst bis zur Hardware und können diese Entscheidungen begründen, statt sie zu übernehmen. Das ist nötig, denn nicht alles läuft so, wie es in der Produktbeschreibung steht – und die Stellen, an denen es abweicht, findet man selten beim Lesen, sondern im Betrieb.
Wir kennen nicht nur das Cloud Pak. Wir kennen den Boden, auf dem es steht.
FABIAN STEIGER, GESCHÄFTSFÜHRER ECCEENE
04
Migration von Altbeständen aus BAW
Der Wechsel von BAW auf Cloud Pak ist kein Umzug, sondern eine Übersetzung. Was auf WebSphere lief, läuft in Containern nicht einfach weiter.
Betroffen sind vor allem die Bestände, die über Jahre gewachsen sind: Artefakte aus früheren Migrationen, Bibliotheken, an denen niemand mehr etwas ändern will, und BPEL, das abgekündigt ist und in vielen Häusern trotzdem noch Fachlogik trägt. Wir haben Konzepte, diese Bestände zu überführen, ohne die Fachlichkeit neu zu erfinden.
Und dann sind da die laufenden Vorgänge. Die lassen sich mitnehmen – IBM sieht dafür einen Weg vor, und begonnene Prozesse laufen im Zielsystem zu Ende. Der Weg ist allerdings an Bedingungen geknüpft, die man vorher kennen muss: Die Versionen von Quell- und Zielsystem müssen exakt zusammenpassen. Als Quelldatenbank sind Db2, Oracle oder MSSQL vorgesehen. Die Benutzerverwaltung muss über LDAP laufen, und jeder betroffene Benutzer muss im Zielsystem existieren. Vorher sind die Anwendungen auf Kompatibilität zu prüfen und veraltete Aufrufe zu bereinigen. Und der Punkt, der die Sache ernst macht: Beim Transfer wird die Datenbank für die Container-Laufzeit umgeformt. Diesen Schritt gibt es genau einmal.
Das ist deshalb kein Arbeitspaket, das man nebenbei einplant. Wir kennen die Stellen, an denen es klemmt, und wir haben zusätzlich Exporter, die Vorgangsdaten aus den proprietären Strukturen herausholen – für die Fälle, in denen ein Teil des Bestands nicht mitwandern soll oder später noch für eine Auswertung gebraucht wird.
05
Training und Coaching
Wir bringen Ihnen das gerne bei, und dabei geht es weniger um Ihre Techniker als um den Fachbereich und die Entscheider.
Der häufigste Befund ist kein technisches Problem, sondern ein ungenutztes: Sie zahlen für eine umfangreiche Plattform, und im Haus weiß kaum jemand, was sie kann. Modellierung, Regeln, Auswertung, Entscheidungsmanagement – vieles davon ist vorhanden und wird nicht benutzt, weil es nie jemand erklärt hat.
Wir erklären es in der Sprache des Fachbereichs, nicht in der des Handbuchs. Bei Cloud Pak arbeiten wir seit 2019 damit – die Container-Grundlagen darunter unterrichten und bauen wir seit über zehn Jahren.
→ Woher Cloud Pak kommt
Das Problem. IBMs Software war jahrzehntelang an ihre Unterlage gebunden: bestimmte Betriebssysteme, bestimmte Application Server, Lizenzen nach Prozessorleistung einer konkreten Maschine. Das funktionierte, solange Software dort blieb, wo sie installiert worden war. Ende der 2010er Jahre stimmte diese Annahme nicht mehr – Kunden verteilten Lasten zwischen eigenem Rechenzentrum und mehreren Cloud-Anbietern und wollten sich an keinen davon binden.
Die Lösung kam über eine Übernahme. Im Juli 2019 schloss IBM den Kauf von Red Hat ab, die größte Akquisition der Firmengeschichte. Erzählt wird sie meist als Linux-Geschäft; der eigentliche Gegenstand war OpenShift. Red Hats Kubernetes-Distribution war im Unternehmensumfeld bereits etabliert, lief im Rechenzentrum ebenso wie bei allen großen Cloud-Anbietern und galt als herstellerneutral.
Wie zielgerichtet das war, zeigt der Zeitabstand: Drei Wochen nach dem Abschluss kündigte IBM die Cloud Paks an – das eigene Portfolio, containerisiert und für OpenShift optimiert. Über hundert Produkte wurden dafür umgestellt.
Ein Cloud Pak ist ein Bündel, kein einzelnes Produkt: vorintegrierte Software auf gemeinsamer Grundlage, lauffähig im eigenen Rechenzentrum, in einer privaten Cloud oder bei einem beliebigen öffentlichen Anbieter. Dazu ein verändertes Lizenzmodell – ein Kontingent virtueller Prozessorkerne, das innerhalb eines Cloud Pak zwischen den enthaltenen Produkten verschoben werden kann.
Cloud Pak for Business Automation führt zusammen, was IBM über zwei Jahrzehnte zugekauft hat: Content Services aus FileNet, Workflow Services aus der Lombardi-Linie, Entscheidungsregeln aus ILOG, Dokumentenerfassung mit Datacap, dazu Process Mining und RPA. Vorher waren das getrennte Produkte mit eigenen Werkzeugketten und eigenen Lizenzen.
Was daraus folgt. Das Cloud Pak ist breit, weil es ein Portfolio vereinheitlichen sollte – nicht, weil ein einzelner Kunde all das braucht. Und es setzt einen Cluster voraus, weil Portabilität der Zweck der ganzen Übung war: Wer Software überall gleich laufen lassen will, braucht überall dieselbe Schicht darunter.
Für ein Haus mit einer Container-Strategie ist das kein Preis, sondern ein Vorteil – die Plattform ist ohnehin da. Für ein Haus ohne eine solche Strategie steht vor dem eigentlichen Vorhaben ein zweites.
→ Weiterlesen
Schatten-KI: Warum das Verbot das Falscheste ist, was Sie tun können
4 von 10 Unternehmen vermuten private KI-Nutzung, nur 26% bieten selbst etwas an. Warum die verdeckte Nutzung eine kostenlose Bedarfsanalyse ist.
13% fürchten um ihre Existenz: Wie Mittelständler jetzt automatisieren sollten
13% der Unternehmen sehen ihre Existenz bedroht, 2024 waren es 4. Warum drei berechtigte Einwände den Einstieg blockieren und wie sie sich…
Ohne Nullmessung ist jeder ROI eine Meinung
62% der KI-Anwender halten sich für Nachzügler, obwohl sie vorn liegen. Warum der Vergleichsmaßstab fehlt und wie eine Nullmessung ihn liefert.
Warum Ihre Einsparungen nie in der Bilanz ankommen
Effizienz hat eine Decke. Warum Einsparungen gefühlt bleiben, wenn jede Abteilung anders rechnet, und mit welcher Rechnung aus Bauchgefühl ein Betrag wird.
Ihr erfahrenster Mitarbeiter geht in vier Jahren? Sein Wissen muss vorher raus.
Die Fachkräftelücke ist um ein Viertel geschrumpft, aber nur wegen der schwachen Konjunktur. Warum die nächsten Jahre das Zeitfenster sind, um Wissen…
Prozessautomatisierung: Warum jeder Systemwechsel Sie zweimal bezahlen lässt
Migrationswerkzeuge nehmen das Customizing mit, die Logik zwischen den Systemen nicht. Warum sie beim Wechsel neu gekauft wird und wie Sie das…