Oswald Regular
OpenSans Regular
Business Rules Environment

Ab Initio-Software wird von den unterschiedlichsten Benutzern eingesetzt. An einem Ende des Spektrums stehen professionelle Anwendungsentwickler. Diese Experten können hoch entwickelte Systeme entwerfen und erstellen, die große Datenmengen in komplexen Umgebungen verarbeiten. Für sie bietet Ab Initio das Graphical Development Environment (grafische Entwicklungsumgebung, GDE) zum grafischen Erstellen komplexer Prozesse und Geschäftslogik an. Die resultierenden Anwendungen werden auf dem extrem robusten und skalierbaren Co>Operating System ausgeführt.

Am anderen Ende des Spektrums der Ab Initio-Benutzer stehen Geschäftsanwender. Sie sind technisch weniger interessiert und wissen beispielsweise nicht, mit welchen Mechanismen Terabytes von Daten oder tausende von Messages pro Sekunde verarbeitet werden. Aber sie wissen genau, welche Anforderungen ihre Systeme erfüllen sollen, und sie kennen sich oft am besten mit den geschäftsrelevanten Daten und Regeln aus.

Im Laufe der Jahre kam es zu einer – manchmal unfreundlichen – Trennung zwischen den Geschäftsanwendern und den für sie tätigen IT-Teams. Die Geschäftsanwender wissen, welche Aufgaben bewältigt werden müssen und welche Bedeutung diese Aufgaben für das Unternehmen haben. Die IT-Experten wiederum wissen, wie diese Anforderungen erfüllt werden können. Die IT-Abteilung fordert genaue Spezifikationen und die Geschäftsanwender bemühen sich, sie bereitzustellen. Aber Unklarheiten und Fehler sind unvermeidlich – Fehler in den Spezifikationen sowie Fehler bei der Umsetzung der Spezifikationen in Code. Der erforderliche Prozess – von der Spezifikation über die Codierungs- und Testphase bis zur Freigabe – läuft nie so schnell und reibungslos ab wie erhofft. Auf jeder Stufe muss eine Person herausfinden, was eine andere Person gemeint hat. Dies kostet viel Zeit und birgt ein großes Fehlerpotenzial. Und zusätzliche Zeit muss aufgewendet werden, um Fehler zu finden, die Spezifikationen zu überarbeiten und den Code anzupassen. Die Produktivität wird beeinträchtigt und man kann sich nie sicher sein, dass alle Fehler erkannt und behoben wurden. In manchen Fällen kann der Prozess nicht abgeschlossen werden, und Projekte scheitern.

Wie wäre es, wenn Geschäftsanwender selbst in der Lage wären, die Teile des Systems zu steuern, mit denen ihre Geschäftslogik implementiert wird? Wie wäre es, wenn ihre Geschäftsregeln in einer Weise ausgedrückt würden, die sie verstehen, sodass sie sie sogar selbst schreiben können? Und wie wäre es, wenn die Geschäftsregeln automatisch in Code konvertiert würden, der auf einem größeren System ausgeführt werden kann? Das klingt nicht schlecht, oder? Genau das ist der Grundgedanke des Business Rules Environment (Geschäftsregelumgebung, BRE).

Mit der BRE von Ab Initio können Analysten Geschäftsregeln auf eine Weise festlegen, die ihnen sehr vertraut ist, nämlich in rasterähnlichen Kalkulationstabellen. In der BRE werden Regeln nicht mit technischen, sondern mit geschäftlichen Begriffen festgelegt. Die verwendeten Ausdrücke versteht jeder Benutzer, der sich mit MICROSOFT EXCEL auskennt. Daher können Regeln nicht nur schnell und genau festgelegt werden, sondern sie sind auch für andere Geschäftsanwender problemlos verständlich.

Darüber hinaus gibt die BRE den Geschäftsanwendern die Möglichkeit, die Geschäftsregeln eigenständig zu prüfen. Die Geschäftsanwender können die Regeln direkt in das System einfügen, um sie auf Testdaten anzuwenden und sofort die Ergebnisse anzuzeigen. Wenn sie mit den Ergebnissen nicht zufrieden sind, können sie die Regeln direkt ändern. Das spart enorm viel Zeit.

Die BRE von Ab Initio ist kein eigenständiges Werkzeug

