Occasionally the business rules do not lie comfortably within the capabilities of the BRMS.

Using an ordinary scripting language is an alternative.

An example is of an institutional lender, wishing to check loan documents against a rule set derived from historical data and expert knowledge.

Typical rules are:

  • Polarity: Does the time-value assessment of the asset match the market for assets of the same type?
  • Contractual: Have phrases with legal implications been inserted into the documents?
  • Quality: Are any phrases in the document contrary to the quality assessments?
  • Assumptions: Have any assumptions been included in the documents?
  • Adjustments: Do adjustments match the quality assessments?
  • Transaction: Are the documents intended for the same purpose as the transaction?
  • History: Do the dates/values of the asset match available data?
  • Evaluation: Do various evaluation methods concur?

On examining the base documents, in addition to a normalized database, large amounts of data are extracted from an external XML (XPATH) source of deep structure, as well as a number of PDF documents from various sources.

A final requirement is to process in excess of 10,000 documents per hour, in a cloud-based environment, with output in PDF and spreadsheet formats.

In summary, there is a requirement for financial maths functions, natural language processing, fuzzy logic, time series processing, algorithms, as well as ordinary logic. The scale of the shortfall in functionality is easy to misjudge: note that many BRMS systems don’t offer, as standard, numerical rounding acceptable to financial institutions.

A Service Oriented Architecture (SOA) would be possible with various packages providing the desired rules and functionality, but the end result would be unlikely to perform well, necessitating a server farm.

The chosen alternative, to use a broad-based scripting language (PHP in this case) can be justified:

  • all the required functionality is available.
  • the end solution can be run on the desired platform and meet the performance goals.
  • the scripting tool can be ring-fenced with an SOA interface (SOAP and REST in this case)
  • the rulesets can be structured in much the same way as they would be in a BRMS.
  • much the same tools are available for managing the rulesets.

Of course, the discipline of a BRMS and the additional (especially graphical) features are not present.  Without the ruleflows of DROOLS or the decision trees of XpertRule a ruleset of more than a hundred rules can become difficult to manage.

The developers also have to restrict themselves to using simple structures so that the rules themselves remain clear: readability is the first priority. This means that REGEX patterns and Object Oriented patterns are forbidden and arrays are inadvisable unless absolutely clear.

Noting that most BRMS use some form of limited scripting (XpertRule:VBScript/Procs; DROOLS:Java; ILOG:OPL;), this is not a major departure.  The compartmentalization of scripts, and organisations of scripts into a visual structure is missing. (In this case, the sequence of the firing of the rulesets was not important, so greatly lessening the impact.)

The nett result was a successful implementation. It is worth noting that at least two previous attempts by different vendor’s teams had not succeeded, and, prior to this project, the object model was described specifically in a well known BRMS agile architecture guide as “unnecessarily complex” and “business users will typically reject it”. We think this sentiment is an expression of the limitation of the rules engine (DROOLS) rather than the wider view of a BRMS.

.