This article originally appeared on the BeyeNETWORK
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Although there is often discussion of business rules in the business intelligence arena, there are subtle differences regarding the exact definition of an actual business rule. Despite this confusion, many organizations are building rule-based applications, and data warehouses are being built based on business rules. This article examines a simplified business rule framework that may provide a basis for ultimately integrating more complex business rules into your environment.
First things first – let’s talk about semantics. A major issue that appears with all of our clients is the inability of relevant stakeholders within the organization to agree on basic definitions for commonly used business terms. Fortunately, this is my thought experiment, so we will eliminate this problem by capturing a standardized definition for every commonly used term in a metadata registry.
Okay, that’s better. I will define a “simple business rule” as “a declarative statement that asserts relationships between entities within your system,” and determines where to go next. Consider this example: “Customers pay for products using cash or credit cards.” This is a simple assertion that we expect to be true, so if a person walks into the showroom with a bucket of fish, he will not be able to walk home with a new car. Clearly, there is a language we can use: commonly used business terms refer to entities in the system, and we use verbs to capture these relationships. One advantage to this approach is that it forces the business and technical team to work statements out together, in a way that is separated from both the business process and the technical implementation. Here are more examples:
“Customers may only purchase in-stock items.”
“The employer pays employees with valid employee numbers.”
“Tax forms are filed before April 15.”
Notice that these examples conform to an assertion format—they are statements expressed in a declarative manner, focusing on associations taking place between business terms. While the assertions may describe actions, they don’t describe processes. In other words, the rule may state that some action takes place, but the events or state changes that trigger the activation of the rule are implicit; the way that the result is achieved is left out of the equation. Basically, we are attempting to separate simple facts from the way they are deployed within your environment.
Formally stating rules is interesting because it provides a means to exchange ideas that guide the business in a way that can be technically understood. Even better, separating assertions from the process exposes where implementation dependencies have been introduced that have an impact on an operational system. On the other hand, while this format can capture the concepts associated with an assertion, the “free-form” nature of the statement still prevents us from making the rule actionable. In reality, the value one extracts from a business rule process boils down to the ability to manage the rules for both content (for the business people) and implementation (for the technical people), and tying the two together.
We are basically still at the starting gate, since the free-formed text is still not actionable; it would almost be silly to cut and paste the above statements into a computer program and expect it work. There are two additional steps one might take to transform the simple rule into application code. The first is to formalize a statement of rules in a way that can be made actionable. My suggestion is to explore transforming every simple business rule into an if-then-else statement. This could be done by segregating the precondition, the expected state change when the precondition evaluates to true and the expected state change when the precondition evaluates to false. While this slightly contrasts a traditional artificial intelligence view of declarative rules, because our scope is limited this doesn’t pose a serious conceptual problem, and again, this is acceptable, since it is my experiment. Essentially, every rule can be stated in this form:
IF (precondition) THEN (positive action) ELSE (negative action).
Of course, there might not be a precondition (in which case it is assumed to be the static value ‘TRUE”), and there may only be one of the two actions defined. For example, we might transform our first example above into this:
IF (item is in stock) THEN (customer may order item) ELSE (notify customer that item is out of stock).
The second task is to clearly identify which business data objects are referenced and then identify the corresponding actual data objects that are used to represent those business objects, as well as how the jargon used to describe actions and attributes of those objects translates into clear expressions. Taking our example one step further, we would need to answer the following questions:
- How are “items” represented in our system?
- How is “in-stock” defined?
- What does the term “customer” represent?
- How is an order performed?
- What form of notification is done when an item is not in stock?
There should be a clear answer to each one of these questions. Answering all of them will complete the transformation of our simple business rule into a form that can be made actionable.
One additional benefit we can get out of this multi-phased process is an audit trail, which is established between high level policy and low-level code. We end up with a hierarchical representation of activating policy:
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 result of my experiment is the seed of a new idea. If we can begin to look at how policy can directly link to code, and then formulate a framework to manage that linkage, we would have an interesting way to correlate business activity to its related programmatic application. In turn, this can provide clarity of execution, nimbleness in change when the business policies change and simplified reporting about how information correlates to achieving business objectives.
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!
Dig Deeper on Business intelligence best practices