Herkömmliche „Regel-Engine“-Produkte sind eigenständige Werkzeuge. Für diese Produkte müssen Schnittstellen zu anderen Produkten und zur übrigen Recheninfrastruktur eingerichtet werden. Ihre Leistung und Skalierbarkeit sind begrenzt. Sie können nur einfache Datenstrukturen verarbeiten. Da ihre Perspektive auf die von ihnen verarbeiteten Regeln beschränkt ist, können sie nicht systemübergreifend zur Lineage-Verfolgung eingesetzt werden.

Mit der BRE von Ab Initio werden diese und viele andere Probleme und Einschränkungen beseitigt, denn sie ist eng mit dem Co>Operating System und den Metadatentechnologien von Ab Initio verbunden. Die BRE wurde von Anfang an so entworfen und implementiert; sie wurde also nicht erst nachträglich bzw. als Ergebnis einer Marketingstrategie entwickelt, wie es bei typischen Softwarefirmen sonst oft der Fall ist.

  • Dieselben BRE-Regeln können ohne erneute Implementierung in Batch-, Web-Service-, Echtzeit- und kontinuierlichen Anwendungen ausgeführt werden.
  • BRE-Regeln laufen sehr effizient und können für die Ausführung auf mehreren CPUs und Servern skaliert werden. Die Skalierbarkeit der mit Ab Initio-Software erstellten Systeme ist unbegrenzt.
  • BRE-Regeln können komplexe hierarchische Legacy-Daten verarbeiten. In Verbindung mit dem Co>Operating System kann die BRE nativ alles verarbeiten, was in Legacy-Umgebungen vorhanden ist (EBCDIC, gepackte Dezimalzahlen, internationale Formate, XML, COBOL-Copybooks …).
  • Dieselben BRE-Regeln werden auf allen vom Co>Operating System unterstützten Plattformen auf dieselbe Art ausgeführt (UNIX, LINUX, WINDOWS, Z/OS und Z/LINUX).
  • Die BRE profitiert von allen Robustheitsmerkmalen des Co>Operating Systems, wie beispielsweise Fehlerbehandlung, Checkpointverfahren usw.

Was sind „Geschäftsregeln“?

Die BRE unterstützt drei Arten von Geschäftsregeln: Entscheidungsregeln, Validierungsregeln und Zuweisungsregeln. Obwohl diese Regeln sehr ähnlich sind, werden sie von Geschäftsanwendern gern in die genannten Kategorien unterteilt.

Je nach Art des Geschäfts können Regeln sehr kurz und einfach oder äußerst lang und komplex sein. Die BRE eignet sich für beide Extreme. Die derzeit größten in einer Produktionsumgebung eingesetzten BRE-Regelsätze umfassen mehr als 50.000 Regeln.

Im folgenden Beispiel wird eine sehr einfache in der BRE erstellte Entscheidungsregel gezeigt, nämlich die Steuerberechnung der US-Einkommenssteuer entsprechend US-Formular 1040:

Diese Regel hat zwei Eingabeparameter – den Veranlagungsstatus (Filing status) und das zu versteuernde Einkommen (Taxable income) aus Formularzeile 43 – und berechnet daraus als einzigen Ausgabewert die Steuer (Tax) auf Formularzeile 44. In der BRE gibt es einen impliziten AND-(UND)-Operator zwischen Spalten und einen impliziten ELSE-(SONST)-Operator zwischen Zeilen. Die ersten Zeilen dieser Regel bedeuten also Folgendes:

WENN der Veranlagungsstatus den Wert Single (ledig) hat UND das zu versteuernde Einkommen aus Formularzeile 43 kleiner oder gleich 100000 ist, DANN wird die Steuer auf Formularzeile 44 berechnet, indem das zu versteuernde Einkommen aus Formularzeile 43 per Lookup aus der Steuertabelle abgerufen und der Betrag für ledige Personen zurückgegeben wird.

SONST: WENN der Filing status (Veranlagungsstatus) den Wert Single (ledig) hat UND das Taxable income (zu versteuernde Einkommen) aus Formularzeile 43 größer als 100000 und kleiner oder gleich 171550 ist, DANN wird die Tax (Steuer) auf Formularzeile 44 berechnet, indem das Taxable income (zu versteuernde Einkommen) aus Formularzeile 43 mit 0,28 multipliziert und 6280,00 vom Ergebnis subtrahiert wird.

SONST: WENN der Veranlagungsstatus den Wert Single (ledig) hat UND das zu versteuernde Einkommen Taxable income line 43 aus Formularzeile 43 größer als 171550 ist  …

