Architekturüberlegungen bei der Automatisierung von Geschäftsregeln

Transkript

1 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln Markus Schacher, KnowBody Hohlstrasse 534, 8048 Zürich, Switzerland

2 Abstract Bei der Gestaltung agiler IT-Unternehmensarchitekturen steht heute vermehrt auch die Automatisierung von Geschäftsregeln im Vordergrund. Dazu bieten sich verschiedene technische Lösungsansätze an: von der expliziten Ausprogrammierung der Regeln, über deren Automatisierung durch Datenbank-Managementsysteme bis hin zum Einsatz spezialisierter Rule Engines. Dieser Vortrag zeigt auf, wie sich Geschäftsregeln pragmatisch und effizient automatisieren lassen und in welchen Fällen sich der Einsatz einer "klassischen" Rule Engine tatsächlich rechtfertigt. Zudem wird auf wichtige Überlegungen eingegangen, die bei der Gestaltung einer skalierbaren Architektur regelbasierter Systeme essentiell sind. 2

3 Unsere Mission: Bridging the Gap 3

4 Unser Angebot Consulting Situative Anwendung von Know-how aus unseren Kernkompetenzen in Projekten Training Schulung von Know-how aus unseren Kernkompetenzen Running Werkzeuge zur automatisierten Know-how Anwendung Know- How Shaping Erarbeitung und Standardisierung von neuem Know-how Doing Anwendung von Know-how aus unseren Stammgebieten zur Problemlösung und Projektabwicklung Brokering Vermittlung von Know-how aus anderen als unseren Kernkompetenzen 4

5 Ihr KnowBody in dieser Präsentation Markus Schacher 1959: Geboren in Zürich 1982: Abschluss des Studiums an der HTL Winterthur : Software Engineer bei Siemens 1987/88: Nachdiplomstudium ETH Zürich : Consultant bei Zühlke : Consultant bei Born Informatik 2001: Mitgründer der Firma KnowGravity Heute: Business/System/Software Engineering Consultant Spezialist für Executable UML (xuml) Co-Autor eines Buches zum Business Rules Ansatz Architekt von CASSANDRA und KnowEnterprise erfahrener Kursleiter & Speaker Aktives Mitglied der Business Rules Group (BRG) und der Object Management Group (OMG) 5

6 Inhalt Geschäftsregeln Rekapitulation Kategorien von Geschäftsregeln Entscheidungsgrundlagen Technologie zur Automatisierung von Geschäftsregeln Ausprogrammierung Datenbank-Managementsysteme Rule Engines Architektur-Überlegungen Standards Typische Architekturen 6

7 Geschäftsregeln

8 Begriffe Geschäftsregel / Business Rule Aus Geschäftssicht: Eine Direktive, die das Geschäftsverhalten beeinflussen oder leiten soll, um damit eine Geschäftspolitik zu unterstützen, die als Reaktion auf eine Chance, Bedrohung, Stärke oder Schwäche formuliert wurde. Aus IT Sicht: Eine Aussage, die Aspekte des Geschäfts definiert oder einschränkt. Damit wird beabsichtigt, die Struktur des Geschäftes festzulegen oder das Verhalten des Geschäfts zu kontrollieren oder zu beeinflussen. 8

9 Begriffe (2) Business Rule Ansatz Eine Menge von Techniken und Technologien, die sowohl Business Engineering als auch IT Systementwicklung abdecken, mit dem Ziel, agile Geschäfts- und IT-Systeme zu betreiben, welche direkt durch Geschäftsleute kontrolliert werden. Business Rule Engine Eine technische Software-Komponente, die für die effiziente Ausführung und Überwachung von Geschäftsregeln verantwortlich ist. 9

10 Arten von Geschäftsregeln Ableitungsregeln Eine Person ist ein bevorzugter Kunde, falls ihr Umsatz in den vergangenen 12 Monaten mindestens 500 CHF ist und sie nicht auf der schwarzen Liste ist. Eine Person ist auf der schwarzen Liste, falls eine an sie gelieferte Bestellung nicht innerhalb von 30 Tagen bezahlt wurde. Einschränkungen Ein Kunde darf nie seine Kreditlimite überschreiten. Jede aktive Bestellung darf nur aktive Produkte enthalten. Prozessregeln Wenn ein neuer Kunde eine Bestellung aufgibt, muss seine Kreditwürdigkeit geprüft werden. Guinness muss empfohlen werden, falls Heineken bestellt wird. 10

11 Beispiel: Faktenmodell & Geschäftsregel Rabatt Aktionsrabatt ist Upgrade für hat hat Fahrzeugtyp ist gebucht von Miete hat Gesamtpreis hat hat Preis pro Tag Anzahl Tage Miete hat Gesamtpreis P = T mal Fahrzeugtyp der ist gebucht von dieser Miete und hat Preis pro Tag minus R minus AR, wobei Miete hat Anzahl Tage T Miete hat Rabatt R Miete hat Aktionsrabatt AR 11

