Interview: Die Business Rules-Perspektive

Zusammenfassung

Dieses ist der dritte Artikel in unserem Themenschwerpunkt „Qualitätssicherung und Testen in BPM-Projekten“. Neben der allgemeinen Diskussion zum Thema (siehe Interview M. Scholze) haben wir bereits eine Einordnung des Themas QS in das Framework der Integrierten BPM Projektmethodik (IBPM) vorgenommen (siehe QS-Checkliste). Diese Einordnung des Themas QS in die 10 Säulen des IBPM-Frameworks liefert eine praktische Checkliste für QS-Verantwortliche in BPM-Projekten.

Aufgrund der hohen Relevanz und Komplexität haben wir uns entschlossen, einer der 10 Säulen im BPM-Framework an dieser Stelle einen eigenen Artikel zu gönnen. Dieser soll im Kontext BPM und QS noch einmal speziell das Thema Business Rules vertiefen. Wir konnten hierzu Herrn Roland Straub, Senior Solution Manager für BRM bei der Bosch Software Innovations GmbH, als Interviewpartner gewinnen.

Hintergrund

Im Buch „Enterprise BPM“ haben wir im Kapitel „Business Rules“ das Zusammenspiel von BPM und BRM (Business Rules Management) bereits ausführlich beleuchtet. Wichtig war uns hier insbesondere das Thema „Trennung von Prozessfluss und Entscheidungslogik“, da diese eine wichtige Voraussetzung zur Erreichung von Zielen wie Erhöhung der Agilität, Einbindung der Fachbereiche, Automatisierung von Entscheidungen, Verbesserung der Wartbarkeit und Wiederverwendung ist.

Auf die Vor- und Nachteile einer dichten Integration zw. BPM und BRM sind wir insbesondere in dem Interview mit Daniel Steiner von Pegasystems eingegangen (Pegasystems ist ein Vertreter der dichten Integration von BPM und BRM in einer Engine). Als Verfechter von BPM und SOA gehen wir an dieser Stelle eher von einer losen Kopplung zw. BPM und BRM aus, wie sie in Abb. 1 aus dem Buch noch einmal zusammengefasst ist.

Abb. 1: Einordnung des BRMS in die SOA

Eine Prozesskomponente kann danach einen Service im BRMS aufrufen (z.B. als Webservice), um eine Regel auszuwerten. Der Regelservice im BRMS agiert ggf. als Orchestrierungsservice, der wiederum Services aufruft, z.B. um auf weitere Regeldefinitionen oder auf Datenservices zuzugreifen (diese Datenservices können natürlich auch außerhalb des BRMS liegen).

Wie wir bereits in der „QS-Checkliste“ dargestellt haben, bietet es sich in einer SOA an, das Testen einzelner Komponenten durch den Einsatz von Service-Simulatoren und Mock-Ups zu unterstützen. Welche weitergehenden Möglichkeiten zur Unterstützung der Qualitätssicherung in einer SOA ein BRMS anbieten kann, diskutieren wir im folgenden Interview.

 

Interview

R. Nelius: Welche Auswirkungen hat die Einführung von BRM in einem BPM-Projekt auf die Gesamt-Teststrategie? Kann die Rules Engine als Ausführungseinheit der Geschäftslogik aus Perspektive des zu testenden Prozesses als Black-Box betrachtet werden?

R. Straub: Die Auswirkungen können sehr vielschichtig sein und sich u.a. auf technischer, organisatorischer und auf der Qualitätsebene erstrecken. Werden die von der Rules Engine im Rahmen des Tests zu verarbeitenden Daten vom Prozess geliefert (auch als End-2-End Testansatz zu verstehen), kann die Rules Engine aus Perspektive des Prozesses tatsächlich als Black-Box verstanden werden. Hierbei arbeitet sie klassischerweise zustandslos: Von der Process Engine angelieferte Eingabedaten werden von der Rules Engine verarbeitet und die Regelergebnisse wieder an die Process Engine zurückgeliefert. Somit lassen sich die Regeln mit den aus dem Prozess zur Verfügung gestellten Daten einfach mittesten.

