Marketing at Coherent Knowledge suggests this Dilbert for those with compliance challenges!
Logic from the English of Science, Government, and Business
Our software is translating even long and complicated sentences from regulations to textbooks into formal logic (i.e,, not necessarily first-order logic, but more general predicate calculus). As you can see below, we can translate this understanding into various logical formalisms including defeasible first-order logic, which we are applying in Vulcan’s Project Halo. This includes classical first-order logic and related standards such as RIF or SBVR, as well as building or extending an ontology or description logic (e.g., OWL-DL).
We’re excited about these capabilities in various applications, such as in advancing science and education at Vulcan and formally understanding, analyzing and automating policy and regulations in enterprises.
-
English translated into predicate calculus
English translated into predicate calculus
-
-
an unambiguously, formally understood sentence
an unambiguously, formally understood sentence
-
-
English translated into SILK and Prolog
English translated into SILK and Prolog
Pursuing a decision tree down a rat hole
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.
Event-centric BPM and goal-driven processing
The slides for my Business Rules Forum presentation on event semantics and focusing on events in order to simplify process definition and to facilitate more robust governance and compliance are at Event-centric BPM.
After the talk I spoke with Jan Verbeek and Gartjan Grijzen of Be Informed and reviewed their software, which is excellent. They have been quite successful with various government agencies in applying the event-centric methodology to produce goal-driven processing. Their approach is elegant and effective. It clearly demonstrates the merits of an event-centric approach and the power that emerges from understanding event-dependencies. Also, it is very semantic, ontological, and logic-programming oriented in its approach (e.g., they use OWL and a backward-chaining inference engine).
They do not have the top-down knowledge management approach that I advocate nor do they provide the logical verification of governing policies and compliance (i.e., using theorem provers) that I mention in the talk (see Guido Governatori‘s 2010 publications and Travis Breaux‘s research at CMU, for example) but theirs is the best commercially deployed work in separating business process description from procedural implementation that comes to mind. (Note that Ed Barkmeyer of NIST reports some use of SBVR descriptions of manufacturing processes with theorem provers. Some in automotive and aerospace industries have been interested in this approach for quality purposes, too.)
BeInformed is now expanding into the United States with the assistance of Mills Davis and others. Their software is definitely worth consideration and, in my opinion, is more elegant and effective than the generic BPMN approach.
What could be more strategic than process or decision management?
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?”
Agile decision services without XML details
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”
Externalization of rules and SOA is important – for now
James Taylor’s notes on his lunch with Sandy Carter of IBM and the CEO of Ilog prompted me to write this. Part of the conversation concerned the appeal of SOA and rules to business users. Speaking as a former vendor, we all want business people to appreciate our technology. We earn more if they do. They say to IT “we want SOA” or “we want rules” and our sale not only becomes easier, it becomes more valuable. So we try to convince the business that they are service-oriented, so they should use SOA. Or we tell the business that they have (and make) rules, so they should use (and manage their own) rules. And rules advocates embrace and enhance the SOA value proposition saying that combined, you get the best of both worlds. This is almost precisely the decision management appeal. Externalize your decisions as services and externalize rules from those services for increased agility in decision making. This is an accurate and appropriate perspective for point decision making. But it doesn’t cover the bigger picture that strategic business people consider, which includes governance and compliance.
Nonetheless,
Effective SOA and business rules have one requirement (or benefit) in common: externalization.
The externalization of services from applications Continue reading “Externalization of rules and SOA is important – for now”
CEP crossing the chasm into BPM by way of BRMS
Complex event processing (CEP) software handles many low-level events to recognize a high-level event that triggers a business process. Since many business processes do not consider low-level data events, BPM may not seem to need event processing. On the other hand, event processing would not be relevant at all if it did not occasionally trigger a business process or decision. In other words, it appears that:
- CEP requires BPM but
- BPM does not require CEP
The first point is market limiting for CEP vendors. Fortunately for CEP vendors, however, most BPM does require event-processing, however complex. In fact, event processing is perhaps the greatest weakness of current BPM systems (BPMS) and business rules management systems (BRMS), as discussed further below. Continue reading “CEP crossing the chasm into BPM by way of BRMS”