Eine Analyse von IBMs ILOG und Red Hats JBoss BRMS Business-Rule-Systeme von Red Hat und IBM im Vergleich

Um fundierte Entscheidungen zu treffen und tagesaktuell auf neue Anforderungen reagieren zu können, benötigen Unternehmen IT-gestützte Geschäftsregeln. Business-Rule-Management-Systeme (BRMS) unterstützen sie bei dieser Aufgabe. Entsprechende BRMS-Lösungen stehen beispielsweise von IBM und Red Hat zur Verfügung. Hier ein Vergleich beider Systeme von Partnern für Partner.

Anbieter zum Thema

PROFI Engineering Systems AG

WatchGuard Technologies GmbH

mibeca GmbH – Mike Bergmann Akademie

In Unternehmen aller Branchen werden im operativen Geschäft täglich Hunderte von Entscheidungen getroffen. Als Beispiel sei hier die Entscheidung über Kreditanfragen im Finanzsektor genannt. Die Regeln, die eine Entscheidung bestimmen, sind dabei meist im Quelltext vieler IT-Systeme verteilt, so dass auf Änderungen nur langsam und nach einer langen Analyse-Phase reagiert werden kann. Business-Rule-Management-Systeme (BRMS) wurden dafür geschaffen, Geschäftsregeln von der technischen Anwendung zu trennen.

Ein BRMS bietet die Möglichkeit, Regeln erstellen, ändern, testen und veröffentlichen zu können, um sogar tagesaktuell auf Änderungen reagieren zu können und somit zum Unternehmenserfolg maßgeblich beizutragen. Als IBM- und Red Hat-Partner steht die Viada GmbH & Co. KG aus Dortmund immer wieder vor der Wahl zwischen zwei hochwertigen Systemen, IBMs ILOG BRMS und Red Hats JBoss BRMS.

IBM ILOG

Neuen Nutzern wird der Einstieg in IBMs System einfach gemacht. Die mitgelieferte Eclipse-Version (Rule Studio) zeigt bei Rule-Projekten eine Project Map an, die als gute Orientierung der zu erledigenden Aufgaben innerhalb eines solchen Projekts dient.

Erster Schritt: XOM-Import

Man startet mit dem Import seines Execution-Object-Modells (XOM, Java-Klassen oder XML-Dateien). Das XOM stellt die Daten dar, die dem Regelsystem zur Verfügung gestellt werden, um Entscheidungen zu treffen. Das XOM wird in ein Business-Object-Modell (BOM) übersetzt welches dazu dient, ein Vokabular bereitzustellen, um Regeln in natürlicher Sprache definieren zu können (zum Beispiel „Wenn ein Antragsteller unter 18 Jahre alt ist, lehne den Antrag ab“). Im letzten Design-Schritt wird bestimmt, welche konkreten Eingangsdaten erwartet werden, um eine Entscheidung zu treffen, und welche Ausgangsdaten das Regelsystem danach liefert.

Zweiter Schritt: Gliederung der Regeln

Danach teilt man seine Regeln in Pakete ein. Ein Paket enthält immer einen Satz Regeln, der gleichzeitig angewendet wird. Als Beispiel sei hier ein Regelsystem für Versicherungseinstufungen angeführt: Im ersten Schritt überprüft man die Eingangsdaten auf Validität, im zweiten Schritt stuft man den zu Versichernden in einen Tarif ein, woraufhin man im letzten Schritt noch mögliche Risikozuschläge oder Rabatte berechnen kann. Die Einteilung der Pakete in einen vorgegebenen Ablauf übernimmt der „Ruleflow“, den man im Rule Studio komfortabel in Diagrammform designen kann.

Dritter Schritt: Abfassen der Regeln

Im Schritt „Author“ verfasst man die Regeln. Diese können einzeln geschrieben werden, zum Beispiel „Wenn der Versicherungsnehmer mehr als zwei Unfälle hatte, erhöhe den Beitrag um 30 Prozent“. Braucht man viele ähnliche Regeln, bieten sich Decision Tables an. Hier könnte man zum Beispiel obige Regel nehmen, aber die Anzahl der Unfälle, sowie die Erhöhung des Beitrages in neue Zeilen eintragen, um verschiedene Erhöhungsstufen zu realisieren. Decision Trees bieten sich an, wenn komplizierte Konstrukte verfasst werden sollen, in denen zum Beispiel mehrere verschachtelte Wenn-Dann-Fälle abgebildet werden müssen.

Vierter Schritt: Testen

Hat man seine Regeln verfasst, sollten diese getestet werden. Hierzu kann man die erwarteten Eingangsgrößen und die erwarteten Werte in einer Excel-Tabelle eintragen. Nun wird es etwas komplizierter: Um den Test durchzuführen, muss dieser auf einem Applicationserver gestartet werden. Rule Studio bietet zwar die Möglichkeit den Test zu packen. Insgesamt ist dieser Schritt jedoch sehr umständlich. Hat man den Test ausgeführt, erhält man eine Auswertung in HTML-Form.

Um sein komplettes Projekt nun ausführbar auf dem ILOG Rule Execution Server ablegen zu können, muss man ein Rule-App-Projekt erstellen und es „deployen“. Auch hier ist Rule Studio wieder behilflich. Ist die Applikation deployed, wird sie automatisch versioniert, sodass man in seiner IT-Landschaft Altprojekte nicht direkt migrieren muss, falls sich Regeln einmal stark ändern.

Auf der nächsten Seite erfahren Sie, wie sich dieselbe Aufgabenstellung mit Red Hats JBoss-Developer-Studio erfüllen lässt.

(ID:2042834)