Business rules are not new. They exist in businesses whether some or all of the business is automated. Not all business rules may be automated. The generally accepted definition of a business rule comes from The Business Rules Group in 2000 as “a statement that defines or constrains some aspect of business intended to assert business structure or to control or influence the behavior of business.” The approach, the Business Rules Approach, is new in its formalism of managing rules and its emphasis on the business as a priority over the systems implementation. The business rule is a distinct asset and a specific artifact. The systems implementation is easier if the up-front work on the business side is emphasized. The Business Rules Approach extends current systems development life cycle methodologies rather than replaces them. In some cases, the Business Rules Approach addresses only the business-side (no systems development side) for rules that are not automated but which are of importance to the business regardless.
When business Rules exist in systems, they are almost always often buried in program code. Automated business rules with a Business Rules Approach will occur most likely in a combination of:
• a business rules engine (BRE),
• multiple business rules engines (BREs),
• user interface
• business objects and methods
• databases
• in code
• other means
The best design approach implements a rule without redundancy. For instance, static rules may be better off in code rather than through a BRE. This is one of the design decisions that must be made for business rules.
Business rules engines (BREs) are often enablers of business rules implementations. The overall development time for a project using a BRE is usually faster than programming the rules in conventional languages. The rules written in a rule language are separated from complex programming code and written in business terminology. A BRE also allows reuse of the rules across multiple systems and user interfaces. The development process becomes more flexible by allowing the rules to be changed without impacting the rest of the application. Of even greater value than initial development is the significant savings in future maintenance because rules are more accessible and more amenable to quick changes.
The business application coding will interact with the BRE as follows:
Interactions between Applications, Data, and Rules (source: How Blaze Advisor Works)
Generally, business applications invoke a rule service for a decision just as they would invoke a database for data. The results of the decision process can be used to drive further operations and interactions. When invoked, a rule service uses the application data (referenced as any combination of Java objects, database records, XML documents, Microsoft COM+ objects, or custom-defined objects) to make decisions based on the application data and business rules. The decision results can be passed back to the calling application or can be defined as actions taken in the decision process. Actions might include database update messages, calls to external applications, or use of Java methods on objects.
Most BREs support web services, J2EE, EJB, .Net, COM. Some BREs also run on mainframes, and can integrate with legacy systems as well as supporting both interactive and batch systems.
However, all business rules need to be identified regardless of where or whether they are automated. All business rules need to be discovered at some point in the development process. The real key is getting at the “what” not the “how” and at the business’s reasons for having those rules and maintaining them over time, regardless of automation option.
Ladd Bethune is a solutions-oriented technical consultant and innovator with expertise in Business Rules Approaches, Relational Database Tools technology and Reporting Information Systems with 30 plus years experience in IT.
There are no products in your shopping cart.
| 0 Items |
Membership at BPMInstitute.org includes access to our other communities