… und so weiter …

Im nächsten Beispiel wird eine Validierungsregel gezeigt, mit der mehrere Eingaben validiert und mehrere Ausgaben für jeden Fall festgelegt werden:

Hier sehen Sie ein Beispiel für eine Quelle-zu-Ziel-Zuweisungsregel. Für Regeln dieser Art zeigt die BRE auf der linken Seite eine Liste der potenziellen Eingabewerte (Spalte „Inputs“ [Eingaben]) wie z. B. Felder, Variablen, Konstanten und berechnete Werte. In der Mitte ist eine Liste der Zielfelder (Spalte „Output Name“ [Ausgabename]). Rechts davon ist die Spalte „Expression/Rule“ (Ausdruck/Regel). Benutzer können Werte aus der Spalte „Inputs“ in diese Spalte ziehen oder sie können hier einen Ausdruck zum Berechnen der Ausgabe erstellen. (Auf die Spalte „Computed Value“ [Berechneter Wert] gehen wir später ein.)

BRE-Regeln können beliebig komplexe Logik enthalten

Die Logik in BRE-Regeln kann einfach sein, wie in den obigen Beispielen gezeigt. Aber in der Praxis arbeiten Geschäftsanwender häufig mit sehr komplexen Regeln. Bei Technologien anderer Anbieter können diese Regeln nicht im Geschäftsregelprodukt implementiert werden, sondern müssen manuell in Programmiersprachen wie C++ oder JAVA codiert werden, was die Benutzerfreundlichkeit und Produktivität stark beeinträchtigen kann. Zudem wird damit der Zyklus Spezifizieren-Interpretieren-Codieren-Testen-Korrigieren wieder eingeführt, der viele Projekte zum Scheitern verurteilt.

Nicht so bei der BRE von Ab Initio. Die BRE verfügt über die gesamte Datenverarbeitungsfähigkeit des Co>Operating Systems und somit über alle seine Funktionen – und es gibt hunderte davon – ebenso wie komplexe logische Strukturen.

Folglich gibt es keine Begrenzung für die Größe oder Komplexität der Ausdrücke in Regeln, die Größe oder Komplexität der Regeln selbst oder die Anzahl der Regeln in einem Regelsatz.

Integrierte Testfunktion ermöglicht Geschäftsanwendern das eigenständige Verifizieren von Regeln

Ein entscheidender Vorteil der BRE von Ab Initio ist ihre integrierte Testfunktion, mit der in der BRE entwickelte Regeln mit Beispieldaten ausgeführt werden können, ohne die Bearbeitungsumgebung zu verlassen. Beim Testen meldet die BRE die für jeden Testdatensatz berechneten Ausgaben sowie den Status aller Zwischenvariablen und -berechnungen. BRE-Benutzer können die Ausgabedatensätze durchsehen und auf jeden berechneten Wert klicken, um genau anzuzeigen, wie und warum der Wert berechnet wurde:

Die BRE zeigt für jeden Testdatensatz die ausgelösten Fälle (gelb) und dunkelt alle Zellen ab, die zu einem fehlgeschlagenen Vergleich führten. Darüber hinaus berechnet die BRE, wie oft jede Regel ausgelöst wird („Times Fired“ [Auslösezahl] im Screenshot). Anhand dieser Informationen können fehlende Testfälle und ungültig konstruierte Regeln ermittelt werden (wenn ein Fall nie ausgelöst wird).

Tests können zu jeder Zeit während der Entwicklung von Regeln durchgeführt werden, sodass nach und nach ein großer Regelsatz erstellt werden kann. Daher kann schon frühzeitig mit der Verhaltensauswertung begonnen werden und nicht erst, nachdem alle Regeln eingegeben wurden.

Die Ausgabe eines Testlaufs kann als Benchmark gespeichert werden, mit der spätere Testläufe automatisch verglichen werden. Wenn Regeln in der Entwicklungsphase oder beim Entwerfen von Modifikationen geändert werden, können alle Unterschiede zwischen dem aktuellen Verhalten der geänderten Regeln und den gespeicherten Benchmarkergebnissen angezeigt werden. Diese Funktion ist äußerst hilfreich, wenn die Auswirkungen einer vorgeschlagenen Änderung bewertet werden sollen. Ohne die BRE von Ab Initio befinden sich Geschäftsanwender beim Ändern von Regeln oft im „Blindflug“.

