How Semantics and Business Rules Amplify Each Other

There are two semantic ontologies to think about when dealing with business rules. The first is that business rules are built of instances from a business rule ontology (as shown in Figure 8.19). The second is that the terms in which the rules are expressed are taken from a semantic ontology from the domain that the rules concern. Figure 8.19 shows a small part of the rule ontology from the Business Rule Book,^[49] in this case a few of the "verifiers." Each of the rule types is a proper subtype of its parent, and each has a prescribed behavior. As shown attached to the "unique" verifier, each has a set of templated properties that indicate how the verifier binds to the problem domain. Using a business rules system means committing to the verifiers' rule ontology.

Figure 8.19: Business rules form a semantic ontology and use a domain ontology.

The two boxes at the bottom of the figure represent two items taken from the domain being modeled. They must be in the ontology of the domain for the rule to have any effect.

The challenge to creating effective business rules is knowing how to deal with the potential complexity. A typical legacy system has tens of thousands or hundreds of thousands of business rules. If we re-create the rules at the same level of specification that we find in the source system, we will have even more. We can reduce the complexity somewhat by removing some of the order-specific rules and by getting all the rest of the code out of the way, but this won't reduce the complexity nearly as much as we would like. Having a rich ontology, and basing the rules on the most abstract aspect of that ontology, has the potential to reduce the size of the rule base considerably.

Say you have hundreds of rules about approving various kinds of expenses, commitments, purchase orders, and so on. Some of these rules concern orders at certain stages of commitment; others concern specific resources or specific funds. You may find great economy and ease of understanding when you express the rules at the highest level of each ontology. For example, you might say, "All commitment over $x must be approved before being released" or "All movement of hazardous materials must be accompanied by an MSDS label." Your ontology informs you as to what "commitment," "released," "hazardous materials," and "movement" mean, and if your applications share the same ontology, you have potentially saved yourself hundreds of special case rules.

^[49]Ronald G. Ross, The Business Rule Book Classifying, Defining and Modeling Rules, Houston: Business Rule Solutions, 1997.