Jusletter IT

Business Rules werden einerseits als Regeln, die bestimmte geschäftliche¹ Aspekte eindeutig beschreiben, und andererseits als Anweisungen, mit deren Hilfe Fachanwender Informationssysteme direkt und ohne Umweg über einen traditionellen Implementierungsprozess steuern können, begriffen. Beide Sichtweisen sind für die Rechtsinformatik von hoher Relevanz und in Verbindung miteinander ermöglichen sie prinzipiell eine durchgängige, zielkonforme und konsistente Steuerung von Menschen und Informationssystemen. Allerdings ist das Denken in Business Rules in der Praxis aktuell weit weniger „in Mode“ als das Denken in Prozessen. Tatsächlich scheint die grafisch aufbereitete und durch vielerlei Software unterstützte Modellierung von Prozessen intuitiver und angenehmer als die textuelle Festlegung von Regeln. Jedoch weist gerade die Regelgestaltung in den Rechtsdisziplinen eine gewisse Historie auf und dürfte Juristen deshalb sogar entgegenkommen.

Der Tagungsbeitrag zeigt zunächst in knapper Form die Herkunft und die Funktionsweise des Business Rule Managements (BRM). Danach werden die Beziehungen von Business Rules zu Prozessen, Automatisierungsaspekte und Sprachstandards herausgearbeitet. Der Beitrag schließt mit einer ganzheitlichen Sichtweise auf das BRM und begründet den Bedarf nach Forschung sowie deren öffentlicher Förderung.

Für das BRM lassen sich zwei wesentliche Leitlinien identifizieren. Die organisatorische Leitlinie, die auf die Business Rule Group um Ross in den 1990er Jahren zurückgeht² und die IT-Leitlinie, die sich auf die Expertensysteme der 1970er Jahre gründet. Beide Ansätze führen eine friedliche Koexistenz. Hersteller von Business Rule Management Software – die eine Weiterentwicklung regelbasierter Expertensysteme darstellt – profitieren³ direkt von einem gesteigerten Problembewusstsein und den Problemlösungsansätzen der organisatorischen Leitlinie. Sie gehören deshalb zu deren wesentlichen Sponsoren.⁴ BRM ist keineswegs ein neues Thema. Es hat jedoch bisher bei weitem nicht die Aufmerksamkeit anderer Ansätze wie Service Orientierte Architekturen (SOA) oder Business Process Management (BPM) erhalten.

In organisatorischer Hinsicht ist eine Business Rule ein atomistisches Stück Wissen, das einen bestimmten Ausschnitt des Geschäftes beschreibt. Ein häufig angeführtes Beispiel einer Business Rule lautet: Ein Goldkunde erhält 10% Rabatt. Diese Regel ist im Idealfall Teil der Umsetzung einer bestimmten Strategie, mit z.B. dem Ziel, die Kundenbindung zu erhöhen. Sofern sich die strategische Richtung ändert, müssen auch die korrespondierenden Business Rules angepasst werden. Die Regel könnte z.B. wegfallen oder der Rabattsatz könnte gemindert werden, wenn es zukünftig um Umsatzmaximierung gehen soll, oder es könnten neue differenziertere Regeln hinzukommen, die bestimmte Kundengruppen besser stellen als andere. Das Beispiel zeigt, dass Business Rules über Parameter wie z.B. eine Rabattstaffel hinausgehen, die nur hinsichtlich ihrer Ausprägung Anpassungen ermöglichen.

Business Rules sind eindeutig und ausführbar, dies bedingt, dass alle Begriffe, z.B. „Kunde“ und „Rabatt“ exakt und nicht-interpretierbar definiert sein müssen.⁵ Business Rules beschreiben Entscheidungen. Sie enthalten einen Bedingungs- und einen Aktionsteil, deshalb werden Business Rules auch häufig in WENN-DANN-Form formuliert. Die Goldkundenregel würde entsprechend lauten: WENN ein Kunde Goldkunde ist, DANN erhält er 10% Rabatt. Es gibt aber auch noch viele weitere Darstellungsformen, z.B. Entscheidungstabellen und -bäume. Im Aktionsteil können sowohl Werte verändert als auch Aktionen ausgelöst werden, z.B. WENN ein Kunde ein Goldkunde ist, DANN offeriere Platinstatus. Somit können eine Menge von Business Rules auch Abläufe determinieren.