Einige Aspekte sind hierbei zu beachten:

  • Prozess- und Regelversionen sind zu synchronisieren und unterliegen oftmals unterschiedlichen Lebenszyklen und unterschiedlicher Änderungshäufigkeit. Die Verwaltung und Einbindung der richtigen Regelversion muss sichergestellt sein.
  • Nicht immer möchte man jedoch alle Bewegungsdaten im Prozess halten, nur um sie an die Rules Engine zur Verarbeitung weiterzugeben. Es kann Sinn machen, dass die Rules Engine anhand der vom Prozess übergebenen Schlüsseldaten selbst weitere Daten etwa aus Datenbanken oder von Umsystemen bezieht. Dies erfolgt u.a. aus Performanzerwägungen, hat aber den Nachteil, dass sich Schnittstellen zu den Umsystemen dann auch in den Regeln befinden. Die Rules Engine arbeitet dann nicht mehr zustandsfrei, sondern zustandsbehaftet. Dies ist im Ablauf des Tests zu berücksichtigen.
  • BRMS bieten darüber hinaus eine umfangreiche Testunterstützung zum Whitebox-Testen. Das BRMS kann zudem als Simulator bzw. Mock-Up Implementierung der Geschäftslogik dienen, die sie als Service bereitstellt.

D. Slama: Erhöht die Kombination von BPMS und BRMS nicht exponentiell die Test-Komplexität?

R. Straub: Ziel der BRMS-Integration sollte ganz klar sein, die Testkomplexität zu reduzieren. Dies wird alleine schon dadurch erreicht, dass die Prozessdarstellung übersichtlicher wird, wenn die Details der Geschäftslogik aus dem Prozess herausgelöst und unter die Hoheit eines BRMS gestellt werden.

Die Geschäftslogik kann durch die vom BRMS gelieferten Möglichkeiten zum Whitebox-Testen erst einmal unabhängig vom Prozess qualitätsgesichert werden.

Erst im Rahmen eines End-2-End Tests wird die Rules Engine dann aus der Process Engine aufgerufen und das Zusammenspiel getestet. Die kombinatorische Anzahl an Testfällen auf Prozessebene reduziert sich analog dazu.

D. Slama: Was ist, wenn nicht nur das BPMS das BRMS aufruft, sondern das BRMS wiederum über externe Service-Aufrufe den Prozess beeinflusst?

R. Straub: Dies sollte man nach Möglichkeit vermeiden, da es die Gesamtarchitektur des Systems betrifft und damit die Wartbarkeit der Schnittstellen, sowie die Orchestrierbarkeit, Skalierbarkeit und Performanz des Systems.

Als sauberes Architekturkonzept bietet es sich an, die Regeln als Regelservices auf der Prozessebene genauso wie alle anderen Services zu orchestrieren. Die Koordination des Gesamtablaufes erfolgt somit auf oberster Prozessebene und nicht verborgen innerhalb der Geschäftslogik. Dies erhöht deutlich die Transparenz des Gesamtsystems.

Es gibt jedoch Ausnahmen, wenn, wie bereits erwähnt, nicht alle Bewegungsdaten im Prozess gehalten werden sollen, sondern die Regeln sich selbst Daten besorgen. Insbesondere, wenn der Datenzugriff komplexen Regeln unterliegt und wenn er aus Kostengründen (etwa auf externe Auskunfteien) minimiert werden soll, bietet sich ein regelbasierter Datenzugriff an. Hierbei sollte man jedoch nach Möglichkeit nur lesende Zugriffe vornehmen und schreibende Zugriffe nur durch dedizierte Services auf Prozessebene erfolgen lassen. Dies reduziert die notwendige Einflussnahme auf den Prozess erheblich.

R. Nelius: Wie sieht eine Test-Strategie spezifisch für den BRM-Teil aus? Was muss beachtet werden? Gibt es spezifische Strategien für das Whitebox-Testen von Regeln?

R. Straub: Da BRMS darauf ausgelegt sind, auch mit einer großen Anzahl komplexer Regeln umzugehen, bieten sie umfangreiche Funktionalität für die Testunterstützung. Generell wird das Unit Testing unterstützt, wobei die Testfälle (bestehend aus Eingabedaten und erwarteten Referenzergebnissen) den Regeln zugeordnet werden und beim Testen aufgetretene Abweichungen zwischen Ist und Soll kenntlich gemacht werden:

Abb. 2: Unit Testing im BRMS am Beispiel Visual Rules

Zur genaueren Analyse der Testausführung innerhalb des BRMS dient eine schrittweise Regelausführung, die bisweilen auch ein grafisches Debugging mit Anzeige der pro Regelschritt veränderten Datengrundlage ermöglicht (Abb. 3).

Abb. 3: Grafisches Debuggen im BRMS am Beispiel Visual Rules

Des Weiteren ermitteln BRMS auch Metriken (etwa die Testabdeckung) oder ermöglichen eine komplette Testautomatisierung mit Bezug externer Daten und Reporting der Testergebnisse. Während des Testens aufgezeichnete Ausführungsstatistiken erlauben ein nachgelagertes Monitoring der Regelausführung sowie ein Profiling, bei dem die Ausführungszeiten einzelner Regelpfade ausgewertet werden können. Damit lassen sich die ausgeführten Regelpfade verdeutlichen und nachvollziehen (Abb. 4).

Abb. 4: Monitoring der Regelausführung am Beispiel Visual Rules

Zuletzt bieten BRMS auch formale semantische Überprüfungen von Regelausdrücken an, wie etwa die Erkennung doppelter oder überlappender Regelausdrücke sowie lückenhafter Bereichsabdeckungen in Entscheidungstabellen.

D. Slama: Kann Regelsimulation bei der Erreichung eines hohen Testabdeckungsgrads helfen? Kann man überhaupt eine hundertprozentige Abdeckung aller Kombinationsmöglichkeiten erreichen? Ist das erstrebenswert?

R. Straub: Unter Regelsimulation ist die automatische Verarbeitung großer Datenbestände zu verstehen; oftmals wird hier mit einem Abzug der produktiven Datenbestände gearbeitet. Dadurch kann man sehen, wie sich das Regelwerk insgesamt verhält, wenn alle praktisch auftretenden Datenkombinationen durchlaufen werden. Hierbei kann ein BRMS auch die Testabdeckung messen und reporten.

Solche Simulationsläufe überprüfen jedoch nicht automatisch die Richtigkeit der Regelergebnisse. Hierzu müsste eine Sammlung erwarteter Referenzergebnisse existieren, die man jedoch oft nur manuell fallbasiert bereitstellen kann.

Nicht immer lässt sich eine hundertprozentige Abdeckung aller Kombinationsmöglichkeiten erreichen. Die effizienteste Vorgehensweise ist, bestimmte Regeln gezielt feingranular zu testen. Werden die Regeln, die von übergeordneter Ebene aufgerufen werden, schon einmal für sich feingranular mit hoher bis voller Testabdeckung getestet, dann reichen für die übergeordneten Regeln oftmals wenige Testfälle, um den Gesamtregelablauf zu testen:

Abb. 5: Test des Gesamtregelablaufs am Beispiel Visual Rules

Darüber hinaus werden oft Testabdeckungsgrade definiert, die über alle Regeln hinweg mindestens zu erreichen sind. Diese betragen meist weniger als 100%.

R. Nelius: Welche Tools sollte ein BRMS für ein effizientes Testmanagement mitbringen? Wie sieht das Zusammenspiel  eines BRMS mit Standard-Testtools aus (z.B. QualityCenter)?