12 Das BRA Big Picture beeinflusst Umsetzung mittels Knowledge Management Markt & Gesetze treiben Externalisierung Geschäftsprozesse Business Rules BR Management Umsetzung mittels BR Technologie beeinflusst 12

13 Entscheidungsgrundlagen

14 Volatilität D Para Volatilität Regeln Regel- Management- Prozess Stabilität Vokabular Release- Prozess Applikation 14

15 Anforderungen Umsysteme Benutzer Das System Interfaces Extern Subjekt funktional Business IT Quelle Heute Anforderung in Zukunft "nice to have" notwendig Zeit Notwendigkeit Vokabular nicht-funktional Verarbeitung Objekttyp Fakttyp Änderbarkeit Vorwärts Verfügbarkeit nat. Sprachen Rückwärts Performanz Regel-Typ Autorisierung Durchsetzung Erklärung Technologie Integration Anwendbarkeit Erzwungen Prozessregeln Pull Empfehlung Ableitungen Personen Push Zeit Einschränkungen Orte Service Typ Projekt Ziel Zeit Ressource 15

16 Komplexität von Aussagen Komplexität von Kriterien: Elementare Boolesche Aussage z.b. es ist Donnerstag (weder Fakttyp noch Argumente) Boolesche Aussage mit instanzierten Argumenten z.b. Herr Meier ist präferierter Kunde Boolesche Aussage mit freien Variabeln als Argumente z.b. Herr Meier gibt auf Bestellung Komplexität von Ausdrücken: Aussagelogische Operatoren z.b. Entweder Partner ist präferierter Kunde oder Partner hat Kreditlimite K und K grösser als 1000 Prädikatenlogische Operatoren z.b. Es gibt keinen Kunden, sodass Kunde hat offenen Betrag B und Kunde hat Kreditlimite L und B grösser als L 16

17 Technologie zur Automatisierung von Geschäftsregeln

18 Klassen von Business Rules Technologie Business Rule Engine (BRE) Faktenmodell Mapping technische Business Rule Repräsentation Business Rule Deployment Rule Enforcement in Laufzeit-Umgebung Business Rule Management (BRM) Tools Regel-Dokumentation (Konzept-Katalog, Faktenmodell, Regel- Statements, Regel-Kategorisierung) Template-Definition & -Übersetzung Validierung, Verifikation & Konflikt-Identifikation Such-Mechanismen Zugriffs- und Änderungs-Autorisierung & Change Management Versionierung & Traceability Business Rule Discovery & Mining (BRD) Tools Reverse Engineering von Quell-Code Muster-Suche und Regel-Generierung aus Datenbeständen Aus (anderen) Regel-Repositories (z.b. TARMED) 18

19 Ausprogrammierung Geschäftsregeln gab es schon immer Automatisierte Geschäftsregeln gibt s schon lange Geschäftsregeln tiefer Volatilität können und sollen ausprogrammiert werden => höchst-mögliche Performance Wenn möglich, ausprogrammierte Regeln an einem einzigen (logischen) Ort konzentrieren (Layer oder Service). Ausprogrammierte Geschäftsregeln sind (trotzdem/erst recht) fachlich zu dokumentieren (für die Nachwelt ) Ausprogrammierte Geschäftsregeln können sich zur Laufzeit nicht erklären => Logging/Auditing. Trotz allem lassen sich bei Bedarf auch ausprogrammierte Geschäftsregeln mit dem Release-Zyklus aktualisieren. 19

20 Datenbank-Managementsysteme Heutige Datenbank-Managementsysteme (DBMS) gehören zu den leistungsfähigsten Rule Engines Faktenmodell-Mapping mittels Views Ableitungsregeln (auch über mehrere Stufen) mittels Views Einschränkungen mittels Constraints und/oder Trigger Prozessregeln mittels Trigger Insbesondere Einschränkungen lassen sich durch DBMS massiv durchsetzen. Views, Constraints und Trigger sind typischerweise Metadaten einer Datenbank und lassen sich rasch (auch im Betrieb) ändern => Regel-Administrator = DB-Administrator Die Regelsprache SQL ist allerdings für Nicht-Informatiker nur bedingt verständlich 20

21 Beispiele Ableitungen durch View: CREATE VIEW Bestellungsableitungen AS SELECT BestNr, (Preis - Rabatt) AS Nettopreis, (Rabatt / Preis * 100) AS Discount FROM Bestellungen; Einschränkung durch DB-Constraint: ALTER TABLE Bestellungen ADD CONSTRAINT gueltiger_status CHECK (bezahlt OR Status <> 'geliefert'), ADD CONSTRAINT gueltiger_preis CHECK (Nettopreis =< Bruttopreis); 21

