BibSonomy ::  user :: cschie ::

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.

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.

There are obvious benefits in making business policies/rules explicit and easily changed via accompanying quick-change processes. The apparent benefits revolve around faster reaction to competitors and markets, as well as quick response to management and collaborative tuning. There are more subtle opportunities to get ahead of the game and anticipate customer demand, thus creating the ability to generate incremental revenue streams that play off of increased demands. Customers may also be enabled to make changes to their individual processes as they interact with an organization. CRM efforts are struggling to have a differentiating customer experience. BPM with explicit rules will allow this experience to evolve and become individualized.

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

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.

Unlike traditional BI, an operational BI system should be focused on influencing the interaction with your customer to provide benefit to both the customer and your business. Traditional BI, while often seen as a tool with a very fuzzy ROI, is nonetheless necessary for conducting business. Operational BI, on the other hand, provides a much clearer benefit because it directly addresses your business.

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.

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.

In diesem Buch werden alle relevanten modernen Standards der Geschäftsprozessanalyse und -modellierung miteinander verbunden und ihre praktische Handhabung dargestellt. Kern des Buches ist eine Geschäftsprozess-Methodik, die die verschiedenen Standards in praxisrelevanter und harmonischer Weise verbindet. Sie erfahren, welche Standards es gibt, wofür und wie diese eingesetzt werden können und welche Möglichkeiten aber auch möglichen Einschränkungen in der Praxis damit verbunden sind. Basis sind die BPMN (Business Process Modeling Notation), OSM (...), BMM (...), SBVR (..) und UML (...) - wobei diese Standards zielgerichtet nur soweit behandelt werden, wie es für die Auseinandersetzung mit Geschäftsprozessen notwendig ist. Sie erfahren wie Strategien, Geschäftsregeln und  Geschäftsprozesse dargestellt werden können und welche Strukturierungsmöglichkeiten es für Unternehmensarchitekten es gibt. Das Buch richtet sich an Business-Analysten, Prozessdesigner, Betriebsorganisatoren und verwandte Rollen.

Let’s start by recapping decisions services. Decision services are services, generally stateless ones, that answer business questions for other services. Decision Services typically have no side effects so they can be called whenever they are needed without the caller worrying that something will change in the system. This means that database updates, event generation or other actions taken as a result of the decision are taken by the caller not by the Decision Service. This is not 100% true but works as a general rule. To work, Decision Services need to contain all the logic and algorithms necessary to make the decision correctly.