• the bulk of revenues and all the growth was in pre-configured Decision Management applications
• FICO score revenues were half as much, w/ B2B growing as B2C (myFICO) waned
• tools revenues were less than half again as much and flat
  • optimization (XPress) was up
  • Blaze Advisor was down

This is in sharp contrast to the success that Ilog has enjoyed under the IBM umbrella.

Blaze Advisor doesn’t seem to make sense as a stand-alone tool any more.   Applications are great, and so are combinations of BI/optimization/rules, but if the BRMS tool will survive independently it needs to find more traction, perhaps outside of Fair Isaac.

the innovative Decision Graph visual metaphor, a decision tree management solution that makes even the most complex rule sets easier to manage and explain

Of course, a decision tree is really more like a root system (i.e., the tree is upside down).  So, what this capability is particularly good for explaining how some pretty structured logic gets wherever it lands up, which FICO touts:

The new capability is especially valuable to businesses that need to be able to explain their decision logic to external auditors and regulators, or to internal parties such as senior management.

Unfortunately, this capability is only good for business logic that has been heavily analyzed and transformed from more natural forms of knowledge that stakeholders and regulators understand or communicate about.

FICO’s suggestion is that after operational guidelines and regulations have been laboriously translated (literally and, hopefully, appropriately) into if-then-else logic (i.e., decision trees) that viewing the path through the “code” will be informative to stakeholders and suitable for regulators.  That seems like quite a stretch given the immediately following sentence, which indicates the complexity of using the metaphor in the first place:

Decision Graph gives business analysts a more intuitive way to view and navigate decision trees, which can reach 10,000 nodes or more.

Lots of people are attracted to such “visual programming” metaphors, but they are extremely limited in their logical expressiveness and, therefore, in their utility.  Still, if you are using induction technology (such as FICO’s)  to produce very large decision trees (independent of governing policies or regulations) such a tool can be useful, if only to understand what the machine “discovered” or to explain “how” it reached a decision, albeit post facto, which may or may not be compliant with governing doctrine.

The press release also talks about using this structure to experiment or optimize certain decisions by simulation, which is good stuff.  FICO has long led in this area, especially in the markets it focuses on (i.e., B2C financial).  This would have been a better central point, imo.

Overall, I agree with the following quote embedded within the release:

“Business rules management provides a shared platform for CIOs and business managers to help their enterprises stay competitive, and making business logic clearer to all parties is an essential part of that collaboration,” said Jim Sinur, a vice president at Gartner Research specializing in business rules management systems. “Better visualization of business logic can provide a huge uplift for companies that are looking for ways to improve business decisions.”

Showing thousands of nodes in a tree or cells in a table does not accomplish the appropriate goal (i.e., effective collaboration) of the first clause, however.  And Jim did not say that decision trees provide effective visualization.

My take: the best approach is to guarantee that the statements of business policy and regulation are unambiguously understood by machine intelligence that automatically translates them into completely reliable systems.

That is, the best visualization for general purposes may be plain English.

I don’t know of any video that is particularly good from an executive overview standpoint concerning “business rules” or even “decision management” let alone “management of active knowledge”.    My recommendation is to clarify the objective before drilling into “business rules”, which is a technical perspective.  What is it that you are trying to accomplish?  Most abstractly, it could be to manage and improve performance of an activity or an organization.  That kind of answer or focus is the right place to start and then work backwards to the technical approach rather than start with an inadequately conceived technical need.  This is one of the major problems with business rules as an independent market or product line.

Learning from Enterprise Decision Management

While at Fair Isaac, James Taylor saw this clearly.  He articulated the enterprise decision management (EDM) and positioned the business rules capability Fair Isaac acquired with Blaze Software in that space.  That is, more as a strategic objective than as a tool or technology.  This is an example of the proper way to think about business rules.

The decision management perspective was also narrowly focused on point decision making (e.g., using rules) but James and others (e.g., John Lucker of Deloitte) have appropriately expanded the strategy of decision management to include analytics, which produce and inform decision making (i.e., business rules), into a continuous process not of point decision making, but more closed-loop, continuous process improvement.  Over recent years, this has evolved into the broader market of performance management, which also includes performance optimization.

The key thing to consider when considering inquiries about “the applications and market for business rules” is the applications of knowledge.  The “knowledge engineering” community is often too focused on the sources of knowledge.  Focusing on sources rather than opportunities and benefits is a big part of why the business rules market has been subsumed into the business process management market, which is small in comparison to the business intelligence market, the fastest growing segment of which is performance management.

Semantic enterprise performance optimization checklist:

Here’s a checklist to consider when framing your considerations of strategies and tactics that might involve business rules technology:

