IBM Ilog JRules for business modeling and rule authoring

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.

Ilog would do well to improve this dialog with a means of specifying the inputs and decisions.  In this case, the only required input is an application and the sole output would be the score suggested for the application based on stability at work.  Note that this dialog does not even reflect that there is a score for stability at work in the business or decision model used by this application.  I think Fair Isaac would do better in this regard and IBM had better designs in the rules connector for WebSphere (before the Ilog acquisition).

With or Without Then

Although the video is situated within Ilog’s tabular metaphor, it demonstrates the typical Ilog rule authoring metaphor, which consists of two components: conditions and actions.  Not every rule system is limited to Ilog’s “if-then” functionality, but such production rules (as they are known by computer scientists) dominate the industry.  Production rules always have a “then”.

If you are interested in more expressiveness and logical power you might consider the “semantics of business vocabulary and rules” standard from the Object Management Group (SBVR from OMG) or the “rule interchange format” from the World-Wide Web Consortium (RIF from W3C), but not its impoverished “PRD” specification.  Generally, more linguistic approaches, as in SBVR or Haley/Ruleburst/Oracle Policy Automation do not constrain authors to express knowledge only within “if-then” constructs.

Programmers tend to underestimate how important this is, not only for functionality, but for usability, especially if the target authors, contributors, authorities, or subject matter experts do not think like computers.  For example, how many “if-then” statements are in “the outside back cover of each issue of the magazine must filled with a full-page color advertisement”?  Why force a business analyst, for example, to write down each possibility and lose track of the tree of knowledge from which the forest of rules springs?

Conditions

In the following screen, the author has selected the first column and used some invisible keystroke to bring up the “Condition Column” dialog shown below for column A:

There are all sorts of things to think about here.

1. Why is “request” or “result” in the list?
2. The model is clearly too simple for a realistic demonstration
   1. e.g., people, not just borrowers have age
   2. the amount of a request is actually the amount requested on an application
   3. an application may only have a single applicant (as  implied by the use of “the”)
3. The model suffers from an impoverished understanding of time
   1. the income of a borrower is limited to a single timeframe (e.g., not annually)
   2. the duration of employment is understood only as job seniority
      1. rules that reference days are not practical
      2. rules that reference years will be awkward
4. The interface would benefit from a better understanding of prepositional and possessive forms
   1. <a borrower>’s age, employment, income, or name would be grouped together
   2. <a request>’s amounts, applicant(s), property… would be grouped together
   3. people naturally think (and talk) this way
      1. e.g., a borrower requests an amount
      2. e.g., a request for an amount
      3. e.g., a property is assessed at an amount
5. More generally than just time, the product would benefit from an understanding of amounts
   1. the amount of a request is an amount of money
   2. a property is assessed at a monetary value as of some time

Leaving the deep issues is necessary to get through this commentary on the video, but before doing so, we should pause and contemplate how deeply these limitations will affect strategic  objectives.  For example, if the intent of the rules repository is to manage enterprise knowledge, is Ilog adequate?

Peccadilloes

The use of “request” here is particularly interesting.  What request is this talking about?

The truth is, it will take training and experience to comprehend.  This is a problem, obviously.

This would better be rendered “the request”.  Then one would ask “which request” and the answer would be that there is some request implicit in the context of these statements, which is indeed the case.  To go much further would be to probe the wound exposed here, but the interested reader might want to contemplate the difficulties of rendering this as “a request”.  That metaphor would fail!

More problematic here is the use of the word “result”.  The use of this word is fatal in my opinion.

Phrase or clause

Selecting the phrase “the applicant of a request” leads to the following screen, in which the author is selecting “request” as a substitution for “a request”:

This raises a few questions:

1. What does it mean to substitute “request” for “a request”?
2. Why is “is a borrower” appended after we selected “the applicant of a request”?

At a minimum, it would make more sense if the author substituted “the” for “a” before “request”.

One thing worth noting here is that there is no understanding.  For example:

1. that applications have applicants
2. that ‘request’ in this context is a synonym for ‘application’
3. that ‘request’ is a noun (or a verb!)
4. that every applicant has applied
5. that applications are produced by applicants applying
6. that applicants are not necessarily borrowers

Also note the feedback that the angle-bracketed placeholders need to be filled before the statement can be complete.  After selecting “request”, the following is presented:

Notice that the software things the statement is complete even though a placeholder is unfilled.

Concerning the two prior screens: the word “condition” above the sentence “The statement is complete” is superfluous in each case, but the sentence does not seem appropriate in either case.  In the first case, the sentence seems to be missing something with the angle brackets around “a borrower”.  In the second case, the sentence is not grammatical.  It seems that some determiner is needed before “employer” such as “the applicant’s” or “his/her”.  But I am still wondering what happened to “a borrower” and why it was inserted in the first place…