R. Straub: BRMS sollten nicht nur die Möglichkeit bieten, Testfälle zu definieren, sondern auch über ein Regelspezifisches Testfallmanagement verfügen. Ein solches ermöglicht es, Testfälle als Tests zusammenzufassen und zu verwalten, wie etwa in hierarchische Test Suites, die weitere Test Suites und Tests einbinden können. Entlang dieser hierarchischen Organisation können die Tests auf beliebiger Hierarchiestufe in ein Testmanagement-Tool eingebunden und somit auch außerhalb des BRMS ausgeführt werden. Dies ist eine wichtige Funktion, möchte man z.B. vor der Bereitstellung und dem Deployment neuer Regelversionen im Rahmen eines automatisierten Gesamttests die Konsistenz der Regelbasis sicherstellen.

Abb. 6: Testfallmanagement am Beispiel Visual Rules

R. Nelius: Was muss ein effizienter Rule-Governance-Prozess beachten?

R. Straub: Der Rule-Governance-Prozess muss den vollen Lebenszyklus der Geschäftslogik berücksichtigen. Hierzu gehören: Regelanforderungsdefinition, Regeldokumentation, Regelmodellierung, Testen, Testdokumentation, Regelverwaltung/Versionierung, Regelfreigabe, Festlegung von Gültigkeitszeiträumen, Regeldeployment, Regelausführung und Regelmonitoring.

Folglich muss das BRM, wenn Regeln in Unternehmensanwendungen eingesetzt werden sollen, unbedingt eine Toolunterstützung des gesamten Rule-Governance Prozesses liefern.

Governance zielt hierbei insbesondere auf die Synchronisierung zwischen Prozess- und Regelversion ab. Hierfür bietet das BRMS entsprechende Unterstützung auf den Ebenen der Regelerstellung, -verwaltung und -ausführung an.

R. Nelius: Gerade wenn Business Rules vom Fachbereich verändert werden können sollen, kann es unserer Erfahrung nach kritisch werden. Häufig nehmen die Fachbereiche an, dass die IT als Teil der Projektumsetzung auch eine Qualitätssicherung mit durchführt. In dem Moment, wo der Fachbereich ohne die IT Systemänderungen durchführen kann, entfällt diese Qualitätssicherung durch die IT und der Fachbereich müsste eigentlich eine eigene Qualitätssicherung aufbauen. Wir das so stringent gehandhabt in Ihrer Erfahrung?

R. Straub: Die Einbindung des Fachbereichs in die Qualitätssicherung ist von besonderer Wichtigkeit, denn dieser verfügt über das größte Verständnis der Fachlogik. Eine eher zögerliche Haltung des Fachbereichs selbst liegt oft in der geringen Nachvollziehbarkeit und eher rudimentären Testunterstützung für den Fachbereich bei klassischen Entwicklungsansätzen, bei dem häufig nur ein Blackbox Testing bereitsteht.

Hinzu kommt, dass Prozesse oftmals abteilungsübergreifend angelegt sind und verschiedene Fachbereiche integrieren, wozu dann auch verschiedenartiges Know-how einzubinden ist. Dem hingegen zielt die Geschäftslogik in einem Prozessschritt eher auf einen konkreten Fachbereich und ermöglicht diesem eine fokussierte Qualitätssicherung innerhalb seines Zuständigkeitsbereichs.

Das BRMS bietet dem Fachbereich alle Möglichkeiten, um die Regelverarbeitung bis ins Detail nachzuvollziehen, um eben nicht nur ein Blackbox Testing durchzuführen. Allein die vielfach höhere Transparenz des Ablaufs der Geschäftslogik ist ein wesentlicher Vorteil, wenn ein BRMS eingesetzt wird. Hierzu gibt es die bereits erläuterten Möglichkeiten des Whitebox Testens.

Die Fachbereiche nehmen meiner Erfahrung nach die ggf. umfangreicheren Aufgaben der Qualitätssicherung gerne an, wenn Sie im Gegenzug von einer höheren Transparenz und Nachvollziehbarkeit sowie von einer schnelleren Umsetzung von Regeländerungen profitieren, die dann kürzere Time-to-Market Zyklen ermöglichen.

R. Nelius: Herr Straub, wir danken Ihnen für das Gespräch!

Kommentar hinzufügen