W3C – Commercial Intelligence

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.

Continue reading “IBM Ilog JRules for business modeling and rule authoring”

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!

Continue reading “When Rules Meet Requirements”