Tricks of the trade?

In the immediately preceding screen, note that the author has highlighted “is” and that the drop down includes various alternatives.  It is peculiar that with the exception of “is not”, replacing “is” with any of these would produce a non-grammatical sentence.  Also, there is clearly something awkward (or “clever”) about “is employer”.  I generally feel this way whenever the text is not grammatical.

There is something fishy here about this predicate.  It is a predicate since it is either true or false (as the video subsequently demonstrates) that an applicant is self employed.  Who is “employer”?  Apparently, in this model, an applicant has a single employer, as in “each applicant has an employer” rather than “each applicant may have some employers”.  Ideally, the system would understand that “each person may have more than one employer” and “a person who applies is an applicant”.  Nonetheless, under the limiting assumption that “each applicant has precisely one employer”, why doesn’t the text read “is employed by <a employer>”, where the employer could be further specified as the applicant?

Continuing on, around 1:12 into the video, it is disconcerting to see the software substitute “is employer” for “is a borrower”, as reflected in the following screen:

Here, the author is completing the dialog by giving the condition a title that will be displayed as the column header.

Almost text editing

I suspect that the actual model here has a limitation of one applicant per application and that applicants have a predicate which is true if the applicant is self-employed and that the author specified the text “employer” for when the predicate is true.  If so, the work to get this column defined is far too tedious.  If not, I would prefer that the effort for this column also educated the application as a whole that I could now talk about whether a person is self-employed.

If the author wanted to substitute “the applicant’s employer” for “a borrower”, why did the author select “is”?  Or, if the author selected “is not” from the list, would “a borrower” remain, as in “the applicant of a request is not a borrower” (which appears to be false by definition in this use of the software even though feasible pending approval of a person’s first or sole outstanding loan).  Clearly, there is a design flaw here, both in terms of user interaction and semantics.

Please note that Ilog is working fine.  It is getting the job done.  My point is that it is not semantic.  Semantic means meaning.  Ilog does not understand meaning.  It doesn’t understand.  It doesn’t have knowledge.  It edits text within a metaphor for authoring if-then rules.  As a rule-based programming tool, it is doing quite well.  For capturing, managing, leveraging, and automating knowledge, it is simply not even in the ballpark.

An amount of time

Moving on, the author selects the second column, somehow indicating that it is a condition column and popping up the dialog, which again informs us that it is for a condition, as shown below:

Here, the author is substituting “the applicant of a request” for “a borrower” in “the job seniority in months of a borrower is a number”.

This is better than the prior edit where only “is” was highlighted because the selection will precisely substitute for the highlighted text.  But there are other problems, mostly semantic but also functional.

The video suggests that only borrowers have job seniority.  If I were considering Ilog for a knowledge automation project, I would want to know if seniority could be defined, in general, of if I have to define the phrase “job seniority” instead of understanding that one’s seniority is proportional to the duration of their employment.  This is really a tip of the iceberg on the challenges facing text-chunk editing versus more semantic and natural language business modeling.

I will try not to quibble further with the phrase “the seniority of an employee” (which implicitly quibbles, I admit).  But the seniority of an employee is an amount of time.  Here, I am being forced to specify a number without units, such as years.  What if I wanted to compare someone’s seniority to his or her length of residence of age?  Do I have to model each of these using the same unit of time?  What if I want to consider these collectively as of some point in time?  The approach here suffers from all the problems of defining a database column that holds an integer.  There is no semantics or integrity.

If you watch the video you will see that the author has to select “a request” after selecting “the applicant of a request” and the select “request” to produce “the job seniority in months of the applicant of request”.  I would have preferred to say “the applicant’s seniority” by selecting “the applicant” in the first drop-down and “‘s seniority” from its cascaded (waterfall) menu.

Nonetheless, the result below is functionally adequate, as admitted above.