1. What knowledge (including policies, regulations, objectives, goals) is involved?
2. What knowledge is superficial (i.e., derived from or approximations of) versus deeper knowledge?
3. Will you capture the motivation for a decision rather than how that decision is made using rules?
4. How will the performance  of your decision management or governance system be evaluated?
5. Is the knowledge involved in evaluating such performance part of the knowledge that you will capture and management?
6. How does the manner of evaluation relate to goals and objectives and over what time frames?
7. Is the knowledge about goals and objectives time frames part of the knowledge to be managed?
8. Are your decisions rigidly governed in every aspect or do you need the business process to include experimentation and optimization?

Most business rules efforts are focused on contexts so narrow that they are reduced to technical buying criteria without much or any consideration of the above.  That is, most business rule efforts do not even cover point 1 above.  Few reach bullet 2 and only strategic thinkers get to the third.

Specific recommendations for the naive question:

So I went off looking for videos…  You can find some on technical matters involving IBM/Ilog but I didn’t find any good videos from IBM at the business strategy level which concerned knowledge-based process/decision management/governance, which surprised.

A video from the vendors of Visual Rules touches on many of the traditional buying points that IT people typically formulate before evaluating vendors (here).

Although it did not respond to the inquiry, I sent along this video of James’ since it touches on so many of the aspects beyond business rules that are increasingly in vogue, even if it does not go far enough towards things like the business motivation model and the market for performance management, imo.

And for a very thorough background in the form of an analyst presentation that is consistent with all of the above, John Rymer of Forrester is most thorough in the two longer presentations that are here and there.

Please send me any other content that you would recommend!

Paul

• 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.

Every language has three kinds of statements: questions, statements, and commands.   There are also some peripheral types, such as exclamations (Yikes!), but in business processes and decisions only declarative and imperative sentences matter. 

From a process- or decision-oriented perspective, decisions are always phrased as imperative sentences.  Otherwise, the statements reflected in any business process, whether you are using BPMN or a BRMS, are declarative sentences.

Decisions are imperative sentences because they state an action to be taken.  For example, decline a loan or offer a discount.  It’s really pretty simple.  A decision is an action.  Rules that don’t take actions are statements of truth.  Such declarative statements of truth are perfect for formal logic, logic programming, and semantic technologies.  It’s the action that requires the production rule technology that dominates the market for and applications of rules.

The authors of the aforementioned article use the following diagram to explain the benefits of the decision-oriented approach in simplifying business processes:

The impact is very simple.  If you eliminate how you reach decisions from the flow that you diagram in BPMN things get simpler.  It’s really as simple as realizing that you have removed all the “if” parts (i.e., the antecedents) of the rule logic from the flow chart. 

So who in their right mind would use a business process tool to express any business logic?

For the astute reader, this glosses over the need for decisions to have fairly global access to the data underlying (i.e., required in order to make) decisions.  The separation of models and data between BPMS and BRMS should be avoided to address this.  SOA helps, but there are important details (e.g., stateless?)  [We've also written elsewhere here (how's that for an oxymoron?) about the need for decisions to understand context, both with regard to the state of the business process or events that trigger processes.]

