Business Rules


The goal of business rules is to extract business logic from the procedural application code, where it currently resides, and store it in a place and format where it can be reasoned about and changed much more easily. Currently the business logic of an application is marbled throughout the procedural code, which is often millions of lines of code. Because of the way the code is structured and divided into modules, the same logic often must be applied and reapplied, creating many opportunities for inconsistency. In the business rules approach, the rules are expressed as declarative statements that do not embody procedural concerns or flow of control. These rules can be stored in a database in such a way that tools can reason about their completeness and potential inconsistencies (in other words, are these two rules likely to contradict each other in some circumstances?).

Separating the business rules from the rest of the code involves two nontrivial operations:

  • Determining the rules and expressing them consistently

  • Ensuring that the rules execute when they should

There are many sources for determining what the business rules are. The existing code is one set of validated rules; however, extracting the rules from the legacy code is no mean feat. There are tools that will help with this, but they can only uncover the rules that were implemented, using the terms that were used in the data model. Another good source are the requirements of the applications, starting with the imposed requirements: laws and regulations. Laws and regulations play a role in more and more applications, and they are amenable to being reduced to rule expression. The other sources are the strategy of the enterprise and interviews with key users.

Ensuring that the rules execute (or "fire") when needed is also a nontrivial problem. The two most common approaches to date have been to fire as a side effect on a database update (any time the order table is updated, fire these rules) or to have the applications know when they must explicitly call the rules engine (this works well for things such as pricing or scheduling where the applications cannot do the operation on their own and know they need to call something to get the function completed). However, neither of these approaches is ideal. A more likely successor will be a business rules engine that operates on message traffic. Work flow routing systems already exist that do this, and it seems a logical extension to extend this to more general rule processing.

The connection between business rules and semantics exists at two levels:

  • Business rules are expressed in terms of "terms." If we accept all the terms that we find in all the applications and regulations, we end up with a rule base nearly as complicated as the code base it was meant to augment. We end up with a large number of rules just to describe which terms are synonyms or near synonyms. A rich semantic model and ontology provides an elegant base on which to express the rules.

  • The rules themselves are instances of classes that each have specific semantic meaning. Each business rule taxonomy works approximately the same: To replace procedural logic, the business rule environment creates a number of parametric rule types. These rule types are arranged in a hierarchy. The whole structure is a semantic model of business rules, and it is the elegance of the model that makes it possible to build relatively simple tools to evaluate the rule base or (on the execution side) to determine which rules to fire at run time.




Semantics in Business Systems(c) The Savvy Manager's Guide
Semantics in Business Systems: The Savvy Managers Guide (The Savvy Managers Guides)
ISBN: 1558609172
EAN: 2147483647
Year: 2005
Pages: 184
Authors: Dave McComb

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net