This article originally appeared on the BeyeNETWORK.
In my previous article, Simple Business Rules for Business Intelligence, we began exploring a relatively
IF (precondition) THEN (positive action) ELSE (negative action)
Using this rule framework, we also started to develop a conceptual hierarchy for representing the activation of policy in order to help create an audit trail for validation of data within the context of the business processes:
Policy (the original guiding statement)
Simple business rule (reformulated into assertions)
IF-THEN-ELSE (formal statement in standardized form)
Actionable form (IF-THEN-ELSE with actual data object references)
The next step in developing this framework is to focus our attention a little more closely on the structure of the rule format itself. Basically, we need the details regarding the precondition and the positive and negative actions associated with the rule.
In this month’s article, we are going to examine the precondition, which represents an evaluation of some logical expression associated with the current state of the system. For our purposes, the system state is embodied by the collection of all static data sets plus all potential transactions that may modify those data sets. For example, in an order system, the state may consist of the customer, sales, order detail, payment and fulfillment tables along with pending sales transactions that may modify those tables.
In turn, our actions (both positive and negative) represent modifications to the state. To continue the order example, updating the sales and order detail tables with the information from a sales order is a positive action that may be triggered once the precondition is evaluated to be true. Rejecting the sale if the precondition is false would be the corresponding negative action.
The precondition must reflect a relationship to the data elements within the system state, or else there would not be an effective method to connect the stated rule to its expected behavior. The precondition must specifically refer to the data elements being evaluated, and that implies a dependency on metadata. While at the policy level we can be a bit cavalier about the precision of the terms, in order to make the rule actionable, we need to be precise in our reference. As an example, we might only allow “known customers” to place orders:
IF (the individual placing the order is a “known customer”) THEN (“make the sale”) ELSE (“reject the sale”)
At a policy level this is sufficient. However, to actualize this as an operational condition, we must define individual placing the order and known customer, both at the business level and at the data level. At the business level, a known customer might be an individual with whom we have an associated purchase account linked to a unique customer identification number.
At the data level, the system receives a pending sales transaction in a single record (or XML message or other method), with one field containing a customer’s name. Within the system state, there is a customer table used to manage all individuals that have one or more associated purchasing accounts, and one of the attributes in the table is the customer’s name. The precondition is now intended to evaluate whether the customer named in the pending sales transaction matches a customer name in the customer table. By referring directly to the data instance and its attributes, we can state the precondition in a more formulaic manner:
IF (there exists a record in CUSTOMER such that CUSTOMER.NAME == TRANSACTION.CUSTOMER_NAME) …
The general approach is to express the precondition being tested as a logical expression dependent solely on the “allowed” mathematic operations applied to specific data instance attributes. The set of allowed operations is defined within the system, but a good starting set contains standard Boolean operators: equal ( = ), greater than ( > ), greater than or equal to ( >= ), less than ( < ), less than or equal to (<= ), not equal to ( != ). In addition, we should include standard set operations (e.g., union, intersection, “contained in”) and the arithmetic operators too, for good measure (+, -, *, /). We might also include some set aggregate functions, such as SUM, AVERAGE, etc. Others may be added as they are approved within the rules development framework. We are going to transform the statement of policy into a formal expression that can be fed into a rules engine, and the process to do this refinement, using our operators, is straightforward:
- Identify the data elements referred to within the precondition and determine whether each is
associated with an attribute of a known data set (e.g., a table), an “unaffiliated” data instance
(e.g., an XML message or a pending update record), or a systemic data element (e.g., a processing
variable such as “number of records processed”).
- For each data set element, modify the reference to a dotted notation specifying the data set
name, followed by a dot ( . ), followed by the attribute name. For example, the name field in the
customer table would be changed to CUSTOMER.NAME.
- All “unaffiliated” instances referring to the same operation stream can essentially be
considered to belong together. Assign a name to the data set; then, a reference to an instance
element may also be modified to a dotted notation. For example, the pending sales transactions all
roll up into the set TRANSACTION, and the customer name element is modified to
- Identify the arithmetic and logical operators within the precondition that relate data elements to each other and replace the language with the corresponding operators. For example, if a known customer is one for which we have assigned at least one account and a unique identifier in the customer table, then testing for a known customer means checking to see if an individual has a record in the customer data set. This is a set membership keyed off the customer name, and we reflect that using the key words “…there exists a record in…”
Does this sound simple? Yes. Does this always work? Of course not! The problem is that in most environments, the policy conditions are, for the most part, stated without much degree of precision, which blocks the successive refinement of the statement into a formal expression. While this may introduce some frustration at the beginning of the process, it does present the opportunity to identify common business terms that can benefit from standardization. Once the definitions and semantics have been resolved, the rule refinement process should go smoothly.
In future articles, we will explore the action components of the business rule and look at how a rules engine can be used to deploy those rules.
David is the President of Knowledge Integrity, Inc., a consulting and development company focusing on customized information management solutions including information quality solutions consulting, information quality training and business rules solutions. Loshin is the author of Master Data Management, Enterprise Knowledge Management – The Data Quality Approach and Business Intelligence – The Savvy Manager's Guide and is a frequent speaker on maximizing the value of information. David can be reached at email@example.com or at (301) 754-6350.
Editor's note: More David Loshin articles, resources, news and events are available in the David Loshin Expert Channel on the BeyeNETWORK. Be sure to visit today!