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.
Elicitation and Management of Rules, Requirements and Decisions
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]
- 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
Continue reading “Elicitation and Management of Rules, Requirements and Decisions”
When Rules Meet Requirements
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!
Missing Goals and Requirements in Business Rules
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[1] 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:
- Don’t goals matter?
Continue reading “Missing Goals and Requirements in Business Rules”
Business Rules Process Management
Some strategy folks in an enterprise architecture group recently asked for help making rules more relevant to their organization. Their concerns ranged from when to embed rules in their middle tier versus encapsulate them within services to identifying ideal use cases and reference implementations. They were specifically interested in coupling rules with BPM and BI.
Such questions occur every time a group or enterprise considers adopting rules technology for more than a specific application. They are looking for guidelines, blueprints, or patterns that will help them disseminate understanding about when and how to use rules. They have adopted a BPM vendor which will be integrated with their selected rule vendor, each as enterprise standards, so they are particularly interested in the integration requirements between the two.
Two high level understandings are critical for success in furthering adoption of rules technology.
- abstract activities for which rules technology well-suited and
- when and why rules technology is better than familiar alternatives