Business Rules sind ein Mittel, um die Semantik eines Bereiches zu dokumentieren. Ein wesentliches Ziel der organisatorischen Leitlinien des BRM liegt in der Überführung von Wissen, das an verschiedensten Stellen und unter Umständen nur in den Köpfen einzelner Personen vorliegt, in eine zentrale, formalisierte und semantisch eindeutige Form. Über die reine Dokumentation hinausgehend können diese Business Rules dann auch zur Menschenführung eingesetzt werden oder steuern Informationssysteme.

Abbildung 1 skizziert ein initiales Business-Rules-Modell.⁶ Auf einer konzeptionellen Ebene definieren sogenannte Structural Business Rules, was unter dem Geschäft verstanden wird, z.B. was eine Rechnung ist. Innerhalb dieser Struktur reagieren die sogenannten Operational Business Rules dynamisch auf neue Gegebenheiten und determinieren das Verhalten des Geschäftes. Die konzeptionellen Regeln können sowohl zur Steuerung von Menschen als auch zur Steuerung von Informationssystemen – und damit mittelbar auch zur Steuerung von Maschinen und weiterem Gerät – dienen. Damit frei über die Art der Implementierung entschieden werden kann, muss für die Konzeption eine implementierungsunabhängige Modellierung verwendet werden. Sollen Business Rules zur Menschenführung eingesetzt werden, sind dementsprechende Aspekte zu beachteten, z.B. müssen die Business Rules für die Adressaten verständlich sein. Es kann jedoch davon ausgegangen werden, dass diese Adressaten denkfähig sind. Es obliegt dem Führungssystem des Geschäftes, die Einhaltung dieser Business Rules sicherzustellen. Werden die Business Rules zur Steuerung von Informationssystemen verwendet, müssen sie exakt auf die Semantik und die Syntax der relevanten Informationssysteme ausgerichtet werden. Eine Rechnung ist in diesem Fall eher eine Objektstruktur mit Attributen und Funktionen.

Ein Prozess ist zunächst eine Abfolge von Aktivitäten. Geschäftsprozesse sind Abfolgen, die geschäftsrelevante Ergebnisse erzielen. Beim BPM geht es im Wesentlichen darum, ganzheitlich auf den Leistungsempfänger ausgerichtet zu denken und nicht nur die Leistung einzelner Abteilungen zu optimieren, sondern den gesamten Prozess. Je detaillierter die Prozessmodelle werden, desto schneller stößt die Modellierung allerdings an ihre Grenzen. Insbesondere ist dies der Fall, wenn der Verlauf einer Prozessausführung von vielen Entscheidungen abhängt. Die Prozessmodelle werden dann schlichtweg so unübersichtlich, dass sie kognitiv nicht mehr zu verarbeiten sind. In diesem Fall ermöglicht die Auslagerung von Entscheidungen aus Prozessmodellen in ein gesondertes Business Rule Modell wesentliche Vereinfachungen.⁷ Weitere Probleme ergeben sich, wenn der Prozessverlauf nicht nur in der eigenen Verantwortung liegt, sondern auch in der von externen Instanzen.

Ein Geschäftsprozessmodell ist normalerweise das Ergebnis der Beachtung von Business Rules und einer Freiheitsgrade ausnutzenden kreativen Planung. Bei einer ausschließlichen Festlegung der Business Rules würden diese Freiheitsgrade somit bis zur Prozessausführung erhalten bleiben und könnten dann situationsspezifisch verwendet werden.

Abbildung 2 zeigt ein einfaches Prozessmodell in der häufig verwendeten Notation der Ereignisgesteuerten Prozessketten (EPK). Der Prozess resultiert aus einer Reihe von Business Rules:

• Ein Stammkunde zahlt 100€.
• Ein Nicht-Stammkunde zahlt 200€.
• Ein Fahrer muss einen gültigen Führerschein haben.

Allerdings kann der Prozess auch Tatsachen schaffen, die nicht auf Business Rules beruhen, sondern lediglich der Modellierung einer Kette geschuldet sind und die in Konsequenz nicht-notwendige Regeln erschaffen, z.B.: Die Führerscheinprüfung erfolgt (direkt) nach der Stammkundenprüfung. Der Modellierer schöpfte den ihm zur Verfügung stehenden Freiheitsgrad bereits bei der Modellierung aus und legt diese Abfolge fest.

Man kann sich z.B. ganz praktisch vorstellen, dass der Kunde bereits mit dem Führerschein in der Hand das Geschäft betritt und deshalb sinnvollerweise diese Prüfung am Anfang stehen sollte. Wenn es tatsächlich egal ist, welche Prüfung zuerst erfolgt, dann sollte dieser Freiheitsgrad bis zur Prozessausführung erhalten werden. Je variantenreicher die Abläufe in der Realität werden können, desto höher ist die Wahrscheinlichkeit, diese Fälle bei der Modellierung nicht zu bedenken. Da Business Rules Abläufe modellieren können, dies aber nicht tun müssen, sind sie für solche Situationen besser geeignet. Dennoch kann die intuitive und weit verbreitete Modellierung von Prozessen, z.B. mithilfe von EPK natürlich auch ein Weg zur Identifikation und Modellierung von Business Rules sein. Die Business Rules müssen nur in einem weiteren Schritt aus den Prozessmodellen extrahiert werden.⁸

Bei der traditionellen Entwicklung von Informationssystemen erfolgt mithilfe menschlicher Experten die Verschmelzung von Anwendungs- und Implementierungswissen zur Designzeit. Im Resultat liegen meist Programmcode, zugekaufte Komponenten und Dokumentation vor. Nach der Inbetriebnahme dieses Amalgams sind im Normalfall immer wieder Änderungen notwendig; als Fehlerbeseitigung oder in Reaktion auf neue Anforderungen. Auch diese Änderungen benötigen wiederum die Zusammenarbeit von Anwendungs- und Implementierungsexperten. Änderungen sind somit immer relativ aufwendig und risikoreich und das steht mittelbar einem flexiblen Handeln von Organisationen im Wege.⁹ Mithilfe einer sogenannten Business Rule Engine kann die Verschmelzung von Anwendungs- und Implementierungswissen automatisiert während der Laufzeit des Informationssystems erfolgen und Anwendungs- sowie Implementierungsexperten können die jeweils für sie relevanten Aspekte getrennt voneinander entwickeln und ändern. Mittelbar fördert es auch die Flexibilität der Organisation, wenn diese nicht mehr durch ihre schwer änderbaren Informationssysteme behindert wird.

Abbildung 3 zeigt die Trennung des Informationssystems in die Anwendungsumgebung und das Business Rule Management System. Die Anwendungsumgebung gibt die Kontrolle über das Verhalten des Informationssystems zur Laufzeit an bestimmten Punkten an die Business Rule Engine ab, die dazu die durch Anwendungsexperten entwickelten Business Rules verwendet. Die Anwendungsexperten nutzen zur Entwicklung, Änderung und Verwaltung von Business Rules häufig sogenannte Business Rule Builder, siehe Abbildung 4 für Screenshots.

Für automatisierte Business Rules werden Sprachen verwendet, die auf Nicht-Implementierungsexperten zugeschnitten sind – dennoch erfordern sie eine exakte Syntax, da automatisierte Business Rules auch durch die maschinelle¹⁰ Anwendungsumgebung verstanden werden müssen.

Die Möglichkeiten der Steuerung von Informationssystemen durch Business Rules werden durch das in der Anwendungsumgebung gebundene Anwendungswissen begrenzt. Je generischer die Anwendungsumgebung ist, desto flexibler kann sie auf geänderte Business Rules reagieren, ohne dass sie selber angepasst werden muss. Eine prinzipiell sehr generische Anwendungsumgebung ist das sich abzeichnende Internet der Dienste¹¹ . Sofern die Dienste mit der benötigten Funktionalität irgendwo bereitstehen und über Business Rules angesprochen werden können, wären Anwendungsexperten in der Lage, individuelle Informationssysteme ausschließlich mithilfe von Business Rules zu entwickeln und zu ändern. Natürlich ist dies Zukunftsmusik, aber auch für die teilweise Nutzung von Drittanbieterdiensten und für die Kombination mit eigenerstellten Diensten im Rahmen einer SOA stellt das Business-Rule-Denken eine hilfreiche Erweiterung dar.