But wait, there’s more!  Where did the business process we’re looking at on the right come from?  Where is it documented (or enforced!) that a loan should not be approved without first checking credit?  Is there any path to approving a loan for which checking credit is not a prerequisite?  Who drew this graph?  How do we know it’s right?  [I've written elsewhere about the need for governance of business processes, of which this is the simplest form of example.]

Are you getting the picture?  Business process diagramming is still programming, visual as it may be.  This pigeon-holing of rules technology is wrong.  Raising the understanding of decisions as central is important, even critical.  But thinking that knowledge must be expressed as rules that coallesce complexity into boxes tied with bows within in pretty diagrams is naive.  The right perspective is that both the flow chart and the logic are driven by the knowledge captured about the organization and its operational and governing policies. 

Most people would agree that if-then rules are technical tools.  Many would agree that BPM tools are best left in the hands of IT.  More are realizing that each should be driven more by knowledge about business and constrained less by the shallower by still steep waterfall relationship between the executive suite and technologists.

Decision management is important but it is only a piece of the pie.  Knowledge management – not the 90s notion of content management but knowledge that is curated and understood rigorously enough to generate and govern process and decision diagrams and logic, respectively – is where the strategic CIO needs to aim.

Here is the slide that triggered the controversy:

The point of this slide was to show how the current “state of the art” in business rules forces users away from managing knowledge and into coding with “if-then” structure.  Carlos argued in favor of situating knowledge in what he characterized as “the higher level business process”.  I maintain that software should be able to figure out where knowledge is relevant and put it there in the proper manner.  That is, the various “if-then” statements that can be derived from a more natural and expressive logical statement should be derived by machine.  Otherwise, the sales pitch that BRMS are accessible and usable by non-technical people is not only wrong, but potentially misleading.  That is, I think that knowledge is higher-level than flow-charts, although Carlos sees things in the other order.  Neither one of us denies the other, but I am comfortable that the higher ambition is to empower non-programmers with knowledge management that drives automation rather than to provide automation that limits the codification of knowledge to technical personnel. 

Carlos presented 4 bullet points in his post.  I think these were triggered by the following slide:

The last of these bullets relates to comments above and the first few to the perception that BPM is more important than CEP.  Overal, these are addressing the ignorance of most decision making applications of rules with regard to the current event or state of a business process in which the are embedded.  It is clear that Carlos and I are in agreement that this is an important architectural aspect of succeeding with the three technologies.

I agree with Carlos’ first two bullets concerning the need for events and state of processes to be accessible to logical and policy-based knowledge.  His third bullet, however, exposes one of the deep challenges facing convergence of business rules, processes, and events.  In this bullet Carlos implies that rules are for decision management only.  He misses that knowledge, which is higher level than rules, may define or govern the process itself.   I would like to emphasize here, however, that we agree on the need for a representation of events, state, and processes to be shared across the event, process, rule technology stack. 

Unfortunately, Carlos reiterates the Fair Isaac mantra that events are not core to process or the stack, citing colleague Carole-Ann Matignon, but are peripheral to rules for decisions in the hands of knowledge workers and BPM “tools” in whoever’s hands.

This is a problem with the BRMS and BPM industries as a whole and one that I hope Progress, if not TIBCO, drive home commercially this year.  Carlos says, in line with his other thinking, that “a process is not an event”.   This is consistent because if processes are events then Fair Isaac’s position would be inconsistent and untenable. 

As he wrapped up, Carlos said “and, definitely, processes are not events”, presumably in response to this slide:

Here is my take on the title of Carlos’ post:  Events and semantics.

An event is something that happens.  The big bang was an event.  The civil war was an event.  The swearing in of President Obama was an event.  The beginning of this day was an event.  Does anyone disagree at this point?

OK, if you didn’t disagree… Is the occurrence of a war is an event?  Is the swearing in of a president an event?  Is the beginning of the occurrence of something an event?  The answer is yes, of course!

Is war a process?  Is swearing in a process?  Yes.  Is the beginning of an occurrence a process?  Well, it depends if you are referring to the instant of time at which something begins or the process by which it begins.  If you are referring to an instant of time, as in the start of something (rather than its starting), then you are referring to an event but not a process.  That is, processes take some time.

In fact, processes are events that take time.  If it helps, you can always throw the word “occurrence” in front of “process” to distinguish the instances of processes from their types, as in the distinctions between abstractions and realities, concepts or classes or sets and instances or members.

But the fact remains, processes are events.

We’ve written several times about the artificial distinction between CEP and BPM, their inevitable convergence, and the immature integration of business rules with business process management and event processing that inhibits knowledge-driven governance and decisioning.

We predict that IBM will soon abandon its hair-splitting between business event processing and complex event processing and make a deeper move in the CEP space than its partnerships with Coral8/Aleri and Streambase (we don’t see IBM’s acquisition of AptSoft as addressing the need).  It will also be interesting to see how closely IBM integrates Ilog with its BPM middleware and the Lombardi applications.  Unfortunately, Progress is unlikely to pressure IBM or advance the knowledge-driven enterprise to the extent that a move by Oracle, SAP, or TIBCO could.  And, although they each have some position with regard to rules, conversations with Oracle, SAP and TIBCO continue to indicate incremental approaches without any bold vision for knowledge-driven enterprises where IBM owns the vision and thought leadership.

To date, IBM and SAP have similar messaging of their primary rule-based tools with respect to their middleware platforms.  That is, Ilog is positioned with respect to WebSphere as YASU is positioned with respect to NetWeaver.  Of course, Ilog is the stronger product.  IBM also has better marketing, both in WebSphere versus NetWeaver and Ilog versus SAP’s now non-descript rules engine.  To put it another way, SAP almost ignores policy and decision management.

It is worth noting that SAP uses a second-generation decision-oriented scripting language called “Business Rules Framework” within many of its applications.  SAP is working on relating this pervasively applied, internally developed, procedural tool with its acquired rules engine.  I don’t see much to indicate that SAP will take an effective position versus IBM or Oracle in middleware decisioning, however.  Still, they seem aware of the need to formulate their strategy.  Perhaps we’ll see something in 2010.

Oracle clearly lags IBM in middleware decisioning and suffers from a convergence challenge among its Haley, Ruleburst, and JESS rules engines that are used in its CRM, public sector, and middleware offerings.  However, Oracle is well ahead of SAP in its decisioning capabilities, both within its applications and in its next generation of Fusion and Fusion-based applications.

But IBM, Oracle and SAP seem out of the CEP picture.  So now we have Progress promising the most robust platform for events, processes and rules.  Unfortunately, Progress/Savvion will not be as accessible as IBM or Oracle offerings.  That is, IBM and Oracle, by way of their acquisitions of Ilog and Haley, are much better suited for policy and decision management.

We have written previously that robust business process management must address event processing and that event-driven business processes tend to have many fairly simple processes that are triggered and orchestrated by events and rules.  Tools that ineffectively require users to map policies and rules into flow charts (including almost all CEP and BPM platforms) fail to raise business management from the procedural to the knowledge-driven enterprise.

The CEP vendors, including Progress, TIBCO, Coral8/Aleri, and Streambase, need to consider the analyst-accessible, linguistically-oriented approaches of IBM and Oracle in order to cross the same chasm that business rules vendors crossed last decade.  The same remains true for BPM vendors, although it is nice to see that Progress has selected one that takes rule integration seriously.  IBM is clearly on the move and Oracle is best positioned to respond, but they lack events capabilities, both in their platform/stack and in their knowledge management capabilities.

Of the CEP vendors, TIBCO is best positioned because it has rules and BPM capabilities now.  It will be interesting to see if Coral8/Aleri or Streambase make any moves towards accessibility and business process management in 2010.  IBM is clearly dictating this is the game this decade.

1. Reasoning at a point within a [business] process
2. Reasoning about events that occur over time.
3. Reasoning about a [business] process (as in deciding what comes next)
4. Reasoning about and across different states (as in planning)

Enterprise decision management (EDM) addresses the first.  Complex event processing (CEP) is concerned with the second.  In theory, EDM could address the third but it does not in practice.  This third item includes  the issue of governing and defining workflow or event-driven business processes rather than point decisions within such business processes. 

Business applications of rules have not advanced to include the fourth item.  That is to say, business has yet to significantly leverage reasoning or problem solving techniques that are common in artificial intelligence.  For example, artificially intelligent question and answer systems, which are being developed for  the semantic web,  can do more than retrieve data – they perform inference.  Commercial database and business intelligence queries are typically much less intelligent, which presents a number of opportunities that I don’t want to go into here but would happy to discuss with interested parties.  The point here is that business does not use reasoning much at all, let alone to search across the potential ramifications of alternative decisions or courses of action before making or taking one.  Think of playing chess or a soccer-playing robot planning how to advance the ball on goal.  Why shouldn’t business strategies or tactical business decisions benefit from a little simulated look-ahead along with a lot of inference and evaluation?

Even though I have recently become more interested in the fourth of these areas, I expect the audience at the business rules forum to be most interested in the first two points above.  There will also be some who have enough experience with complex business processes, which are common in larger enterprises.  These folks will be interested in the third item.  Only the most advanced applications, such as in biochemical process planning, will be interested in the fourth.  I don’t expect many of them to attend!

The notion of enterprise decision management (EDM) is focused on point decision making within a business process.  For enterprises that are concerned with governing business processes, a model of the process itself must be available to the business rules that govern its operation.  I’ve written elsewhere about the need for an ontology of events and processes in order to effectively integrate business process management (BPM) with business rules.  Here, and in the workshop, I intend to get a little more specific about the requirements, what is lacking in current standards and offerings, and what we’re trying to do about it.

As I’ve written previously, the distinction between business process management (BPM) and CEP is not well principled but arises from somewhat arbitrary, historically distinct emphases on technology and market segmentation.  Any modern business process system must handle events and discussing events processing without considering processes is a limiting perspective.

Most people would intuitively agree that events trigger business processes.  For example, a business receiving a payment or a letter from a customer or vendor is an event that triggers the process of crediting and depositing that payment or considering and responding to that letter  Hopefully, we are moving beyond academic arguments about the distinction.  (I am ignoring here the algorithmic applications of streaming event processing as in trading in the capital markets.)

So, in current BPM, which should include CEP capabilities, we want decision management that is less ignorant about where it is in a business process and that is aware of events that trigger processing.  That is, we want policies that talk about the state of a business process and the occurrence of events.  The surprising thing is that current business rules management systems (BRMS) and related standards are of no help.  Tools from the leading business rule management system (BRMS) vendors, including Oracle and IBM / Ilog, have no intrinsic understanding of processes, events, or time.  And, outside their integrated BRMS, tools from BPM vendors don’t let us “talk” about anything.  They help us structure flows and code, but they rely on integrated BRMS to manage rules.  The rules include the policies, in which the business “talks”.  The BRMS is where English sentences (or something that increasing looks like English) are managed as the enterprise repository of policy. 

Note that there is nothing special about English.  It’s just easier to read than “natural language”.  Another limitation of current policy management systems is their lack of language independence, which requires automatic translation, which is much simpler if the sentences are unambiguously interpreted with logical rigor, but I digress from the point of this missive…

Some examples will help here.  Suppose we check the credit of an applicant at various points within the collection of processes that constitute how our enterprise conducts business.  We might have policies that are concerned with how we consider or act based on credit information in originating a loan (or policy) versus in renewing  or re-pricing one.  In effect, our policies want to talk not just about evaluating credit or pricing risk, but to do so in the context of a larger business process.  To be more specific, business policies that sound like, “if evaluating credit in the course of pricing a renewal…” or “if evaluating credit while considering a new policy…” are quite natural.  These statements define or govern the business process.  They also talk about where the decision is being made within a business process.  

• BRMS need to understand the context of the business process in order to make context-sensitive decisions.
• BPM needs to tell the BRMS what it is going on from the top-down for the BRMS to understand the context of a decision.

So, we need the BRMS to be told things like:

• I am considering a new applicant.
• I am considering the renewal of a contract.

In these statements, the pronoun “I” is the overall enterprise system contemplating its own actions.  If you find that awkward, just substitute “while”  to obtain what you might “say” in a business policy.  Ideally, the language your policy management system would not be overly stilted but would understand any of:

• while considering…
• during consideration of …
• if considering…
• if an … is being considered for…

and so on.  Otherwise, users will find authoring such statements cumbersome.  Reading and understanding English, even if it is a bit stilted, is easy for people.  We’re built to communicate, after all.

Now consider what you would want to say if you were writing policies that involved events.  In this case, the event has already occurred, such as “we received a letter from a customer…”.  You do not want to say, “if I am receiving a letter from a customer…” (which could only be true for an instant that passes quickly unless it was stated as “… I will be receiving…”).  But if we can only refer to events in past tense, how do we talk about a current event that needs to be handled versus another event that we have already handled?

Many business to consumer (B2C) applications, such as pharmacy benefits have this problem, for example.  To a pharmacy benefit manager (PBM), like Medco or Express Scripts, the swiping of an insurance card at a retail pharmacy is an event to be processed.  Any individual beneficiary has a history of such requests.  We can try to model the current one as a request and the prior ones as transactions, but this becomes awkward for less formal or technical people who want to talk about how many requests someone has submitted over a period of time, for example.  The truth is that there is a history of requests per beneficiary and technical limitations should not obscure this fact.  We should be able to distinguish the current request from prior requests, as in the following:

• a request that has not been processed is current or pending
• if processing a request…
• if a request for … is being considered…

Note that “request” is a deverbal noun, which is to say that the root form is the verb (in this case “to request”).  A request is a reference to an act of requesting that may be in any tense.  The sentences above reflect this in the use of an additional verb that carries the tense.  Of course, this is all completely natural since every sentence has a verb.

The most dangerous expression might be:

• if … requests …

and yet this is the form that almost all BRMS would handle today!  This is dangerous because it is too ambiguous about when the request occurred.  It would be better to say:

• when … requests …

provided that the system understands that, unlike “if”, “when” involves time, but even “when” is less than ideal since an event has always occurred in the past by the time it is processed.  On the other hand, we might define when a request occurs as in:

• a request occurs from the time it is received until it receives a final response.

This assumes that “when” combined with a verb in present perfect tense means during the period of time in which the process referenced by the verb continues.  And this is an important point:

• An event can be an occurrence of a process.
• An event may have a duration.
• “When” may refer to an interval of time.

Events are not necessarily processes, but may refer to instantaneous points in time, such as in the following:

• When a request is received…
• When the processing of a request begins…

but these uses of “when” refer to a point in time before any action can be taken in response to the event, therefore the sentences should only conclude with statements of implied, necessary, or modal logic and should not include any statement of action. Of course, a competent BPM/CEP/BRMS would understand all this and advise the author of a policy that suggests taking action in the past.

As we proceed through these examples our intuition should be building the understanding of the first three points made above.  Processes and events and reasoning about or over time are completely intertwined in nature and separating them between BPM and CEP and BRMS systems is completely artificial and hopelessly limiting.

So what is the solution?  I suggest it is a knowledge management  system that understands the following:

• 1. Policies that use tense.
• 2. Policies that refer to events using deverbal nouns.
• 3. Policies that refer to occurrences of processes as events.
• 4. Policies that refer to potential action using future tense, possibly by way of modals.
• 5. Policies that refer to occurrences of processes using verbs such as “begin”, “end”, “start”, etc.
• 6. Policies that refer to occurrences of process using words like “during”, “while” and “when”
• 7. Policies that refer to events using prepositions like “by”, “before”, “after”, and “when”

The natural language technology to parse such sentences is widely available using many approaches.  I am happy to discuss that with interested parties.  The second step that needs to be addressed is transforming the logical interpretation of such sentences derived from the natural language system into the underlying execution architecture, which includes a process engine and a rules engine that must be appropriately integrated.  That integration involves the informing of the BRMS about the state of the business process and the actions that may be taken which may be expressed as processes in the BPMS.  I’ve written elsewhere about this in more detail and am also happy to discuss it in more detail with BPM or CEP practitioners, product managers and architects.

Understanding events and occurrences of processes as events adds a great deal of power to policy management.  It allows statements of policy to reference and consider the context of business processes.  It allows statements of policy to reference and consider how to handle events in the context of business processes.  And, if it is done with adequate natural language understanding, it accomplishes this integration of BPM and CEP within a single policy management system.

Although I had hoped to cover the fourth point made first above here, I now prefer to conclude with a brief discussion about reasoning over time.  I will strive to cover reasoning about potential states of a process another day.  It is interesting but rigorous material that requires (in my opinion) architectural support that is lacking from current rules engines, whether production rule or logically based, even if the situational or event calculi are good formalisms.

Reasoning over time is pervasive in CEP.  In the pharmacy benefits management domain, for example, coverage is commonly limited based on the history of transactions.  For example, a policy might limit the amount of refills over a period of time.  This involves aggregation over a number of events, each of which is the result of handling a prior request.

Very few knowledge or policy management systems understand that transactions are processes, occurrences of which can be viewed as events.  For example, is “order” an noun or a verb in your enterprise applications?  Our technology has biased us to thinking about objects, which drives our modeling towards nouns and away from verbs.  Our technology biases us against modeling events and processes well!  And it shows up, insidiously sapping productivity and accessibility.

The lack of ontology of process and event in current BRMS not only precludes the kind of integrated BPM and CEP I am discussing here, it also limits the ability of current BRMS to automate policies that consider what has happened in making decisions in the present.  For example, a statement like:

• if a medicine has a maximum therapeutic dosage over a period that is less than the total dosage of that medicine requested by a member over the same period then…

is beyond the capabilities of current offerings.  Authority understood some grammar about time but did not understand that events, such as a request, occurred in any deep sense.  So it could automate a sentence like:

• if the total dosage of a medicine requested by a member on a date within the last 90 days exceeds the maximum quarterly therapeutic quarterly dosage for the medicine then…

but understanding why it understands one sentence and not the other is too much for many authors to tolerate, let  alone understand.  The essential reason is that we sold the company before extending Authority’s ontology to include events and revising its parser to understand that both verbs and their deverbal nouns referred to events (including occurences of processes).

The bottom line here is that a quantum leap in natural language processing of business rules is needed.  Fortunately, this is not a quantum leap for natural language processing itself.  It is well-established that sentences are parsed into representations of events in which noun phrases play semantic roles, such as the following:

• agent or counteragent
• donor or beneficiary
• patient or “experiencer”
• causer
• instrument
• locative or time
• source or destination

where quite a few prepositions relate to more refined aspects of time and location, such as at, on, during, by, before, after, in and so on.   The critical thing for processes and events is that they occur in time.

Realizing this quantum leap in policy management and knowledge automation is really pretty simple.  Take an approach such as Authority and extend its core, upper ontology with the semantic roles and the concepts of events and processes.  Then extend its relation-centric parsing with even-centric parsing (both are needed).  A few more steps, notably handling metonymy, and the next generation of knowledge management and automation that provides the integrated understanding of time, events, and processes discussed here becomes a reality.

That’s what we’re patiently working towards.  And we’re doing it in as engine-independent a manner as practical so that we can leverage standards like RIF and SBVR.  It’s all about the knowledge.

Finally, we are looking for collaborators who would like to learn more or help, and, perhaps, get involved in leveraging the solution or its underlying technology.

By no means is this a book about SBVR.  Rather, it is about the core and critical concepts necessary to understand how  to define an enterprise repository of declarative knowledge covering business.  The unfortunately reality is that the work necessarily suffers from legacy concepts and perspectives, but this is a statement of fact and practicality rather than a negative assessment.  Essentially, my problem with much of the increasingly mainstream marketing and practicing of business rules is precisely the term “rule”.  Nonetheless, since the mainstream audience is pre-occupied with the word “rules” rather than the word “knowledge”, Ron’s book is – again – right on the money for practitioners who want to achieve the benefits of separating models and knowledge from implementations in order to increase the agility of systems and more closely align IT with business needs (all of which he discusses in Chapters 2 and 3).

This edition clearly benefits from the progress in the field and reflects current enterprise objectives that have progressed into the mainstream since Ron began practicing and writing many years ago.  Veterans will quickly recognize and benefit from the simple clarity that Ron brings to the subject.

The critical topics that Ron addresses are the core concepts underlying modeling and linguistics that allow non-technical business analysts (even, perhaps, subject matter experts) to capture unambiguous statements of business definitions, requirements, policies and other “rules” in English sentences that are suitable for presentation to and verification by stakeholders.  In addition, in the event knowledge-level standards like SBVR evolve and are adopted by technology (e.g., business rule) vendors, managing such statements will directly impact the operational behavior of business processes, especially where they involve automated decisions, policy enforcement and other forms of governance requiring enforcement.

Although Ron and I have come to a shared view on knowledge capture and management, we have followed different paths.  Ron’s concern is primarily capture.  Mine extends to and necessarily emphasizes implementation and execution.  Nonetheless, our perspectives on modeling and capture are extremely aligned.  Ron’s writing on what he calls “terms” and “wordings” are right on the money.

We have independently arrived at a point where we believe that linguistic expression of business knowledge is much more important (and valuable) than rule-based expressions suitable for execution by rule engines.  In effect, Ron argues and I agree that the knowledge is much more important, durable, and valuable than its executable form or expression.  As a result, I could not more emphatically introduce Ron’s coverage of how to express models and logic in English.

By the end of Chapter 1, Ron defines what he calls a vocabulary and why  managing  vocabulary is a requirement for managing business knowledge (including definitions, requirements, and policies).   Ron’s writing on nouns and verbs and how they form the backbone of expression for business knowledge is seminal and accessible to novice and expert practitioner alike.

As more or an artificial intelligence practitioner, I might quibble with the omissions of mass nouns, such as money or time, from his discussion, but these topics will not be missed by anyone but the most forward-looking strategist.   Similarly, the limitation of current standards to wordings involving verbs eliminates coverage of adjectival phrases and results in too many wordings involving the verb “has”, at least in my opinion.  For example, wordings like “a person has an age” seem arcane, perhaps technical, to me.  Nonetheless, even though my work supports such “phrasings”, most of its users still use “has” phrasings!  Perhaps this is because I have not taken the time and expended the effort to clarify the concepts that Ron covers so well.  In short, Ron’s writing is right on target for practitioners given the current state of the art (and standards).  And I can think of no other expert or author who has reduced current practice to such an accessible form.

Chapter 4 clearly explains and motivates the use of sentences as the independent units of business knowledge.  Ron does a good job of introducing the notion of roles as the components linked together within predicates using verbs.  This is fairly abstract material, so I don’t blame him for avoiding too much depth on the semantics of roles.  Fortunately, other materials, such as the SBVR standard itself, cover these details in greater depth.  So again, the content seems right on for someone entering the field and focused on linguistic modeling, capture and management rather than more formal “semantics”. 

Ron clearly separates statements defining and relating concepts from requirements.  Not only does he present the material linguistically, he reinforces it with clear graphical presentations of the corresponding models.   Personally, I prefer to mix certain requirements with definitions, as in “a person has exactly one mother”,  but this would complicate the graphical presentations.  He also addresses common linguistics, such as passive voice and using verbs (i.e., participles) as adjectives, which I have found to be important concepts that must be brought to practitioners’ attention.  Otherwise, the models become unnecessarily complex or the resulting sentences seem cumbersome, if not stilted.

In places the formality of SBVR shows through.  For example, “a person must not lease a vehicle the person owns”.  This reflects linguistic limitations of available tools.  This phrasing reflects “necessity” within the underlying logical formalism of SBVR.  In addition, the reiteration of “the person” begs for natural language processing that would understand pronouns, such as “(s)he”.  Having said that, this is clearly a higher level statement than can currently be understood and implement by most business rule management systems (BRMS), however.  As such, it demonstrates the power of Ron’s approach and motivates (given most commercial offerings) the separation of capture and management of business knowledge from its expression in business process management systems (BPMS) or BRMS.

Having encountered the notion of logical necessity in the preceding example, it is worth pointing to Ron’s discussion in Chapter 10.  Externalizing business knowledge from systems requires certain architectures for information systems.  For example, the prohibition of a person leasing a vehicle that (s)he owns requires some action not stated here.  In effect,  a violation of requirements must be anticipated in the runtime architecture.  There are various approaches to this, including runtime exceptions.   Ron demonstrates this approach in Chapter 10 and, if the system incorporates workflow for resolution, he advocates using the end-user accessible form of business knowledge for explanation (in his discussion of guidance within Chapter 2).  More advanced approaches, such as meta-reasoning, and detailed architectural approaches are appropriately left out of this work on capture and management.

Interestingly, in Chapter 7, Ron suggests that business rules should not be expressed within an if-then syntax.  Obviously, this clearly separates Ron’s methodology from the production rule focus of most commercial BRMS.  It also exposes a gap between SBVR and operational systems.  Ron discusses behavioral rules within the chapter but the gap between requirement and behavior remains unfilled.  This is my most significant concern for the logical approach to knowledge management.   Without a framework by which declarative knowledge can bridge to imperative action, the logical approach falls short of operational relevance.  This is reflected, in my practical viewpoint, by the lack of operational deployment of SBVR. 

The principal  challenge remaining for SBVR is to cross the gap from expression into operation.  Aside from linguistic limitations, this is my primary concern for the formal logic approach to knowledge capture and management.   The ideas Ron covers so well are necessary for long-term success in automating managed knowledge, but they are not enough.   Unfortunately, most of the business rule vendors do not adequately address the necessary capabilities that Ron’s methodology and toolsets handle.  This leaves us with a continuing need for business rule engineers to bridge the gap, manually.

The FICO score is not a probability. 

Fair Isaac people describe the FICO score as a ranking of creditworthiness.  And banks rely on the FICO score for pricing and qualification for mortgages.  The ratio of the loan to value is also critical, but for any two applicants seeking a loan with the same LTV, the one with the better FICO score is more likely to qualify and receive the better price.

Ideally, a bank’s pricing and qualification criteria would accurately reflect the likelihood of default.  The mortgage crisis demonstrates that their assessment, expressed with the FICO score, was wrong.  Their probabilities were off.

• Was the FICO score a useful metric of creditworthiness before the crisis but not during?
• Is the FICO score a reliable metric going forward?

In these mid-crunch days, Fair Isaac is reminding its customers that the FICO score is a ranking not a probability.  The underlying point they seek to make is that the relationship between the FICO score and the probability of default is more complex and dynamic than their banking customers understood last year.  (Another post on predictive analytics also discussed stationarity.)

It’s the probability that matters, not the score!

In his keynote, Ian Ayres also focused on the inadequacy of scores.

He was explicit that bankers need the probability of default and, further, that they need to know how reliable such probabilities are.  As an example, he cited polls where one candidate is leading by 6 points within a margin of error of 3 points as almost meaningless.  More meaningful would be the probability that the leading candidate will win.  Even better would be an estimate of the probability of default along with an assessment of the reliability or accuracy of that probability.

Bankers increasingly understand that the FICO score is not the probability of default that they need when originating and underwriting credit.  As a result, bankers increasingly understand that there is no adequate external source of the probabilities they need in order to optimize their portfolio performance. 

This realization has several ramifications:

• A market opportunity for predictive analytics in credit has opened on Fair Isaac’s turf.
• Scorecards have lost much of their “solutions” luster, becoming just another technique.

But several things also became clear as I talked with numerous practitioners last week.  Fair Isaac doesn’t have much competition.  In fact, it is shocking how little competition they have in such a large and lucrative market. 

What decisioning market?

Although there is a market opportunity for more rigorous decisioning solutions, there is no significant challenger to Fair Isaac.  I expected to hear more about the Experian Group, but the only direct competitor identified by more than one person was Austin Logistics.  Several people indicated that they were using statistical tools directly, especially SAS, and Fair Isaac itself is placing a great deal of emphasis on its own predictive analytic tools, especially Model Builder.

Note that Vantage Score is really having an impact on Fair Isaac scoring revenues, as reflected in their most recent earnings call transcript.  So there is more competition than may seem apparent to the audience that attends Interact.

Another chasm to cross

Generally speaking, this market needs the benefits of broader machine learning techniques, such as statistics, and a more rigorous understanding and emphasis on probabilities.  The audience, however, is not technically sophisticated enough to become aggressive adopters, despite recent harsh lessons.  In the same panel, every banker in turn solicited risk analysts to join their organizations, headquartered in Asia-Pacific, London, Canada, and on the west coast.  They also agreed that it is easier to learn finance than analytics.

The market for analytics is crowded with sophisticated tools and intellectually demanding techniques that are simply too hard for most people to understand and use, let alone to use effectively and reliably.  This is precisely the circumstances that decision management was in during the late nineties when business rules technology started going mainstream.  In 2000, we crossed that chasm by introducing natural language business rules (see Haley’s Authority).  At the same time, Blaze Advisor, now owned by Fair Isaac, was crossing that chasm using a form based approach called “Innovator”.

Similar advances will be forthcoming in analytics.  As with business rules, this will not eliminate the need for highly skilled consultants, but their criticality and marginal value will diminish as analytics becomes more effective in the hands of non-experts (and as better solutions develop in key markets, such as in credit, risk, fraud and other criminality or terrorism).

Until it’s easy, use expertise

If you are in this market and could use some help with modeling, analytics, or adaptive decision management, feel free to get in touch.  We have some excellent capabilities and partners in these areas.  We are happy to help recommend approaches or products, or simply to make referrals.  Of course, there are also highly specialized consultancies, such as Strategy Analytics that can give excellent implementation-agnostic advice. 

One thing worth noting, but only in passing for now, is Fair Isaac’s acquisition of Dash Optimization.  This  reflects the increasing trend towards broader and deeper application of technology within credit decisioning.  it is also a response to the decline of scoring and the increasing need for decision optimization, which is a broader subject than decision management, with or without predictive analytics and adaptation. 

Nonetheless, optimizing portfolios will not optimize profits if the scores used are not reliably correlated with probabilities.

It is also interesting how Ilog and Fair Isaac continue to converge from a technological perspective.