Advantages of Business Rules over code

From SmartEnoughWiki

There are a number of advantages gained by expressing business logic in business rules and using the processing and management facilities included with a Business Rules Management System to work with them. In brief summary:

• The separation of decision logic from mechanical implementation gives you more flexibility to make changes with minimal or zero impact on basic systems operation.
• Business rules are more understandable to business-level people, leading to better business/technical cooperation, reduced implementation times, and fewer opportunities for interpretation errors.
• Business rules are easily segmented into groups for control over functional interaction and management.
• Business rules management systems like Blaze Advisor have interactive testing, execution flow, cross-reference tools, and reporting features to aid in development, testing, and documentation.
• Business rules management systems have predefined rule replacement features to handle system updates without interrupting service to application users.
• Business rules can have explicit times and dates when they should go into and out of effect.
• Rule management templates can be created to let users update, view, or create rules in a controlled manner without knowing anything about syntax or code.
• The rule engine can quickly look through large sets of rules, finding the proper ones to apply based on case-specific conditions. No code is required to specify which logic subroutines should be fired in which order.

Business rules syntax allows for a great deal of flexibility that you cannot replicate in traditional programming languages. Rules may be written with English phrases such as "If customer's age exceeds 65 then set customer's discount to .05". This type of familiarity lets business policymakers work side by side with the implementation team. Indeed, several of our customers have put business analysts through the rule writing course and had them writing rules, with no previous programming experience.

Another key difference is that this approach "describes" each unit of logic independently in a business rule. Rules are precompiled into a decision structure that organizes condition combinations for very fast determination of all rules affected by a given set of condition values. A particular condition state is calculated only once, rather than in each separate "line of code" where it might appear in a traditional coding block. The sequencing work that would need to be planned by a coder in writing multiple possible execution threads is automated by the rule engine. As a result, the rule developer can focus on the "correctness" of each atomic piece of logic instead of the sequencing and nesting of if-then-else constructs.

Business rule evaluations also persist during the execution process. This translates into faster execution when many rules apply to your application objects, as conditions (shared by many rules) are evaluated only once during the rule invocation or more precisely each time the value changes. Rule updates propagate to the relevant "nodes" in this decision structure, so the engine does not have to keep rechecking the conditions of every rule that has been defined.
Business rules also provide flexibility for maintenance. In a traditional procedural implementation, the developer would have to understand the chaining programmed in the code for each if-then-else statement or loop. This is a time consuming and high-risk activity. Using rules, it is sufficient to replace, add or remove a rule. The next rule compilation will build a different decision structure that reflects the changes.

Rule templates give rule developers the ability to define specific structured types of rules or replaceable parts of existing rules that should be "exposed" to business level users for rule maintenance or creation. The product auto-generates rule maintenance application Web pages with links to the underlying rules so that business managers can make highly controlled and secure changes without ever seeing a word of the underlying rule syntax. Where appropriate, you can release the ownership of portions of the application business logic without running the risk of allowing unintended changes to other application code. This can greatly reduce costs in making incremental business changes to existing applications by taking the burden off programming departments having to work on maintenance releases.

Because the rules are managed and executed as an independent process called upon by your application, they can be updated at any time without requiring recompiles, links, or processing interruptions to your production application. Rule logic can be tested off-line and then introduced into a running application according to your strategy (scheduled, automatic or manual updates).