Darüber hinaus sind auch Ausführungsdetails zu Regelsätzen verfügbar, die in einer Produktionsumgebung ausgeführt werden. Benutzer können konfigurieren, wie viele Tracking-Informationen gespeichert werden sollen. Der Spielraum reicht hierbei von bloßen Angaben darüber, welche Regelfälle (Zeilen) für jeden Eingabedatensatz ausgelöst werden, bis hin zu sämtlichen Eingabe-, Lookup-, Zwischen- und Endwerten. Analysten haben somit die Möglichkeit, das Verhalten der Regeln im Lauf der Zeit zu untersuchen, was oft zur Verbesserung der Ergebnisse durch Anpassen der Geschäftslogik führen kann. Diese Details können auch von kritischer Bedeutung sein, wenn es um die Beantwortung der Frage geht, wie bestimmte Entscheidungen in der Vergangenheit getroffen wurden.

Transparente Geschäftslogik

Große, komplexe Geschäftsregelsysteme können aus vielen Regeln bestehen, deren Implementierung auf anderen Regeln aufsetzt. Für Geschäftsanwender ist es äußerst wichtig zu verstehen, welche Beziehungen zwischen diesen Regeln bestehen und wie die Daten zwischen ihnen fließen. Leider können die meisten Geschäftsanwender nur selten sehen, wie ihre Systeme funktionieren.

Mit der BRE haben Geschäftsanwender vollen Einblick in ihre Systeme, da die BRE in Diagrammen anzeigt, wie Daten durch miteinander verbundene Regeln fließen, und zwar unabhängig von der Größe und Komplexität dieser Regeln. Darüber hinaus kann die grafische Lineage für Anwendungen angezeigt werden, die aus vielen über die gesamte Anwendung oder sogar über mehrere Anwendungen verteilten Regelsätzen bestehen.

In der folgenden Abbildung wird ein einfaches Lineage-Beispiel für den oben beschriebenen Regelsatz gezeigt, mit dem die Einkommenssteuer entsprechend US-Formular 1040 EZ berechnet wird. Grüne Ovale stehen für Regeln (Berechnungen) und abgerundete Rechtecke für Variablen. Im Testmodus werden unter jedem Variablennamen Beispiele für Testwerte mit allen Zwischenberechnungen angezeigt. Unter dem vollständigen Lineage-Diagramm befindet sich ein vergrößerter Abschnitt, in dem gezeigt wird, wie sich die Berechnung des abzugsfähigen Betrages (deductible) auf die Steuerschuld (amount owed) bzw. die Erstattung (final refund) auswirkt.

Dank der Lineage-Fähigkeit der BRE können Geschäftsanwender wirklich verstehen, wie große Sätze komplexer Regeln funktionieren.

Kein „RETE-Algorithmus“

