Going on 5 years ago, I wrote part 1. Now, finally, it’s time for the rest of the story.
This is not all that simple of an article, but it walks you through, from start to finish, how we get from English to logic. In particular, it shows how English sentences can be directly translated into formal logic for use with in automated reasoning with theorem provers, logic programs as simple as Prolog, and even into production rule systems.
There is a section in the middle that is a bit technical about the relationship between full logic and more limited systems (e.g., Prolog or production rule systems). You don’t have to appreciate the details, but we include them to avoid the impression of hand-waving
The examples here are trivial. You can find many and more complex examples throughout Automata’s web site.
Consider the sentence, “A cell has a nucleus.”:
FICO reported 9% growth in revenues year over year.
- the bulk of revenues and all the growth was in pre-configured Decision Management applications
- FICO score revenues were half as much, w/ B2B growing as B2C (myFICO) waned
- tools revenues were less than half again as much and flat
- optimization (XPress) was up
- Blaze Advisor was down
This is in sharp contrast to the success that Ilog has enjoyed under the IBM umbrella.
Blaze Advisor doesn’t seem to make sense as a stand-alone tool any more. Applications are great, and so are combinations of BI/optimization/rules, but if the BRMS tool will survive independently it needs to find more traction, perhaps outside of Fair Isaac.
Fair Isaac’s recent press release touts the “key differentiator” of Blaze Advisor 7.0 as:
the innovative Decision Graph visual metaphor, a decision tree management solution that makes even the most complex rule sets easier to manage and explain
Of course, a decision tree is really more like a root system (i.e., the tree is upside down). So, what this capability is particularly good for explaining how some pretty structured logic gets wherever it lands up, which FICO touts:
The new capability is especially valuable to businesses that need to be able to explain their decision logic to external auditors and regulators, or to internal parties such as senior management.
Unfortunately, this capability is only good for business logic that has been heavily analyzed and transformed from more natural forms of knowledge that stakeholders and regulators understand or communicate about.
FICO’s suggestion is that after operational guidelines and regulations have been laboriously translated (literally and, hopefully, appropriately) into if-then-else logic (i.e., decision trees) that viewing the path through the “code” will be informative to stakeholders and suitable for regulators. That seems like quite a stretch given the immediately following sentence, which indicates the complexity of using the metaphor in the first place:
Decision Graph gives business analysts a more intuitive way to view and navigate decision trees, which can reach 10,000 nodes or more.
Lots of people are attracted to such “visual programming” metaphors, but they are extremely limited in their logical expressiveness and, therefore, in their utility. Still, if you are using induction technology (such as FICO’s) to produce very large decision trees (independent of governing policies or regulations) such a tool can be useful, if only to understand what the machine “discovered” or to explain “how” it reached a decision, albeit post facto, which may or may not be compliant with governing doctrine.
The press release also talks about using this structure to experiment or optimize certain decisions by simulation, which is good stuff. FICO has long led in this area, especially in the markets it focuses on (i.e., B2C financial). This would have been a better central point, imo.
Overall, I agree with the following quote embedded within the release:
“Business rules management provides a shared platform for CIOs and business managers to help their enterprises stay competitive, and making business logic clearer to all parties is an essential part of that collaboration,” said Jim Sinur, a vice president at Gartner Research specializing in business rules management systems. “Better visualization of business logic can provide a huge uplift for companies that are looking for ways to improve business decisions.”
Showing thousands of nodes in a tree or cells in a table does not accomplish the appropriate goal (i.e., effective collaboration) of the first clause, however. And Jim did not say that decision trees provide effective visualization.
My take: the best approach is to guarantee that the statements of business policy and regulation are unambiguously understood by machine intelligence that automatically translates them into completely reliable systems.
That is, the best visualization for general purposes may be plain English.
I was just asked for some background on business rules and the major players, preferably in the form of videos. The request came in by email, so I didn’t have the opportunity to immediately ask “why”. Below I give some specific and direct responses, but first a few thoughts about clarifying objectives.
I don’t know of any video that is particularly good from an executive overview standpoint concerning “business rules” or even “decision management” let alone “management of active knowledge”. My recommendation is to clarify the objective before drilling into “business rules”, which is a technical perspective. What is it that you are trying to accomplish? Most abstractly, it could be to manage and improve performance of an activity or an organization. That kind of answer or focus is the right place to start and then work backwards to the technical approach rather than start with an inadequately conceived technical need. This is one of the major problems with business rules as an independent market or product line.
Learning from Enterprise Decision Management
While at Fair Isaac, James Taylor saw this clearly. He articulated the enterprise decision management (EDM) and positioned the business rules capability Fair Isaac acquired with Blaze Software in that space. That is, more as a strategic objective than as a tool or technology. This is an example of the proper way to think about business rules.
The decision management perspective was also narrowly focused on point decision making (e.g., using rules) but James and others (e.g., John Lucker of Deloitte) have appropriately expanded the strategy of decision management to include analytics, which produce and inform decision making (i.e., business rules), into a continuous process not of point decision making, but more closed-loop, continuous process improvement. Over recent years, this has evolved into the broader market of performance management, which also includes performance optimization.
The key thing to consider when considering inquiries about “the applications and market for business rules” is the applications of knowledge. The “knowledge engineering” community is often too focused on the sources of knowledge. Focusing on sources rather than opportunities and benefits is a big part of why the business rules market has been subsumed into the business process management market, which is small in comparison to the business intelligence market, the fastest growing segment of which is performance management.
Semantic enterprise performance optimization checklist:
Here’s a checklist to consider when framing your considerations of strategies and tactics that might involve business rules technology:
- What knowledge (including policies, regulations, objectives, goals) is involved?
- What knowledge is superficial (i.e., derived from or approximations of) versus deeper knowledge?
- Will you capture the motivation for a decision rather than how that decision is made using rules?
- How will the performance of your decision management or governance system be evaluated?
- Is the knowledge involved in evaluating such performance part of the knowledge that you will capture and management?
- How does the manner of evaluation relate to goals and objectives and over what time frames?
- Is the knowledge about goals and objectives time frames part of the knowledge to be managed?
- Are your decisions rigidly governed in every aspect or do you need the business process to include experimentation and optimization?
Most business rules efforts are focused on contexts so narrow that they are reduced to technical buying criteria without much or any consideration of the above. That is, most business rule efforts do not even cover point 1 above. Few reach bullet 2 and only strategic thinkers get to the third.
Specific recommendations for the naive question:
So I went off looking for videos… You can find some on technical matters involving IBM/Ilog but I didn’t find any good videos from IBM at the business strategy level which concerned knowledge-based process/decision management/governance, which surprised.
A video from the vendors of Visual Rules touches on many of the traditional buying points that IT people typically formulate before evaluating vendors (here).
Although it did not respond to the inquiry, I sent along this video of James’ since it touches on so many of the aspects beyond business rules that are increasingly in vogue, even if it does not go far enough towards things like the business motivation model and the market for performance management, imo.
And for a very thorough background in the form of an analyst presentation that is consistent with all of the above, John Rymer of Forrester is most thorough in the two longer presentations that are here and there.
Please send me any other content that you would recommend!
If you are considering the use of any of the following business rules management systems (BRMS):
- IBM Ilog JRules
- Red Hat JBoss Rules
- Fair Isaac Blaze Advisor
- Oracle Policy Automation (i.e., Haley in Siebel, PeopleSoft, etc.)
- Oracle Business Rules (i.e., a derivative of JESS in Fusion)
you can learn a lot by carefully examining this video on decisions using scoring in Ilog. (The video is also worth considering with respect to Corticon since it authors and renders conditions, actions, and if-then rules within a table format.)
This article is a detailed walk through that stands completely independently of the video (I recommend skipping the first 50 seconds and watching for 3 minutes or so). You will find detailed commentary and insights here, sometimes fairly critical but in places complimentary. JRules is a mature and successful product. (This is not to say to a CIO that it is an appropriate or low risk alternative, however. I would hold on that assessment pending an understanding of strategy.)
The video starts by creating a decision table using this dialog:
Note that the decision reached by the resulting table is labeled but not defined, nor is the information needed to consult the table specified. As it turns out, this table will take an action rather than make a decision. As we will see it will “set the score of result to a number”. As we will also see, it references an application. Given an application, it follows references to related concepts, such as borrowers (which it errantly considers synonomous with applicants), concerning which it further pursues employment information.
The folks from Knowledge Partners have a post that I found thanks to Sandy Kemsley, whose blog often provides good pointers. This article talks about the decision perspective on business rules. It makes some good points, on which I would like to elaborate albeit at a more semantic or knowledge-level.
Every language has three kinds of statements: questions, statements, and commands. There are also some peripheral types, such as exclamations (Yikes!), but in business processes and decisions only declarative and imperative sentences matter.
From a process- or decision-oriented perspective, decisions are always phrased as imperative sentences. Otherwise, the statements reflected in any business process, whether you are using BPMN or a BRMS, are declarative sentences.
Decisions are imperative sentences because they state an action to be taken. For example, decline a loan or offer a discount. It’s really pretty simple. A decision is an action. Rules that don’t take actions are statements of truth. Such declarative statements of truth are perfect for formal logic, logic programming, and semantic technologies. It’s the action that requires the production rule technology that dominates the market for and applications of rules.
The authors of the aforementioned article use the following diagram to explain the benefits of the decision-oriented approach in simplifying business processes:
The impact is very simple. If you eliminate how you reach decisions from the flow that you diagram in BPMN things get simpler. It’s really as simple as realizing that you have removed all the “if” parts (i.e., the antecedents) of the rule logic from the flow chart.
So who in their right mind would use a business process tool to express any business logic? Continue reading “What could be more strategic than process or decision management?”
Today, I came upon some commentary by a business rule colleague, Carlos Serranos-Morales, of Fair Isaac concerning a presentation I made at the Business Rules Forum. During the presentation I showed some sentences that are beyond the current state of the art in the business rules industry. Generally speaking, these were logical statements that did not use the word “if”. (Note, however, that many of the them could be expressed in SBVR, OMG’s semantics of business vocabulary and rules standard). Carlos argued that such statements should be more precisely articulated within the specific context of a business process.
Here is the slide that triggered the controversy:
Externalizing enterprise decision management using service-oriented architecture orchestrated by business process management makes increases agility and allows continuous performance improvement, but…
How do you implement the rules of EDM in an SOA decision service? Continue reading “Agile decision services without XML details”
TIBCO is the CEP vendor most focused on the market for business rules, as reflected in Paul Vincent’s post here. Although I agree with Paul that rule vendors are not currently offering enough in terms of support for long-running processes, the conclusions that he draws in favor of considering a CEP alternative to a BRMS are not compelling yet.
Paul said that rules don’t address the following that are addressed by CEP:
- BAM (business activity monitoring) and the other BPM (business performance management)
- Complex-rule processing
- Customer-centric (portfolio-based) decisions / policies
I am sure Paul was just being flippant, but you may notice that there is a bit of a war going on between CEP, BPM and rules right now. Continue reading “Behind the CEP curtain – it’s about time, not the cache”