22 BR Engine versus Expertensysteme Business Rules Engine Typischerweise verwendet zur Automatisierung von Geschäftsprozessen Automatisiert eine grosse Menge von (relativ) einfachen Geschäftsentscheidungen Arbeitet mit sehr grossen Datenmengen Performance ist wichtiger als eine flexible Wissensrepräsentation Produkte sind offene Middleware- Plattformen, welche sich ine eine existierende Umgebung integrieren lassen Menschen-lesbare Regel- Sprachen Expertensystem Ersetzt typischerweise einen menschlichen Experten Automatisiert einige wenige, aber komplexe Entscheidungen (z.b. Medizinalbereich oder technische Störungssuche) Arbeitet mit relativ kleinen Datenmengen Oft komplexe Formalismen zur Wissensrepräsentation notwendig (Frames, Unsicherheiten, etc.) Typischerweise hochspezialisierte, geschlossene Umgebungen und/oder eingebettete Lösungen Eher technische Regel-Sprachen (auf Programmierer-Ebene) 22

23 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 23 Vorwärts-Inferenz Gegebene Fakten Gefolgerte Fakten Zwischen-Fakten Regel Folgerungen Grundlagen

24 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 24 Vorwärts-Inferenz: Probleme Gegebene Fakten Gefolgerte Fakten Zwischen-Fakten Regel Diese Fakten werden nicht benötigt Folgerungen Grundlagen

25 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 25 Rückwärts-Inferenz Gegebene Fakten Gefolgerte Fakten Zwischen-Fakten Regel Hypothesen Fragen

26 Rückwärts-Inferenz: Probleme Spontane Requests Keine anderen Folgerungen Fragen Hypothesen Gegebene Fakten Gefolgerte Fakten Zwischen-Fakten Regel 26

27 Vorwärts- versus Rückwärts-Inferenz Vorwärts Inferenz wird sinnvollerweise angewandt, falls Abfragen von gefolgerten Fakten häufiger vorkommen als Änderungen an gegebenen Fakten typischerweise viele gefolgerte Fakten gleichzeitig von Interesse sind nur wenige gegebene Fakten zur Bestimmung der gefolgerten Fakten notwendig sind das Sammeln von gegebenen Fakten einfach bzw. effizient ist. Rückwärts Inferenz wird sinnvollerweise angewandt, falls Änderungen an gegebenen Fakten häufiger vorkommen als Abfragen von gefolgerten Fakten typischerweise wenige gefolgerte Fakten gleichzeitig von Interesse sind viele gegebene Fakten zur Bestimmung der gefolgerten Fakten notwendig sind das Sammeln von gegebenen Fakten aufwändig ist (z.b. Fragen an den Benutzer). 27

28 Der RETE-Algorithmus RETE (lat. Netz ) ist ein Verfahren, ein Netzwerk von Regeln effizient abzuarbeiten. Dabei geht es darum, möglichst rasch zu bestimmen, welche Regeln im Netzwerk feuern, d.h. deren Bedingungen wahr sind wiederholte Evaluationen von Bedingungen zu vermeiden. Dazu wird ein Netzwerk von Speicherstellen aufgebaut, die als Cache für (Teil-)Ausdrücke dienen bei Folgerungen von Regeln die betroffenen Teile dieses Caches wieder verworfen. RETE hilft vor allem dann, wenn bei der Abarbeitung der Regeln viele Bedingungen unverändert bleiben identische Teile von Bedingungen in vielen Regeln wiederholt vorkommen. RETE steigert die Performance der Regelverarbeitung auf Kosten des Speicherbedarfs und wird hauptsächlich bei Vorwärts-Inferenz eingesetzt. 28

29 Schnittstellen einer Rule Engine Verwendung von Rule Engine Diensten Applikation (Applikations-)spezifische Spracherweiterungen P ist ein präferierter Kunde, falls sein Jahresumsatz grösser als 2000 ist Execution Logs Regeln Rule Engine Applikations-Funktionen & Libraries Bereitstellung von Regeln und Protokollierung derer Ausführung Applikations-Layer & Frameworks Zugriffsfunktionen auf Applikationsumfeld 29

30 JSR-94 Standardisiert ein Java-API, wie eine Rule Engine aus einer Applikation aufgerufen wird. Administration Laden und verwalten von Treibern zu Rule Engines Laden und verwalten von Rule Sets Stateless Sessions Übergabe einer Liste von Objekten, Ausführung eines Rule Sets und Rückgabe einer Liste von Objekten in Form eines einzigen Aufrufs Erlaubt die selektive Rückgabe von Objekten via Filter Stateful Sessions Erlaubt längere Interaktionen mit der Rule Engine Ermöglicht das selektive Hinzufügen und Entfernen von Objekten via Handles 30

