Architekturüberlegungen bei der Automatisierung von Geschäftsregeln
Werbung
Architekturüberlegungen bei der Automatisierung von Geschäftsregeln Markus Schacher, KnowBody Hohlstrasse 534, 8048 Zürich, Switzerland www.knowgravity.com 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. Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 2 Unsere Mission: Bridging the Gap Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 3 Unser Angebot Consulting Situative Anwendung von Know-how aus unseren Kernkompetenzen in Projekten Training Schulung von Know-how aus unseren Kernkompetenzen Doing KnowHow Running Anwendung von Know-how aus unseren Stammgebieten zur Problemlösung und Projektabwicklung Brokering Werkzeuge zur automatisierten Know-how Anwendung Vermittlung von Know-how aus anderen als unseren Kernkompetenzen Shaping Erarbeitung und Standardisierung von neuem Know-how Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 4 Ihr KnowBody in dieser Präsentation • • • • • • • • • Markus Schacher 1959: Geboren in Zürich 1982: Abschluss des Studiums an der HTL Winterthur 1982-1988: Software Engineer bei Siemens 1987/88: Nachdiplomstudium ETH Zürich 1988-1992: Consultant bei Zühlke 1992-2001: 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) Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 5 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 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 6 Geschäftsregeln 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. Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 8 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. Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 9 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.“ Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 10 Beispiel: Faktenmodell & Geschäftsregel Rabatt ist Upgrade für Fahrzeugtyp hat Preis pro Tag ist gebucht von Aktionsrabatt hat hat Miete hat Gesamtpreis hat 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 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 11 Das BRA Big Picture beeinflusst Umsetzung mittels Knowledge Management Markt & Gesetze treiben Geschäftsprozesse Externalisierung Business Rules BR Management Umsetzung mittels BR Technologie beeinflusst Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 12 Entscheidungsgrundlagen Volatilität D Para RegelManagementProzess Regeln Volatilität Stabilität Vokabular ReleaseProzess Applikation Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 14 Anforderungen Business Interfaces Umsysteme IT Extern "nice to have" notwendig Zeit Quelle Benutzer in Zukunft Heute Notwendigkeit Subjekt Ziel Anforderung Das System Zeit Ressource Projekt funktional Typ nicht-funktional Vokabular Verarbeitung Objekttyp Fakttyp Durchsetzung Erzwungen Empfehlung Regel-Typ Änderbarkeit Vorwärts nat. Sprachen Rückwärts Autorisierung Erklärung Anwendbarkeit Prozessregeln Ableitungen Pull Personen Einschränkungen Verfügbarkeit Performanz Technologie Integration Architekturüberlegungen bei der Automatisierung von Geschäftsregeln Zeit Push Orte Service 15 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“ Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 16 Technologie zur Automatisierung von Geschäftsregeln 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, RegelStatements, 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) Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 18 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. Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 19 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! Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 20 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); Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 21 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 MiddlewarePlattformen, welche sich ine eine existierende Umgebung integrieren lassen • Menschen-lesbare RegelSprachen Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 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 Vorwärts-Inferenz Grundlagen ? ! ? ! ! ! ! ! ! ! ! ! ! ! ! ! ! Folgerungen ? ? ? ? Gegebene Fakten ! Gefolgerte Fakten Architekturüberlegungen bei der Automatisierung von Geschäftsregeln ! ! Zwischen-Fakten Regel 23 Vorwärts-Inferenz: Probleme Diese Fakten werden nicht benötigt Grundlagen ? ! ? ! ! ! ! ! ! ! ! ! ! ! ! ! ! Folgerungen ? ? ? ? Gegebene Fakten ! Gefolgerte Fakten Architekturüberlegungen bei der Automatisierung von Geschäftsregeln ! ! Zwischen-Fakten Regel 24 Rückwärts-Inferenz ? ! ! Fragen ? ! ! ! ! ! ! ? Hypothesen ? ? ? Gegebene Fakten ! ! ! ! ! ! ! Gefolgerte Fakten Architekturüberlegungen bei der Automatisierung von Geschäftsregeln ! ! ! Zwischen-Fakten Regel 25 Rückwärts-Inferenz: Probleme Spontane Requests ? Keine anderen Folgerungen ! ! Fragen ? ! ! ! ! ! ! ? Hypothesen ? ? ? Gegebene Fakten ! ! ! ! ! ! ! Gefolgerte Fakten Architekturüberlegungen bei der Automatisierung von Geschäftsregeln ! ! ! Zwischen-Fakten Regel 26 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). Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 27 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. Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 28 Schnittstellen einer Rule Engine Verwendung von Rule Engine Diensten (Applikations-)spezifische Spracherweiterungen Applikation P ist ein präferierter Kunde, falls sein Jahresumsatz grösser als 2000€ ist Rule Engine Execution Logs Applikations-Funktionen & Libraries Regeln Bereitstellung von Regeln und Protokollierung derer Ausführung Applikations-Layer & Frameworks Architekturüberlegungen bei der Automatisierung von Geschäftsregeln Zugriffsfunktionen auf Applikationsumfeld 29 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 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 30 Architektur-Überlegungen Die Service-Architektur Application Client Rule Services API SQL Database Engine Business Rules Engine SQL Database Business Rules Architekturüberlegungen bei der Automatisierung von Geschäftsregeln + 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 − 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 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 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 33 Push-Schnittstelle Applikation Rule Engine Ist Herr Meier ein präferierter Kunde? P ist ein präferierter Kunde, falls sein Jahresumsatz grösser als 2000€ ist Ja Kunden Bestellungen Artikel Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 34 Pull-Schnittstelle Applikation Rule Engine Ist Herr Meier ein präferierter Kunde? Ja P ist ein präferierter Kunde, falls sein Jahresumsatz grösser als 2000€ ist Kunden Bestellungen Artikel Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 35 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 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 36 Die Layer-Architektur Application Client Business Object API Business Rules Engine Business Rules SQL Database Engine Database + 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) − Prozessregeln schwierig abbildbar − Typischerweise proprietärer ZugriffsMechanismus auf Daten − Performance kann problematisch sein − Nur wenige kommerzielle Produkte verfügbar Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 37 Kompilations-Architektur Application User Interface User Interface Code Application Logic Business Rule Compiler Application Logic Code Integrity Constraints and Trigger Code Database Engine Database Architekturüberlegungen bei der Automatisierung von Geschäftsregeln Business Rules 38 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 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 39 Ein Architekturbeispiel mit Drools Session Browser Application JSF View Beans 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 ins / upd / fireAllRules Mapper change WM get r field esult Mod s el up date s Data Objects Controller Facade Service X Model Service Y Architekturüberlegungen bei der Automatisierung von Geschäftsregeln Drools Rule Definitions 40 Zusammenfassung 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! Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 42 Besten Dank für Ihre Aufmerksamkeit! Fragen? ISBN 3-540-25676-8 Architekturüberlegungen bei der Automatisierung von Geschäftsregeln 43
