Dieser Artikel konzentriert sich auf zwei dieser Probleme: den operativen Aufwand für den Betrieb von ODM und die Belastung durch das Vokabular, aufgrund derer Fachanwender weiterhin von Entwicklern abhängig sind. Beide werden so dargestellt, wie sie sich in ODM zeigen und wie DecisionRules sie löst.
Die beschriebenen Muster sind branchenunabhängig. Sie gelten unabhängig davon, ob die Regeln Kreditvoraussetzungen, Underwriting in Versicherungen, Telekommunikationspakete oder staatliche Leistungsansprüche betreffen.
Was ist eine Business Rules Engine?
Eine Business Rules Engine (BRE) dient einem einzigen Zweck: Automatisierte Geschäftsentscheidungen sollen kostengünstig, schnell und sicher geändert werden können. Die Entscheidungen selbst gehören in die Verantwortung des Fachbereichs. Die BRE ermöglicht es dem Fachbereich, diese Verantwortung zu übernehmen.
Eine geeignete BRE besteht einen einfachen Test: Ein Product Manager, Compliance-Verantwortlicher oder Risikoverantwortlicher kann sie öffnen, den aktuellen Stand in production prüfen, einen Schwellenwert ändern und die Änderung bereitstellen, ohne dafür ein Entwickler-Ticket einzureichen. Genau das bedeutet „Automatisierung“.
Eine BRE, die neue spezialisierte Rollen, neue Bereitstellungs-Pipelines und zusätzliche zu wartende Infrastruktur erfordert, löst das falsche Problem.
Problem 1: Der Infrastrukturaufwand
In ODM
Eine Bereitstellung besteht nicht aus einem einzelnen Produkt, sondern aus einem vollständigen Stack: einem Application Server wie WebSphere, Liberty, JBoss, WebLogic oder Tomcat, einer relationalen Datenbank für das Regel-Repository, Decision Center als Umgebung für die Regelerstellung, Decision Server als Runtime, mehreren bereitstellbaren Archiven, Profilkonfigurationen, optionalem Clustering für Hochverfügbarkeit und einer eigenen Umgebung für jede Phase.
Jede ODM-Umgebung umfasst einen vollständigen Stack, den das Team installiert, patcht und für jede Phase repliziert.
Patching, Upgrades und Kapazitätsplanung erfolgen vollständig intern. Die erforderlichen Kenntnisse umfassen die Administration von WebSphere, die internen Strukturen von ODM und die Java-Enterprise-Integration. Das sind spezialisierte Bereiche mit einem eigenen Markt für Fachkräfte. Fachanwender können Regeln in Decision Center erstellen, doch die darunterliegende Bereitstellung bleibt Aufgabe von Entwicklern und Systemadministratoren.
In DecisionRules
DecisionRules wird als Managed Service bereitgestellt. Zur Auswahl stehen Public Cloud, also SaaS auf AWS in US- oder EU-Regionen, Private Managed Cloud, also eine dedizierte Umgebung in einer vom Kunden gewählten Region, die üblicherweise innerhalb weniger Tage einsatzbereit ist, oder Self-Hosted als Docker- oder Kubernetes-Bereitstellung, auch air-gapped.
Alle drei Modelle verwenden dieselbe UI, dieselben APIs und dieselben Kenntnisse.
Alle drei Bereitstellungsmodelle verwenden dieselbe UI, dieselben APIs und dieselben Kenntnisse.
Bei Public Cloud und Private Managed Cloud müssen Kunden nichts installieren, patchen oder skalieren. DecisionRules betreibt die Plattform vollständig.
Self-Hosted-Bereitstellungen bestehen aus einem einzelnen Container und einer MongoDB-Instanz, die vom jeweiligen Team verwaltet wird. Der Application Server, eine separate Autorenoberfläche und die Replikation des vollständigen Stacks für jede Phase entfallen dennoch.
Problem 2: Die Belastung durch das Vokabular
In ODM
Fachanwender schreiben Regeln nicht in frei formuliertem Englisch. Sie setzen sie aus einem kontrollierten Vokabular zusammen, das Entwickler im Voraus erstellt haben. Die Kette besteht aus vier Ebenen. Drei dieser Ebenen liegen hinter einer Grenze, die Fachanwender nicht überschreiten können.
Drei der vier Ebenen liegen hinter einer Grenze, die nur ein Entwickler überschreiten kann.
Wenn ein Fachanwender ein Konzept benötigt, das noch nicht im Vokabular enthalten ist, etwa ein neues Flag, eine neue Berechnung oder ein neues Feld, muss ein Entwickler das XOM erweitern, das BOM aktualisieren, das neue Element verbalisieren und erneut veröffentlichen. Erst danach erscheint der Ausdruck im Dropdown. Auch das Vokabular selbst muss laufend gepflegt werden: Standardmäßige Verbalisierungen sind nicht immer benutzerfreundlich, große BOMs erzeugen unübersichtliche Vokabulare und verlangsamen den Editor. Entwickler verbringen daher erhebliche Zeit mit der Bereinigung über Categories und Virtual Methods.
In DecisionRules
Das Modell wird auf zwei Ebenen reduziert. Die Eingabe- und Ausgabeschemas der Regel bilden das Vokabular. Schema und Regel befinden sich in derselben Umgebung, werden von denselben Personen bearbeitet und durchlaufen denselben Review-Zyklus.
Schema und Regel befinden sich in einer gemeinsamen Umgebung. Ein neues Feld steht deshalb unmittelbar nach seiner Erstellung zur Verfügung.
Sobald ein Feld im Schema vorhanden ist, steht es unmittelbar als Bedingungsspalte oder Ausgabespalte in der Tabelle zur Verfügung. Es gibt kein separates Objektmodell, keinen zusätzlichen Schritt zur Verbalisierung und kein Entwickler-Ticket, um eine neue Variable zugänglich zu machen.
Ein konkretes Beispiel: Kumulativer Bonus
Das folgende Beispiel ist eine reale ODM-Regel aus einem Regelprojekt zur Bonusberechnung. Die fachliche Absicht lässt sich in einem Satz zusammenfassen: Wenn ein Mitarbeiter sowohl SMART-Auszeichnungen als auch SYNERGY-Auszeichnungen besitzt, werden die SMART-Bonusbeträge addiert und die Gesamtsumme zu jeder SYNERGY-Auszeichnung hinzugefügt.
Das für Analysten lesbare Englisch basiert auf einer Java-Klasse, die ein Entwickler zuvor erstellt hat.
Beim Öffnen dieser Regel in Decision Center ist der Code aus dem Screenshot nicht sichtbar. Stattdessen erscheint die BAL-Ansicht mit lesbarem Englisch, das der Analyst bearbeiten kann:
for each award in smart awards do set 'smart total' to smart total + the bonus amount of the award;
for each award in synergy awards do set the bonus amount of the award to the bonus amount of the award + smart total;
Die Formulierung ist flüssig. Schwellenwerte können geändert, Bedingungen ergänzt und Kategorien umbenannt werden. Dieser Teil ist nicht das Problem.
Schwieriger ist es, den Inhalt des Dropdowns zu ändern.
Jeder Ausdruck, den Sie in dieser BAL lesen, etwa „the bonus amount of the award“, „smart awards“, „synergy awards“ erscheint im Dropdown nur, weil ein Entwickler eine Java-Klasse für Award, mit einem Feld namens bonusAmount erstellt, sie über ein Business Object Model verfügbar gemacht und die englische Verbalisierung manuell formuliert hat. Wenn der Fachbereich am nächsten Tag einen regional bonus modifier zur Regel hinzufügen möchte, ist dies nicht direkt möglich.
Die flüssige Regelerstellung ist real, funktioniert aber nur innerhalb des Vokabulars, das ein Entwickler vorbereitet hat.
Dieselbe Regel in DecisionRules bleibt in Ihrer Hand
In DecisionRules wird dieselbe fachliche Absicht durch einen Decision Flow umgesetzt, der eine Decision Table aufruft. Beide werden im Browser erstellt. Beide bleiben in Ihrer Hand.
Der Flow macht die Orchestrierung nachvollziehbar, während die Tabelle die Entscheidung für jede Auszeichnung enthält. Beide können im Browser bearbeitet werden.
Der obere Flow zeigt den gesamten Algorithmus auf einen Blick: Die SMART-Gesamtsumme wird einmal aggregiert, die Liste der Auszeichnungen wird durchlaufen, für jede Auszeichnung wird die darunterliegende Tabelle aufgerufen und die Ergebnisse werden in der Ausgabe gesammelt. An dieser Grenze wird die Aufgabe übergeben. Der Flow übernimmt ab diesem Punkt nicht mehr die Orchestrierung. Die Tabelle übernimmt die Entscheidung für jede einzelne Auszeichnung.
Diese Tabelle bildet den Kern der Regel und lässt sich in einem Durchgang lesen. Bei SYNERGY-Auszeichnungen wird die SMART-Gesamtsumme zum Bonus hinzugefügt, bei allen ELSE-Fällen bleibt der Wert unverändert. Eine Änderung des Schwellenwerts von „größer als 0“ auf „größer als 100“ erfordert lediglich eine Anpassung der Zelle und eine erneute Veröffentlichung. Eine dritte Zeile für einen neuen Auszeichnungstyp wird auf dieselbe Weise hinzugefügt: Die Zeile wird ergänzt, die Zellen werden ausgefüllt und anschließend wird die Regel veröffentlicht. Dafür sind weder ein Entwickler noch eine Java-Klasse oder ein Ticket erforderlich.
Der Flow oberhalb der Tabelle macht die Orchestrierung nachvollziehbar. Der Aggregationsschritt ist ein einzelner Node, auf den alle Beteiligten verweisen können. Die Iteration ist ein einzelner Node. Die Entscheidung für jede Auszeichnung ist ebenfalls ein einzelner Node, und dieser Node ist die gerade beschriebene Tabelle. Der Collect-Node benennt genau, wohin das Ergebnis geschrieben wird. Unterhalb der Oberfläche bleibt nichts in einem generierten, nicht bearbeitbaren Formular verborgen.
Was geschieht mit dem regionalen Bonusmodifikator, der in ODM an dieser Grenze scheitert? Entscheidend ist nicht, dass diese Regel schwierig wäre. Selbst eine kleine Regel erreicht jedoch eine Grenze, sobald ein Konzept benötigt wird, das der Entwickler nicht im Voraus bereitgestellt hat. In DecisionRules existiert diese Barriere nicht, weil die Ebene, die sie erzeugt, nicht existiert.
Die Zuordnung: Was entspricht welchem Element?
Eine Migration ist eine Übersetzung, keine Neuentwicklung. Sowohl ODM als auch DecisionRules bieten verschiedene Regeltypen. Jedes heute in ODM verwendete Artefakt besitzt ein Gegenstück in DecisionRules.
Bei den meisten Regeln erfolgt die Zuordnung direkt: Eine ODM Decision Table wird zu einer DecisionRules Decision Table, eine ODM Decision Tree wird zu einer DecisionRules Decision Tree.
In der folgenden Abbildung geht es nicht um die Anzahl der Regeltypen. Entscheidend ist, worauf jeder Regeltyp aufbaut, wo er erstellt wird, wie er ausgeführt wird und was für seinen Betrieb gewartet werden muss. Der obere Teil des Stacks wird übertragen, der untere entfällt.
Der obere Teil des Stacks wird direkt übertragen, während der untere vollständig entfällt.
Regelartefakte
Jeder Regeltyp in ODM basiert auf einem Business Object Model, das ein Java Execution Object Model umschließt. Jede Eigenschaft und Methode wird manuell in das Vokabular übertragen, das der Autor sieht. Jeder Regeltyp in DecisionRules basiert dagegen auf einem typisierten JSON-Schema, das in derselben UI wie die Regel definiert wird. Die fachliche Absicht bleibt in beiden Systemen gleich, DecisionRules benötigt dafür jedoch nur halb so viele Ebenen.
Das Orchestrierungsartefakt Ruleflow von ODM mit seiner .rfl-XML-Datei wird separat zu einem Decision Flow auf einer visuellen Arbeitsfläche.
Wo Sie arbeiten
ODM verteilt die Regelerstellung auf zwei Werkzeuge: Fachanwender öffnen Decision Center im Browser, Entwickler verwenden Rule Designer in Eclipse. DecisionRules führt beide Rollen in einer einzigen Browserumgebung zusammen, in der sie gemeinsam an denselben Artefakten arbeiten.
Fachanwender und Entwickler arbeiten an denselben Artefakten statt in zwei getrennten Werkzeugen.
Wie Regeln ausgeführt werden
Rule Execution Server läuft auf einer WebSphere-Instanz, die Ihr Team installiert hat und patcht. Eine DecisionRules-Regel wird unmittelbar nach ihrer Veröffentlichung als REST-Endpunkt unter einer Solver API-URL verfügbar. Die Vertragsstruktur, die Ihre Anwendung verwendet, bleibt unverändert. Lediglich Endpunkt und Protokoll ändern sich.
Was Sie warten müssen
Diese Zeile entfällt vollständig. Die WebSphere-Installation, die relationale Datenbank für das Regel-Repository, die Replikate für dev, SIT, UAT und production, die Clustering-Skripte und die Bereinigung des Vokabulars entfallen bei den von den meisten Teams gewählten Bereitstellungen als Managed Service vollständig. Das Wort „Nothing“ unten rechts in der Abbildung ist keine rhetorische Übertreibung. Es beschreibt den tatsächlichen operativen Aufwand, den Sie nach der Migration übernehmen.
Sie migrieren nicht allein
Von oben nach unten gelesen zeigt die Abbildung die gesamte Migrationsgeschichte auf einen Blick. Die Regellogik wird unverändert übertragen. In der oberen Hälfte erfolgt eine mechanische Übersetzung, in der unteren Hälfte werden Komponenten vollständig entfernt. Gerade diese Asymmetrie macht die Migration sinnvoll.
Sie führen die Migration nicht allein durch. Unser Team analysiert Ihre ODM-Landschaft, stimmt mit Ihnen einen Migrationsplan ab und unterstützt anschließend gemeinsam mit unserem AI Assistant, der die DecisionRules-Plattform vollständig kennt, bei der schnellen und konsistenten Implementierung der Regeln. Dadurch sinkt die Zahl manueller Übertragungsfehler, die sich bei einer umfangreichen Migration sonst ansammeln würden.
Wenn bereits eine Testsuite aus Decision Validation Services vorhanden ist, übertragen wir die Testfälle zusammen mit den Regeln und führen sie gegen die neuen DecisionRules-Versionen aus. So können Sie die Gleichwertigkeit vor der Umstellung prüfen. Wenn keine Testsuite vorhanden ist, erstellt der AI Assistant eine auf Grundlage der Regellogik. Dadurch entsteht ein Sicherheitsnetz für Regressionstests, das in ODM möglicherweise nicht vorhanden war.
Sie bringen die fachliche Absicht in die Migration ein. Wir übernehmen die Übertragung und Verifikation.
IBM, Operational Decision Manager, ODM, WebSphere, Decision Center, Decision Server, Rule Designer und Decision Validation Services sind Marken oder eingetragene Marken der International Business Machines Corporation in den Vereinigten Staaten und/oder anderen Ländern. Alle anderen genannten Produktnamen sind Eigentum ihrer jeweiligen Inhaber. Dieser Artikel wird von der IBM Corporation weder unterstützt noch steht er mit ihr in Verbindung.