31 Architektur-Überlegungen

32 Die Service-Architektur Application Client Database Engine SQL Rule Services API Business Rules Engine + Einfach in eine existierende Umgebung integrierbar + Gute Unterstützung für (komplexe) Ableitungsregeln + Gute Transparenz; oft sogar Erklärungskomponente verfügbar + Viele kommerzielle Produkte verfügbar Database SQL Business Rules Weniger gut für Einschränkungen geeignet Geschäftsregeln können umgangen werden, d.h. BRE muss nicht aufgerufen werden Performance kann problematisch sein 32

33 Daten-Schnittstelle Im Rahmen einer Service-Architektur können deklarierte Fakttypen auf zwei Arten einer Rule Engine zur Verfügung gestellt werden: Via Push-Schnittstelle Bei einem Service-Aufruf werden der Rule Engine sämtliche für die Entscheidung relevanten Informationen mitgegeben Via Pull-Schnittstelle Bei einem Service-Aufruf holt sich die Rule Engine sämtliche für die Entscheidung relevanten Informationen selber 33

34 Push-Schnittstelle Applikation 3 Rule Engine 4 Ist Herr Meier ein präferierter Kunde 5 Ja P ist ein präferierter Kunde, falls sein Jahresumsatz grösser als 2000 ist 1 2 Kunden Bestellungen Artikel 34

35 Pull-Schnittstelle Applikation Rule Engine 2 Ist Herr Meier ein präferierter Kunde 4 Ja P ist ein präferierter Kunde, falls sein Jahresumsatz grösser als 2000 ist 1 3 Kunden Bestellungen Artikel 35

36 Gegenüberstellung Push-Schnittstelle + keine allgemeine Schnittstelle der Rule Engine auf die Geschäftsdaten notwendig + oft kein zusätzlicher DB-Zugriff notwendig, da die notwendigen Daten im Aufrufer bereits vorhanden sind nicht geeignet für grosse Datenmengen bei Regel-Änderungen muss ggf. die Aufruf-Schnittstelle angepasst werden Pull-Schnittstelle + die Aufruf-Schnittstelle bleibt auch bei Regel-Änderungen stabil + auch für grosse oder unbekannte Datenmengen geeignet generischer Zugriff der Rule Engine auf Geschäftsdaten erforderlich ev. resultieren redundante DB-Zugriffe von Aufrufer und Rule Engine 36

37 Die Layer-Architektur Application Client Business Rules Engine Business Object API Business Rules + Gute Unterstützung für Einschränkungen und Ableitungsregeln + Kann nur schwer umgangen werden, d.h. Daten sind durch Einschränkungen geschützt + Ableitungsregeln können transparent integriert werden (keine Unterscheidung zwischen deklarierten und abgeleiteten Fakten) Database Engine SQL Database Prozessregeln schwierig abbildbar Typischerweise proprietärer Zugriffs- Mechanismus auf Daten Performance kann problematisch sein Nur wenige kommerzielle Produkte verfügbar 37

38 Kompilations-Architektur Application User Interface User Interface Code Application Logic Application Logic Code Business Rule Compiler Database Engine Integrity Constraints and Trigger Code Database Business Rules 38

39 Kompilations-Architektur: Eigenschaften + Sehr gute Performance + Redundante Anwendung von Regeln (z.b. Server und Client) + Unterstützt alle Arten von Regeln Geschäftsregeln können umgangen werden Aktive Regeln kaum mehr sichtbar (Transparenz) Unter Umständen schwer in eine bestehende Umgebung integrierbar Nur wenige kommerzielle Produkte verfügbar 39

40 Ein Architekturbeispiel mit Drools Browser JSF Session Application Beans View Responsibility: map data objects to GUI beans propagate changes to the rule engine handle results of the rule engine propagate validated changes to the data objects set get Mapper change Data Objects ins / upd / fireallrules fieldmodel updates Controller get results WM Drools Facade Model Service X Service Y Rule Definitions 40

41 Zusammenfassung

42 Heuristiken Volatilität beachten Anforderungen an Rule Execution Technologie explizit machen Geschäftsregeln können auch programmiert werden DBMS sind sehr leistungsfähige Rule Engines Auf geeignete Regel-Repräsentation achten Faktenmodell-Mapping An Rule Engine zu übertragende Datenmengen beachten Stateful Sessions vermeiden Unternehmensweites Rule Management nicht vergessen 42

43 Besten Dank für Ihre Aufmerksamkeit Fragen ISBN