The column is given a header (which could have been “Applicant’s Seniority (in months)” but note that the statement is indicated as complete again, even though a prior screen had indicated that placeholders should be filled.  This is simply a peccadillo of the metaphor which wants a single placeholder to be unspecified.

Anticipation

The following screen shows that the author is anticipating rules that will specify ranges of a person’s tenure with the current employer.  That, is the author has conceived of a table with two columns in which a minimum and maximum may be specified.  This is a bit forward looking for many potential contributors, but Ilog has other alternatives that do not require such foresight.  (Actually, Ilog’s dual-column range functionality is better than prior generations of this metaphor from  Corticon or Haley/Oracle.)

Now this drop down can get pretty long, especially in more than a trivial example such as this, so perhaps Ilog might take a cue from Haley and cascade shared prefixes with waterfall menus, such as by having all the “is as” options cascade to the right, for example.  There are other user interface niceties and design challenges that have not been met here, too.  For example, why does <min> follow “least” in one place but not another?  And, should there be an adverb before between, such as “inclusively”, or not?  And why is “and” other than for “between”?  What if I want to say “is at least … and less than…”?  And what is this “null” thing all about?  And what is the difference between “is” and “equals” or “is not” and “does not equal”, if they are different?

All these questions raise serious issues that a well educated programmer and experienced Ilog user may not even think about.  But they will have an impact or who can use Ilog effectively and on reliability.  All the training in the world won’t keep users from confusing “is” or “equals”, whether or not they are the same, for example.  And “null” will cause problems, too, such as whether some is not something other than null if it is null. (I realize that reads poorly, but it is a precise demonstration of the issue.)

After selecting the highlighted choice, the following screen completes the column headings:

Note that the defaults here are at fault.  The subcolumns would much better be titled “at least” and “less than” since the maximum is excluded but the minimum is inclusive.

After completing this dialog the following shows the misleading range column headings as an action column is being defined:

I cringe at this English.  Make it a double!-)

First, the “set” before each of the attributes is an action, not a decision.  Second, it encourages people to think like programmers rather than logically.  It would be much better to change each “set the… to …” to “the… should be …”.

Second, the “make it <a boolean> that …” is terrible.  How about substituting “… should be <true or false>”?  Also, Boolean is capitalized in my dictionary.

I don’t want to touch “print <a string>” or “set <variable> to…”!

And only the indoctrinated know what to make of “<a result>”.

Moving on, the author selects “set the score of a result to a number”.  Most won’t know what it means to do this but here is what results:

Without further ado, the table definition is completed and “a rule” is authored, as shown below:

In this metaphor, rows correspond to rules.  In other metaphors, columns or even cells may complete rules.

Here, as cells are populated, the text control below the menu bar presents textual feedback on the corresponding condition or action with the rule.  Notice above that specifying false in the first column corresponds to “the applicant of request is employer”.  As discussed above, this would read much better as, “an applicant is not self-employed” or, more immediately from Ilog’s perspective, “an applicant of the application is not employer”.

Although the following shows a cell in the score column as highlight, the paraphrasing text concerns the two cells in the middle column:

As discussed above, I would prefer that this text read “no applicant has been with his or her current employer for at least 3 years”.  Changing the assumption that an application has only one applicant would cause all the author’s work to need re-engineering, however.  Nonetheless, as will become apparent in a moment, the model specifies job seniority as being a non-negative number, so the “at least zero” is uninformative (generally, amounts of time are not negative).  And with any understanding of units, Ilog could render this as “the seniority of the applicant of the request is less than 3 years”.

As the table is filled in, the limitations of the column labels becomes more apparent.  For example, which row does someone who is not self-employed fall if they have been with the same employer for 36 months?

Ilog does a nice job merging the range columns to cover at least 6 months, as shown in the cascading pop-up menu above and the resulting screen below:

Ilog also does a nice job identifying that not all situations are covered by the table as shown by the comment on gaps and the functionality of inserting the missing value(s) in a column:

So the author continues specifying the rules for the self-employed, as reflected below:

The video also shows the insertion of multiple rows in the second column for each cell in the first column. Ilog’s ability to insert (and collapse) these structures gives it the ability to present such tables as trees and corresponding trees as tables, which is appealing to some users.  Overall, I like Ilog’s layout functionality more than other vendors’ decision table metaphors (although I am aware of approaches that are yet to be commercialized that I like even better).

As we have seen above, and as shown below, Ilog emphasizes (perhaps even relies upon)  the rendering of text to clarify the meaning of its decision tables.

Here, a paraphrase for the entire rule in the row that holds the cursor (over the row number) is displayed as text.  Although this could be expressed more tersely (and perspicuously), it is fine for a technical analyst.  Non-technical people, including many business analysts, would be through off by the lack of “the” before “request”, “employer”, and “result”, but the most significant questions are what it means to “set” and what the meaning or utility of the referenced “result” is.  Most would also appreciate dropping the semicolon and “all of the following conditions are true”, its following colon and the bullets in favor of a simple “and”.

To sum it up, I like Ilog’s decision table metaphor and its supporting functionality, but Ilog does not address linguistics or semantics to an adequate degree for managing and automating requirements, policies, and other knowledge.  As I have written elsewhere, I hope IBM addresses these shortcomings in pursuit of a holistic offerings to enable increasingly knowledge-based enterprises.  As it does so it will also need to address the logical weaknesses of current business rule engines,  but understanding knowledge is a prerequisite for automation, even if only through forward chaining.