I got an update on the Oracle Business Rules product recently. Oracle is an interesting company - they have the components of decision management but do not yet have them under a single umbrella. For instance, they have in-database data mining (blogged about here), the Real Time Decisions (RTD) engine, event processing rules and so on. Anyway, this update was on business rules.
RuleSpeak® beinhaltet eine Menge von Richtlinien für die Darstellung von Geschäftsregeln in prägnanter, anwenderfreundlicher Art. Es ist keine Sprache oder Syntax per se, vielmehr eine Sammlung von "Best Practices" für deutsch-sprechende Geschäftsanwender.
Technically, BPM/Business Rules approach place process logic with the BPM suite and decision logic in the business rules management system (BRMS). The process logic in a BPM suite sequences and controls activities and launches and cancels processes. Control is achieved with timers and exception handlers. Processes can be designed to recover from errors, restart processes and coordinate activities. The BRMS effectively designs, organizes and executes the logic behind a process decision. An effective BRMS can handle any depth and complexity of decision logic, including computationally complex logic and dense logic.
Bruce makes an interesting comment on business rules too: that “routing logic in process gateways” are not “business rules”. That doesn’t really make sense: for sure some gateways will be process-housekeeping decisions of little interest to the business user, but others will surely embed business-critical decisions. On the other hand, it has long been acknowledged that a best practice for BPM is to delegate such business decisions to a managed decision service - hence the explicit new business rule (aka decision) task in BPMN 2.0. And,in the CEP world, for tools like TIBCO BusinessEvents to invoke a decision managed by its Decision Manager tool.
Term: a word or phrase used to describe a thing or to express a concept [1]
Concept: an abstract idea. Concepts are expressed by terms. [1]
Fact: Facts relate terms [2]
Fact Type: a fact type is an association between two or more concepts
Vocabulary: the body of words used in a particular language or in a particular sphere [1]
Terminology: the body of terms used in a subject of study, profession, etc. [1]
Fact Model: A fact model establishes the basis for shared operational business knowledge. [2] This model is usually graphical and can also be called the business object model or BOM.
Based on feedback from clients and earlier surveys, I have compiled and listed the benefit themes below:
Business Agility: Faster reactive and proactive time to market
Decision Making: Test rule-based scenarios at lower cost
Revenue Opportunities: Greater product, pricing and flexibility
Customer Satisfaction: More-customizable products and services
Compliance; Greater visibility into policy adherence
The main characteristic to be aware of in these tools is that BE is primarily rule-based (using an embedded rule engine), whereas BW and iProcess are orchestration / flow engines. In BE we can use a state diagram to indicate a sequence of states which may define what process / rules apply, but this is really just another way of specifying a particular type of rules (i.e. state transition rules).
The main advantages to specifying behavior as declarative rules are:
Handling complex, event-driven behavior and choreography
Iterative development, rule-by-rule
The main advantages of flow diagrams and BPMN-type models are:
Ease of understanding (especially for simpler process routes)
Process paths are pre-determined and therefore deemed guaranteeable.
In combination these tools provide many of the IT capabilities required in an organization. For example, a business automation task uses BW to consolidate information from multiple existing sources, with human business processes for tasks such as process exceptions managed by iProcess. BE is used to consolidate (complex) events from systems to provide business information, or feed into or drive both BW and iProcess, and also monitors end-to-end system and case performance.
OpenLexicon is an open-source business rules and process management tool that rapidly develops applications for transaction and process-based applications. OpenLexicon is known for providing high performance solutions and has been used in a number of enterprise-level applications. You can read about these here . You can use either product separately or in concert. There are two main components of OpenLexicon: the metadata repository and the business rules engine. Major components of OpenLexicon are released as open source software under the OpenLexicon OpenSource License. A good overview of the business rules approach is available here .OpenLexicon has a Wizard that is a web-form based collaborative tool for building business rules and business use cases. For a brief overview of the wizard, look at this link . We have designed the Wizard for non-developers and analysts with light technical skills. It features a richer experience for the users on the web, traditionally only offered by thick-client UIs. The collaboration team assembles groups of business rules into a business use case and published in a metadata file or the database. OpenLexicon provides solid support for web services. You can read about the OpenLexicon WSDL here . There is also an eclipse plug-in for web services here . You create complex application behavior with OpenLexicon’s process management. OpenLexicon can build an application reads data from a file, performs reference data lookups, validates the entire object, and then stores it in a database table. You can read about this here . Plus, you can build the application in the Wizard while writing no code! OpenLexicon also supports web services. A simple architecture diagram for OpenLexicon is included here .
On Wednesday morning, June 12, I gave my paper on the three business rules projects to the ERBC: The projects were: Drools, OpenLexicon and OpenRules. It was well attended and well received. Pete Skangos and I gave everyone a copy of the book and we started an impromptu signing line, until it was a bit past the beginning of the next paper.
Vor einigen Tagen fand ich einen Artikel, der auf sehr anschauliche Weise erklärte, weshalb der Business-Rules-Ansatz so wichtig ist. Es sind immer noch wenige Experten, die von jener Relevanz des Business Rules Managements (BRM) ausgehen. Drei entscheidende Fragen werden sich all jene stellen, die ernsthaft über einen Einsatz von BRM sprich automatisierbaren Geschäftsregeln nachdenken:
1. Was sind die Vorteile von Business Rules, die ein zusätzliches Investment rechtfertigen?
2. Warum sollte man nicht nur die Regeln codieren?
3. Werden die Regeln verlässlich funktionieren und vor allem sich reibungslos in das System integrieren lassen?
Was Regeln und Entscheidungen zusammenhält und was sie unterscheidet, ist eine oft gestellte Frage, wenn Sowatec zum Thema Business Rules Management berät: Was unterscheidet sie eigentlich genau und welche Abhängigkeiten sind am Werk.
Grundsätzlich lassen sich zu Entscheidungen und ihren Bedingungen drei wesentliche Aussagen treffen.
Entscheidungen sind von den Prozessen, Systemen bzw. Events strikt zu unterschieden d. h. sie müssen getrennt betrachtet werden. Erst dadurch ist erste ihre Identifizierung und damit Verwaltung möglich.
Regeln, die für Entscheidungen nötig sind, werden in je nach Ziel bzw. Fokus orientierten Regel”gruppen” zusammengefasst.
Die Verwaltung eines Regelsets obliegt den Verantwortlichen für die Herkunft der jeweiligen Regeln (Legal, Marketing, Firmenpolitik etc.). Erst wenn Regeln sich ändern, hat das Auswirkungen auf zu treffende Entschedungen, nicht umgekehrt.
Regeln bzw. Business Rules sind also Bedingungen für das Decision Management und seine Werkzeuge, den Decision Services. Bei James Taylor habe ich einen recht guten Artikel zu Decision Services gefunden: Here’s how decisions and rules relate
Vergleichbar mit BPMS werden nicht alle Anwender diese komplexe Funktionalität eines BRMS in gleichem Umfang nutzen. Entscheiden für einen Einsatz eines komplexen Management von Geschäftsregeln ist die Komplexitiät der Regeln. Grundsätzlich entscheidend für den Einsatz von regelbasierten Prozessen ist ja immer noch, wieviele Prozesse automatisierte werden können/müssen, wie komplex diese Prozesse sind und wie “teuer” es ein Unternehmen kommt, diese Prozesse nicht zu automatisieren. Entscheidend für den Einsatz eines ausgewachsenen BRMS ist deshalb immer noch, wie schnell ein Unternehmen auf Veränderungen am Markt reagieren können muss, wie agil ein Unternehmen sein muss.
The success of Service-Oriented Architecture (SOA) has created the foundation for information
and service sharing across application and organizational boundaries. Through the use of SOA,
organizations are demanding solutions that provide vast scalability, increased reusability of
business services, and greater efficiency of computing resources. More importantly,
organizations need agile architectures that can adapt to rapidly changing business requirements
without the long development cycles that are typically associated with these efforts. Event-Driven
Architecture (EDA) has emerged to provide more sophisticated capabilities that address these
dynamic environments. EDA enables business agility by empowering software engineers with
complex processing techniques to develop substantial functionality in days or weeks rather than
months or years. As a result, EDA is positioned to enhance the business value of SOA.
The purpose of this white paper is to describe the approach employed to overcome the significant
technical challenges required to design a dynamic grid computing architecture for a US
government program. The program required optimization of the overall business process while
maximizing scalability to support dramatic increases in throughput. To realize this goal, an
architecture was developed to support the dynamic placement and removal of business services
across the enterprise.
Incanto can be implemented to solve the following kinds of decision making problems:
Problems where the expert rule set is large or complex. Incanto is especially suited to managing complexity.
Problems where the rules change frequently. Incanto`s testing capabilities mean amended rule sets can be introduced swiftly and with confidence.
Problems where the expert rules set needs to be applied to large volumes of data.
Where all these conditions apply Incanto is probably the only good answer in the market at present.
Multiple channels and types of events…
… executing in multiple Inference Agents (Event Processing Agents on an Event Processing Network)…
… where Events drive Production Rules with associated (shared) data…
… and event patterns (complex events) are derived from the simple events and also drive Production Rules via inferencing…
… to lead to “real-time” decisions.
For those of you that could not make it, I wanted to give you the gist of what I presented. This presentation covers the evolution of the business rules technology focusing first on the drivers that forced the market to shift its focus from Business Rules Engines (BRE) to Business Rules Management Systems (BRMS). In a nutshell, the main ideas are summarized below. In a few days, the recording will also be posted on our community site for your convenience.
Rob sees three key areas where rules can help:
Tighter warranty controls
Claims processing is improved because financial limits, detailed coverage types, materials return and more can be automated and rapidly changed when necessary. The rules also allow “what-if” testing and impact analysis.
Better built vehicles
The decision making is tracked very closely thanks to rules so you can analyze specific repair types, specific VINs and so on. More effective parts return and generally better information also contribute.
Lower cost repairs
Rules allow goodwill repairs, labor-only repairs and specific kinds of repairs to be managed very precisely. Rules-driven decisioning can reduce the variation of costs between dealers and help intervene, rejecting or editing claims that seem overly expensive. The ability of rules to deploy data mining and predictive analytics can also really help here.
JT has posted his view on rules and decisions and how they relate. Given that James talks more about services than events, I thought it would be worth reviewing his post from both a Complex Event Processing and a TIBCO BusinessEvents event processing platform perspective.
”Decision Services:
Support business processes by making the business decisions that allow a process to continue.
Support event processing systems by adding business decisions to event correlation decisions (they are often called Decision Agents in this context).
Allow crucial and high-maintenance parts of legacy enterprise applications to be externalized for reuse and agility.
Can be plugged into a variety of systems using Enterprise Service Bus approaches.”
Jess/CLIPS rule set to demonstrate the use of Bayes' theorem in handling dependencies between uncertain beliefs. This rule set uses a very simple scenario in which a number of jars hold combinations of black and white jelly beans. As the test progresses, jars are randomly selected, and beans are removed. The rule set processes a sequence of these bean draw events. Before each draw, the system uses Bayes' theorem to determine the probability of a black or a white bean being drawn from specific jars. The program answers questions in the form of "if the next bean drawn is black, what is the probability that it will be drawn from jar 3"?
M. zur Muehlen, M. Indulska, und K. Kittel. 19th Australasian Conference on Information Systems (ACIS 2008), Christchurch, New Zealand, Australasian Computer Society, (2008)
J. Schiefer, S. Rozsnyai, C. Rauscher, und G. Saurer. DEBS '07: Proceedings of the 2007 inaugural international conference on Distributed event-based systems, Seite 198--205. New York, NY, USA, ACM, (2007)
M. zur Muehlen, M. Indulska, und G. Kamp. EDOCW '07: Proceedings of the 2007 Eleventh International IEEE EDOC Conference Workshop, Seite 189--196. Washington, DC, USA, IEEE Computer Society, (2007)