Business Rule Technology
Is Business Rules Approach better than traditional coding?
Traditional coding is good when business applications are static and the logic coded is simple. What happens if the business rules need frequent changes to accommodate the real-life competitive market scenarios which require repositioning in terms of business policies, pricing, promotion and marketing.
Consider a scenario where a number of products/services are offered by a company. Each of these products/services has complex configuration and different promotion/pricing rules. If we adopt a traditional programming approach it is not hard to see the huge effort involved in coding the logic layer for these configurable products. On the other hand it would require continuous effort from the IT team to make the changes to accommodate customer preferences to launch advanced and upgraded products.
The requirement gaps between business and IT almost always exist which leads to frequent release cycles for development/enhancement/defects and a complete regression testing cycle. A business rules approach, and a business rule management system, can help close the gap and empower business users to manage their business rules independent of IT.
Business Rules approach de-couples the business logic from the application layer in the same way as the persistence layer abstracts the database interaction from the application layer or as the presentation layer is separated from the controller.
There are a number of advantages gained by expressing business logic in business rules. In brief they are :
* The separation of decision logic from implementation gives you more flexibility to make changes with minimal or zero impact on the system applications.
* Business rules are easy to understand by the business people, leading to better business/technical cooperation, reduced implementation times, and fewer opportunities for interpretation errors.
* 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.
* Each unit of logic can be independently expressed in a business rule. Rules are precompiled into a decision tree 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 rules can have explicit times and dates when they should go into and out of effect.
* Rule Templates and Domain Specific Language helps business users/analysts to update, view, or create rules in an intuitive English phrase language 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.