Business Rule Engines und Builder werden in Form von Open Source und als geschlossene Software von verschiedenen Herstellern angeboten. Alle nutzen eigene Business-Rule-Sprachen. Allerdings bemühen sich große Organisationen wie die Object Management Group (OMG) und das World Wide Web Consortium (W3C) um Sprachstandards. Ein Beispiel dafür ist das Rule Interchange Format (RIF) des W3C, das den Austausch von Business Rules zwischen verschiedenen Umgebungen unterstützt.¹² Sofern die Business Rules von einer zentralen Stelle, z.B. von einer staatlichen Instanz herausgegeben werden, könnte RIF zum Einsatz kommen, um diese in unterschiedlichen Umgebungen zu automatisieren.

Die OMG stellt in Form von Semantics of Business Vocabulary and Business Rules (SBVR)¹³ und des Business Motivation Models (BMM)¹⁴ zwei Sprachspezifikationen zur Verfügung, die Business Rules thematisieren. SBVR unterstützt die Erstellung von Geschäftsvokabularen und darauf aufbauend von Geschäftsfakten und Business Rules, die für definierte semantische Gemeinschaften gültig sind. SBVR ist sehr mächtig und nicht unbedingt intuitiv verwendbar. Insbesondere die überwiegende Nutzung von Text erfordert – gegenüber der Nutzung weniger, einfacher, grafischer Elemente, z.B. bei EPK – eine tiefere Auseinandersetzung mit der Methode. Dass die Einfachheit der Modellierung von EPK auch deren Missbrauch fördern kann, wurde bereits bei der Gegenüberstellung von Business Rules und Prozessen angeführt. Die relative Schwierigkeit von SBVR kann demnach auch Vorteile mit sich bringen.

 

Das BMM unterstützt die Ableitung von Zielen und Mitteln zu deren Erreichen, siehe Abbildung 5. Es verwendet eine Trennung in Zweck und Mittel auf verschiedenen Ebenen, die ein schrittweises Konkretisieren bis zur Ableitung von Business Rules ermöglichen. Im Gegensatz zu dem sehr stark formalisierten SBVR ist das BMM eher oberflächlicher Natur und stellt grundsätzliche Ideen bereit, die während der Anwendung stark konkretisiert werden müssen. Es ist jedoch grade deshalb ein leicht anzuwendendes und hilfreiches Werkzeug zur Ableitung der Business Rules aus den obersten Zielen einer Unternehmung.

Business Rule Management ist für die freie Wirtschaft, aber insbesondere auch für öffentliche Institutionen ein interessantes Thema, da es gleichzeitig die vertikale Integration von den obersten Zielen bis zu deren Umsetzung und die horizontale Integration von Anwendungen und deren Implementierung in Informationssystemen ermöglicht. Das real existierende Business Rule Management bleibt hinter dessen prinzipiellen Möglichkeiten zurück, was auf die Notwendigkeit für weitere Forschung hindeutet. Zwar forschen sowohl die Hersteller von Business Rule Software wie z.B. IBM, Bosch und JBoss an der Verbesserung ihrer Produkte als auch große Forschungseinrichtungen an den generellen Möglichkeiten des Business Rule Managements¹⁵ . Es besteht jedoch durchaus weiterer Bedarf an anwendungsorientierter Forschung. Abbildung 6 zeigt ein Modell, das im Nachgang eines Workshops zum Business Rule Management auf der Informatik 2010 Service Science in Leipzig erstellt wurde und das für eine ganzheitliche Auseinandersetzung mit einem Business Rule Management System geeignet ist.¹⁶

Das Modell identifiziert sechs unterschiedliche Sichten auf ein Business Rule Management System:

1. Rationale; das System als Ganzes und seine Bestandteile müssen begründet sein, dazu dient beispielsweise das BMM.
2. Presentation; Business Rules können auf unterschiedliche Weise dargestellt werden oder in Erscheinung treten, z.B. in Form expliziter WENN-DANN-Regeln, aber auch als Prozessdarstellungen oder als Aushang an der Wand.17
3. Conceptual; Business Rules müssen so gestaltet werden, dass sie mit externen Regelwerken konform sind und leicht angepasst werden können. Sie nutzen ein eindeutiges Vokabular. Allerdings können Business Rules einer unterschiedlichen Logik unterworfen sein, z.B. bedingt durch deren Implementierung. Beispielsweise SBVR und RIF sind hier einzuordnen.
4. Implementation; die Implementierung kann sowohl durch Informationssysteme als auch durch Menschen erfolgen. Manche Business Rules sind für eine bestimmte Implementierungsform prädestiniert, bei anderen kann frei darüber entschieden werden.
5. Runtime; Business Rules jeglicher Implementierungsform können gemeinsam in konkreten Situationen zum Einsatz kommen. Die Verknüpfung des Business Rule Management Systems mit Informationssystemen zur Laufzeit erfolgt über den sogenannten Working Memory, der potenzielle Business Rules und Ereignisse erhält, die Business Rules auslösen können, welche dann ihrerseits Aktionen verursachen. Sowohl die Quelle für Ereignisse als auch die Konsequenzen von Aktionen müssen nicht unbedingt innerhalb des Kontrollbereiches des Business Rule Management Systems liegen.
6. Administration; alle Aspekte des Business Rule Management Systems - die Business Rules selber, ihre Implementierung, ihre Darstellung und die zugrunde liegende Logik - müssen konsistent verwaltet werden.

 

 

Für alle sechs Sichten und für deren gemeinsame Betrachtung existiert Forschungsbedarf, der über die Interessen einzelner Hersteller hinausgehen sollte und deshalb öffentlicher Förderung bedarf.

Becker, Jörg, Ahrendt, Christoph, Coners, André, Weiß, Burkhard, Winkelmann, Axel, Business Rule Based Extensions of a Semantic Process Modeling Language for Managing Business Process Compliance in the Financial Sector. In:

Fähnrich, K-P./Franczyk, B. (Hrsg.), Informatik 2010 Service Science – Neue Perspektiven für die Informatik Band 1, Lecturer Notes in Informatics (LNI) Proceedings, Leipzig, S. 201–206 (2010).

Business Rule Group, Defining Business Rules ~ What Are They Really?, http://www.businessrulesgroup.org/ first_paper/br01c0.htm aufgerufen 6.1.2012 (Erscheinungsjahr 1993).

Graham, Ian, Business Rules Management and Service Oriented Architecture A Pattern Language, Wiley, Chichester (2006).

Grob, Heinz Lothar, Bensberg, Frank, Coners André, Regelbasierte Steuerung von Geschäftsprozessen - Konzeption eines Ansatzes auf Basis von Process Mining. In: Wirtschaftsinformatik (4/2008), S. 268–281 (2008).

OMG, Business Motivation Model (BMM), v1.1, http://www.omg.org/spec/BMM/1.1/PDF aufgerufen 6.1.2012 (Erscheinungsjahr 2010).

OMG, Semantics of Business Vocabulary and Business Rules (SBVR), v1.0, http://www.omg.org/spec/SBVR/1.0/PDF aufgerufen 6.1.2012 (Erscheinungsjahr 2008).

Pitschke, Jürgen, Integrierte Unternehmensmodelle – SBVR in der Praxis anwenden. In: Fähnrich, K-P./Franczyk, B. (Hrsg.), Informatik 2010 Service Science – Neue Perspektiven für die Informatik Band 1, Lecturer Notes in Informatics (LNI) Proceedings, Leipzig, S. 188–194 (2010).

Resch, Olaf, Six Views on the Business Rule Management System. In: e-Journal of Practical Business Research, Ausgabe 11, http://www.e-journal-of-pbr.info/resch-six-views-business-rule-management-system aufgerufen 20.11.2010 (Erscheinungsjahr 2010a).

Resch, Olaf, Business-Rule-basierte Servicesteuerung. In: Fähnrich, K-P./Franczyk, B. (Hrsg.), Informatik 2010 Service Science – Neue Perspektiven für die Informatik Band 1, Lecturer Notes in Informatics (LNI) Proceedings, Leipzig, S. 187–188 (2010).

Resch, Olaf, Business-Rule-Management. In: wisu Das Wirtschaftsstudium (3/07), S. 317–321 (2007).

Resch, Olaf, Business Rule Management als Instrument des Software Reengineering. In: Softwaretechnik Trends, Vol. 25(2), http://pi.informatik.uni-siegen.de/stt/25_2/WSR05/PDF/29Resch.pdf aufgerufen 20.05.2005 (Erscheinungsjahr 2005).

W3C, RIF Overview, http://www.w3.org/TR/rif-overview aufgerufen 6.1.2012 (Erscheinungsjahr 2010).