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: (more…)
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:
- 34% Incorrect requirements
- 24% Inadequate requirements
- 22% Ambiguous requirements
- 9% Inconsistent requirements
- 4% Poor scoping of requirements
- 4% Transcription errors in requirements
- 3% New or changing requirements
Both of the following statements are true, but the first is more informative:
- Business Rules Management Systems (BRMS) typically produce forward chaining production rules that are interpreted by a business rules engine (BRE) based on the Rete Algorithm.
- BRMS typically generate rules that are interpreted by a BRE.
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:
- What is different about production rules?
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.
- Why does the Rete Algorithm matter?
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:
- Why does chaining matter?
Fourth, dropping the word “forward” before “chaining” loses information. Forward chaining reacts to information without requiring goals. This begs the question: