Creating and Managing Business Rules with Code Effects

If you've been in the industry long enough, you know that managing a system that uses one of the conventional business rules engines is not really that easy. Evaluation of existing tested and approved rules against an organization's data is almost never a problem. Engines offer a variety of easy to understand and easy to use features when it comes to rule evaluation. It's rule management that causes so many headaches to business teams all over the world. Particularly, creation of new rules and modification of the existing/established ones.

Traditionally, the creation of business rules is accomplished in one of two ways:

• Decision Tables. Rules are declared as text/CSV/XML/Excel files by business people who follow certain predefined formats, either public or proprietary. Such files are called decision tables. A single decision table usually defines one or more conditions and optional actions/value setters that make up a business ruleset. Each file is validated, compiled into native object(s), tested, and deployed by an IT team.
• GUI. Business people create or modify rules by using a graphical UI, either provided by the engine or developed in-house. Such a UI often requires a working knowledge of scripting languages or consists of a series of predefined drop downs that can dynamically change their options depending on the current input. The IT team only sets everything up and maintains the system; the rule management itself can be administered by the business.

While other methods do exist, the above mentioned are the most common ones.

Decision tables have been around since the 60’s and haven’t changed much since then. Their fundamental problem is that business analysts cannot manage corporate rules without IT being heavily involved in the process. More often than not, a non-technical person cannot simply create a new table; first, (s)he must learn either some rule definition language or a cryptic format. In such systems, MS Excel ^© becomes the UI of choice, and it's not necessarily a great choice when it comes to business rules.

The GUI approach is the most appealing for organizations because it has the potential to almost entirely separate IT from the business, but it's very difficult to create a requirements-crunching system just by throwing a bunch of drop downs, labels, and check boxes into fixed locations, no matter how complex the underlying logic is.

Code Effects business rules engine approaches the traditional business rules management from a completely different perspective. It provides an almost limitless GUI while delivering record-setting rule evaluation performance. There are no decision tables, no predefined UI controls; your business rules get compiled into IL objects just before the evaluation starts in order to achieve the amazing performance that made Code Effects engine so popular. The engine it very easy to set up and use.

As mentioned elsewhere in this documentation, Code Effects business rules engine is not a complete system. It doesn't include rule authorization logic, versioning control, or debugging capabilities. You can build those parts yourself if you need them. We concentrate only on features that are essential for successful creation, validation, and evaluation of business rules.

Here is what needs to be done in order to use Code Effects in one of your products or as a stand-alone business rules engine:

• First, you must define the class(es) or Source XML doc(s) that our engine can use as source object(s). Chances are, your organization already uses such classes. You can even generate your source objects on-the-fly at run-time using our FlexSource technology if you store your fields and their values in a database. The possibilities here are actually limitless.
• Next, you need to decide which of your systems will host the rule evaluation. For example, it can be a Windows service, running 24/7 in the background somewhere on the corporate network. It could register a SOAP/WCF service and wait for instances of your source objects to arrive, evaluating each instance against one or more business rules. With Code Effects, it literally takes one assembly reference and several lines of code to evaluate a source object (or a multitude of source objects) against one or more business rules.
• You also need to give your business analysts a way to create, edit, save, and delete rules. Code Effects business rules editor does not save or delete those rules for you. Instead, it gives you the rules’ XML documents and some related data every time the rule author clicks the Save, Delete, or Load button. It's up to you, the developer, how to handle that data. So, create a new web application or use any existing one and drop the Rule Editor in it. Define the rule saving, loading, and deleting logic to complete the application. That takes a relatively short amount of time, unless you enhance the app by adding rule security, debugging, and versioning features. Our demo projects can help.

It's worth noting that Code Effects rules editor is not trying to become an online IDE or a code editor of any kind. Our goal is very simple: to provide the best and easiest to use business rule editor for business people. Every new UI feature that we consider must make Code Effects easier to use for people who deal with business rules on a daily basis.