Was ist RETE? Nur keine Sorge – wenn Sie mit der BRE arbeiten, müssen Sie das nicht wissen. Bei herkömmlichen Regelprodukten hingegen bestimmt der RETE-Algorithmus, in welcher Reihenfolge Regeln ausgeführt werden. Daher müssen Geschäftsanwender, die mit solchen Produkten arbeiten, einen ziemlich komplexen Begriff aus dem Bereich der Informatik bzw. der künstlichen Intelligenz verstehen. (Informationen zum RETE-Algorithmus finden Sie unter http://de.wikipedia.org/wiki/Rete-Algorithmus.)

In der Praxis macht der RETE-Ansatz es sehr schwierig, die Konsequenzen von Änderungen an einer Regel zu verstehen, da Änderungen Auswirkungen auf andere Regeln haben können, die sich in den Spezifikationen an ganz anderer Stelle befinden. Die Leistungsoptimierung wird ebenfalls erschwert, da kleine Änderungen große und unerwünschte Konsequenzen haben können.

In der BRE werden Regeln in der Reihenfolge ausgeführt, in der sie festgelegt wurden. Die Leistung ist nicht nur wesentlich höher, sondern auch vorhersagbar! Und man muss kein Informatikstudium absolviert haben, um zu verstehen, wie die Regeln funktionieren.

Wie arbeitet die BRE mit dem Co>Operating System zusammen?

Die BRE platziert die vom Benutzer erstellten Regeln in einer Komponente in einem Graphen, der vom Co>Operating System ausgeführt wird. Klicken Sie hier, um mehr über Komponenten, Graphen und das Co>Operating System zu erfahren.

Da Geschäftsregeln im Co>Operating System ausgeführt werden, bieten sie alle Vorteile und Stärken des Co>Operating Systems. Regeln sind äußerst robust und können an jede Datenquelle und jedes Datenziel ankoppeln, Daten jeder Art verarbeiten, jegliches Datenvolumen bewältigen, im Batchmodus und/oder in Echtzeit laufen und verteilt über mehrere Server mit verschiedenen Betriebssystemen ausgeführt werden. Das Co>Operating System umfasst alles, was zum Erstellen und Ausführen robuster geschäftskritischer Anwendungen benötigt wird, und stellt es für die BRE bereit.

Im folgenden Beispiel wird ein Graph (eine Anwendung) des Co>Operating Systems gezeigt, in dem eine wichtige Komponente Regeln enthält, die mit der BRE spezifiziert wurden:

Vollständige Regelverwaltung und Governance

Alle Regeln werden im Enterprise Meta>Environment (EME) von Ab Initio gespeichert. Da die EME alle zur Quellcodeverwaltung erforderlichen Funktionen bietet (einschließlich Versionierung), können Benutzer der BRE zwischen zwei Deployment-Methoden wählen:

  • Regeln wie andere Anwendungselemente behandeln. Dies bedeutet, dass sie alle standardmäßigen Codeauslieferungsphasen durchlaufen müssen: Entwicklung, Test und schließlich Freigabe in die Produktionsumgebung. Diese robuste Methodik ist IT-Entwicklern sehr vertraut, aber die zahlreichen Schritte können ziemlich viel Zeit beanspruchen. Dennoch optimiert und verkürzt die integrierte Testfunktion der BRE den Gesamtprozess.
  • Regeln eher wie Referenzcodedaten in einer Betriebsdatenbank behandeln. Geschäftsanwender können Änderungen an Referenzcodes (Hinzufügungen, Aktualisierungen und Löschungen) häufig vornehmen, ohne dass sie den gesamten Prozess der Anwendungscodeauslieferung durchlaufen müssen. So können sie schnell auf sich ändernde Geschäftsanforderungen reagieren.

Ab Initio gibt keinem dieser Ansätze den Vorzug; wir geben unseren Kunden einfach die Möglichkeit, den Ansatz zu wählen, der ihren Anforderungen am besten entspricht.

Da die EME eine sehr gute Versionierungsunterstützung bietet, können Benutzer ihre Umgebung mühelos so konfigurieren, dass Regeln nach dem „Champion/Challenger“(Sieger/Herausforderer)-Prinzip bereitgestellt werden. Der Grundgedanke hierbei ist, zwei Versionen der gleichen Regeln parallel auszuführen und ihre Ausgaben miteinander zu vergleichen. Anschließend legen Benutzer Verfahren fest, mit denen die ermittelten Unterschiede geprüft und die Regeln optimiert werden, um die gewünschten Ergebnisse zu erzielen.

Einheitliche Technologie zur Vereinigung des Unternehmens

Die BRE bietet Funktionen zum integrierten, interaktiven Testen und automatischen Generieren produktionsfähiger ausführbarer Module, die es Geschäftsanwendern ermöglichen, sich direkt an der Anwendungsentwicklung zu beteiligen und das Know-how der IT-Mitarbeiter sinnvoll zu ergänzen. Da die Geschäftslogik in der BRE auf eine Weise präsentiert wird, die Geschäftsanwender verstehen und anwenden können, werden viele Risiken und viel Unsicherheit eliminiert, die üblicherweise mit der Entwicklung und Bereitstellung neuer Anwendungen verbunden sind.

Die BRE-Regeln und die von ihnen gesteuerten Anwendungen werden vom Co>Operating System ausgeführt. Sie können daher von beliebiger Komplexität sein und werden dennoch extrem effizient und mit uneingeschränkter Skalierbarkeit ausgeführt. Zudem können dieselben Regeln ohne erneute Codierung in Batchanwendungen und Web-Service-Anwendungen ausgeführt werden. Da die BRE mit der gleichen einheitlichen Technologie erstellt wurde wie das Co>Operating System, kann jeder Vorteil des Co>Operating Systems auch in der BRE genutzt werden. Die BRE und das Co>Operating System arbeiten nahtlos zusammen, um das Unternehmen zu vereinen.

English
Français
Español
Sprache:
Deutsch
简体中文
日本語