One of the major advantages of a BRMS is the speed to market: the change-test-implement cycle is typically much shorter than the standard sprint or change-window cycle.
As an example, one enterprise (8000+ staff) has had over 3000 releases over the 10 year life span of their rules engine: that figure includes releases that do not make it through testing, so production releases are roughly weekly, much faster than their standard change windows that are at best monthly, and sometimes six monthly.
To realise this speed, some architectural challenges have to be tackled. Consider the following scenario:
A telecom has offered a new product with a major media launch to the public. A misprint in the “Careless” magazine has left those customers with the impression the first year is free. The telecom has decided to honour the misprint, but only for those customers who submit the “Careless” magazine coupon.
The rules for this requirement are, on face value, easy to add, and might look like:
if careless_coupon_submitted = True and careless_coupon_date < 12 months old then product_price = 0
However, the requirement extends further into the architecture: the careless_coupon_submitted and careless_coupon_date are not on the database, nor on the “add-product” screen, that the call-centres use.
Despite the BRMS speed, the telecom will need to interrupt other development and testing, and use an emergency change window to implement the database and screen changes.
The following architecture overcomes these limitation, and make the BRMS more responsive to change:
- Introduce a definition file for the rulebase-screen-database architecture.
- Allow the definition file to add new database entities/attributes “on the fly”, within strict guidelines.
- Allow the definition file to add the capture of new “ad hoc” data items on screens.
RDF is useful for definition files, which can be processed automatically. In this case, it might look like:
(format: subject/predicate/object)
rulebase/is called/careless year rulebase/starts on/1 jan 2016 rulebase/documented in/business.doc rulebase/approvedby/business person rulebase/selectable on/screen rulebase/selectable as/screen control (eg checkbox) rulebase/selection enabled by/ruleset 99991 rulebase/applies to/selection criteria (eg. types of user....) rulebase/validated by/ ruleset 99992 rulebase/calculated by/ruleset 99993 rulebase question/<non qualifying question> eg. has circumstance zzz/ -questionchoice "disqualifier" <note the RDF minus sign in the above> rulebase question/<qualifying question> eg. has circumstance yyy/ -questionchoice "a qualifier"
Adding database items “on the fly” does run counter to many architectural principles (e.g. TOGAF 2.3.4.1), and with good reason. We recommend that the “on the fly” items be rationalised by the database team as soon after the implementation as is practical. This is especially important with EAV implementations because of the practical difficulties posed for developers and those preparing “self-service” reports.
To use EAV to add DB items on the fly, the definitions typically look like:
entity/attribute/value[datatype]
Customer.Product.Event /careless_coupon_submitted /[boolean] Customer.Product.Event /careless_coupon_date /[date]
For some organisations using “reserved for future use” entities/attributes is a more acceptable alternative to EAV.
.