Confusion about Services Based Architectures [SBA, SOA, EDA, ...] has been created by a number of industry elements. Industry critics like Forrester first used the term Services Based Architecture until 2000 when Gartner came up with their own term Services Oriented Architectures (SOA). Forrester was still using the term SBA in 2002. Gartner next created the term Event Driven Architecture and has now come full circle back to SOA 2.0 (supporting both SOA and EDA like the original SBA).
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
As IBM absorbs ILOG it will be important that it continue to invest is this multi-platform approach. Not only are there some nice features in the .Net product (that I for one would like to see available to the Java product) but decision management with business rules is, for most companies, a multi-platform problem. The value of using business rules to decision management comes in part from making sure the same rules are used everywhere they are supposed to be used. While deploying business rules in Decision Services on SOA makes this easier, the best solution is to allow the rules to be packaged up and deployed as Java components, Web Services, .Net assemblies or COBOL code so that they can run natively on all the platforms that run the business.
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.”
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.
Substitute a standard web services interface for a speaking tube, a business rules management system for his encyclopedic knowledge of policies and regulations, data mining or predictive analytics for his customer knowledge and adaptive control for his experimentation and you have Decision Management. The Answerer but on an industrial scale.