Business Rule Management-System

Fachverantwortliche wünschen sich mehr Flexibilität und Geschwindigkeit bei anstehenden Änderungen. Ein Business Rule Management System kann dabei helfen, Anpassungen der Geschäftslogik rasch und flexibel vorzunehmen.

(Zu) formaler Change-Prozess

In Fachanwendungen sind viele Geschäftsregeln, oder Business Rules auf Englisch, hinterlegt. So kann zum Beispiel festgelegt werden, dass das „Gültig ab …“-Datum eines Vertrags nicht mehr als drei Monate in der Vergangenheit liegen darf.

Diese Geschäftsregeln sowie deren Reihenfolge und Folgeaktionen, die sie auslösen, sind in klassischen Anwendungen fest einprogrammiert. Änderungen sind somit dem formalen Release-Zyklus der Software unterworfen. D.h. jede gewünschte Änderung durchläuft die Phasen Konzeption, Spezifikation, Realisierung, Qualitätssicherung, Dokumentation und Produktivsetzung. In grossen Unternehmen und Organisationen sind Release-Zyklen von drei bis sechs Monaten nach wie vor üblich. Dank dem formalen Change-Prozess bleiben die Servicequalität und die Nachvollziehbarkeit bei Anpassungen der Software gewährleistet.

Gleichzeitig hat dies aber den Nachteil, dass der Anwender bis zu sechs Monate auf eine fachlich erforderliche Änderung einer Geschäftsregel wartet. Die Dynamik der Märkte sowie interne und externe Compliance-Vorgaben erfordern hingegen immer kürzere Zyklen bei der Anpassung von Geschäftsregeln in Fachanwendungen.

Modellieren statt Programmieren

Fachverantwortliche wünschen sich deshalb vermehrt flexible Systeme. Sie möchten die Geschäftsregeln selber rasch und unkompliziert anpassen können – ohne Programmierkenntnisse und ohne den ganzen technischen Aufwand eines Software-Releases.

Genau dies ist der Zweck eines so genannten Business Rule Management Systems (BRMS). Ein BRMS besteht aus mindestens drei Komponenten: Business Rule Editor, Business Rule Repository und Business Rule Engine.

• Mit dem Business Rule Editor können Geschäftsregeln definiert werden.
• Das Business Rule Repository verwaltet alle definierten Regeln.
• Die Business Rule Engine letztlich führt die definierten Geschäftsregeln in der richtigen Reihenfolge aus.

Ein Business Rule Management System löst die fachliche Logik aus dem technischen Code und ermöglicht einem Fachanwender, die Logik in einer natürlichen Sprache zu erstellen. Die Logik wird in Wenn-Dann-Regeln, Entscheidungstabellen oder Entscheidungsbäumen abgelegt.

Ein BRMS erlaubt den Fachverantwortlichen somit, die Geschäftslogik und den Ablauf einer Anwendung ohne Programmierkenntnis zu modellieren. Die Phasen Analyse, Prototyping, Modellierung, Ausführung und Test gehen dabei fast nahtlos ineinander über. Der Fachverantwortliche kann sein Fachwissen einbringen und mit den Softwareentwicklern auf gleicher Augenhöhe arbeiten.

Viele Vorteile…

Die Hauptmotivation für den Einsatz von modellierten Geschäftsregeln wurde einleitend schon genannt: Änderungen der Geschäftslogik können schneller, flexibler und ohne Programmierkenntnisse vorgenommen werden.

Geschäftsregeln in einem BRMS sind einfacher schreibbar und leichter lesbar. Fachverantwortliche sehen auf einen Blick, welche Regeln aktuell für welchen Geschäftsvorfall gültig sind und durchlaufen werden. Dadurch ist auch der Unterhalt des Systems bei künftigen Änderungen einfacher, flexibler und kostengünstiger.

Test- und Simulationsmöglichkeiten im Vorfeld – auch während des laufenden Betriebs – garantieren eine schnelle und vor allem sichere Regeländerung. Dadurch wird das Risiko minimiert, dass Änderungen von Geschäftsregeln nicht den erwünschten Effekt haben.

Geschäftsregeln werden in einem zentralen Repository verwaltet und können firmenweit eingesetzt werden. Firmenweite Konsistenz und Befolgung der Compliance können damit sichergestellt werden.

Die Kontrolle über fachliche Änderungen liegt im Fachbereich. Die IT wird dadurch entlastet und die Time-to-Market verkürzt.

…und einige Nachteile

Ein BRMS bietet die Möglichkeit, Regeln zu verketten, sogenanntes “Chaining”. Dabei kann der ausführende Teil einer Regel die Bedingung der nächsten Regel beeinflussen. Dies kann dazu benutzt werden, sehr komplexe Geschäftsvorfälle abzubilden. Leider sind solche Verkettungen sehr schwer zu lesen und somit auch aufwändig im Unterhalt.

Die Verwendung einer Rule Engine kann so leicht zu einem “Spaghetti-Code” führen mit sich widersprechenden oder redundanten Regeln. Ähnlich wie bei Source-Code in Java oder .NET kann auch bei einer Rule Engine schnell der Vorwurf entstehen, dass nur noch derjenige die Regeln versteht, der sie selber geschrieben hat.

Weiter kann die Rule Engine in zweierlei Hinsicht zu einem Bottleneck der Unternehmung werden: Einerseits leidet die Performance, wenn viele Applikationen auf ein zentrales Repository von Regeln zugreifen. Andererseits gibt es Schwierigkeiten bei der Definition von Regeln, wenn unternehmensweit synchronisiert und abgestimmt werden muss, wer welche Regeln wie verändern darf.

Governance: Wer ist verantwortlich?

Die beschriebenen Nachteile lassen sich beseitigen oder zumindest entschärfen, indem eine klare Governance erstellt wird. Diese legt fest, nach welchen Vorgaben die Geschäftsregeln zu erstellen sind, und was nicht erwünscht oder gar nicht erlaubt ist. So lässt sich ein Wildwuchs im Regel Repository frühzeitig unterbinden.

Die Governance soll auch definieren, welche Regeln zentral verwaltet werden sollen und welche dezentral durch einzelne Abteilungen verwaltet werden. Auch hier mit dem Ziel, einen organisatorischen Wildwuchs zu unterbinden.

Fazit

Das Modellieren – statt Programmieren – von Geschäftsregeln mit einem Tool wie Consor Universal ist kein Allheilmittel. In einem Umfeld mit vielen Geschäftsregeln und vielen laufenden Änderungen lassen sich damit aber grosse Vorteile erzielen.

Der Fachbereich erhält mehr Flexibilität, Transparenz und Umsetzungsgeschwindigkeit und die IT wird von Change und Maintenance Aufgaben entlastet.