systems that know and understand and think and learn
Here is a graphic on how various reasoning technologies fit the practical requirements for reasoning discussed below:
This proved surprisingly controversial during correspondence with colleagues from the Vulcan work on SILK and its evolution at http://www.coherentknowledge.com.
The requirements that motivated this were the following: Continue reading “Requirements for Logical Reasoning”
Ron Ross was kind enough to send me a copy of his recently publishd 3rd edition of his book, Business Rule Concepts. Ron has been at the forefront of mainstreaming business rule capture for decades. Personally, I am most fond of his leadership in establishing the Object Management Group’s Semantics of Business Vocabulary and Rules standard (OMG’s SBVR). This book is an indispensible backgrounder and introduction to the concepts necessary to effectively manage business rules using this standard.
Does your business have logic that is more or less complicated than filing your taxes?
Most business logic is at least as complicated. But most business rule metaphors are not up to expressing tax regulations in a simple manner. Nonetheless, the tax regulations are full of great training material for learning how to analyze and capture business rules.
For example, consider the earned income credit (EIC) for federal income tax purposes in the United States. This tutorial uses the guide for 2003, which is available here. There is also a cheat sheet that attempts to simplify the matter, available here. (Or click on the pictures.)
What you will see here is typical of what business analysts do to clarify business requirements, policies, and logic. Nothing here is specific to rule-based programming. Continue reading “Harvesting business rules from the IRS”
James Taylor’s blog today on rules being core to BPM and SOA in which he discussed reuse had a particularly strong impact on me following a trip yesterday. During a meeting with the insurance and retail banking practice leaders at a large consulting firm, we looked for synnergies between applications related to investment and applications related to risk. Of course, during that conversation, we discussed whether operational rules could be usefully shared across these currently siloed areas, but we landed up discussing what they had in common in terms of business concepts, definitions, and fundamental truths or enterprise wide governance. It was clear to us that this was the most fruitful area to develop core, reusable knowledge assets.
In his post, James agrees with the Butler Group’s statement:
Possibly the most important aspect of a rules repository, certainly in respect of the stated promise of BPM, Service Oriented Architecture (SOA), and BRMS, is the ability for the developer to re-use rules within multiple process deployments.
I have several problems with this statement: Continue reading “Rules are not enough. Knowledge is core to reuse.”
A manager of an enterprise architecture group recently asked me how to train business analysts to elicit or harvest rules effectively. We talked for a bit about the similarities in skills between rules and requirements and agreed that analysts will fail to understand rules as they fail to understand requirements.
For example, just substitute rules in the historical distribution of requirements failures:[1]
Continue reading “Elicitation and Management of Rules, Requirements and Decisions”
I am working on some tutorial material for business analysts tasked with eliciting and harvesting rules using some commercial business rules management systems (BRMS). The knowledgeable consumers of this material intuitively agree that capturing business rules should be performed by business analysts who also capture requirements. They understand that the clarity of rules is just as critical to successful application of BRMS as the clarity of requirements is to “whirlpool” development.[1] But they are frustrated by the distinct training for requirements versus rules. They believe, and I agree, that unification of requirements and rules management is needed.
Consider these words from Forrester:
One might argue that Word documents, email, phone calls, and stakeholder meetings alone are adequate for managing rules. In fact, that is the methodology currently used for most projects in a large number of IT shops. However, this informal, ad hoc approach doesn’t ensure rigorous rules definition that is communicated and understood by all parties. More importantly, it doesn’t lend itself to managing the inevitable rules changes that will occur throughout the life of the project. The goal must be to embrace and manage change, not to prevent it. [2]
But note that Forrester used the word “requirements” everywhere I used “rules” above!
Both of the following statements are true, but the first is more informative:
First, dropping the word “production” before “rules” loses information. BRMS do not typically generate rules that are not production rules. Consider, for example, the BRMS vendors involved in the OMG effort produced the Production Rule Representation (PRR) standard. The obvious question is:
Second, dropping the words “based on the Rete Algorithm” loses information. The dominant rules vendors and open-source engines are all based on the Rete Algorithm.
Third, dropping the word “chaining” before “rules” loses information. Chaining refers to the sequential application of rules, as in a chain where each link is the application of one rule and links are tied together by their interaction. But:
Fourth, dropping the word “forward” before “chaining” loses information. Forward chaining reacts to information without requiring goals. This begs the question:
Continue reading “Missing Goals and Requirements in Business Rules”