About Business Rules
After having disclosed BRFPlus in my first blog I want to take a look at business rules in general and give you some thoughts on the business rules idea, tools and trends.
What are Business Rules?
There are many definitions, for example, you may have a look at the definition in wikipedia http://en.wikipedia.org/wiki/Business_rules
“Business rules or business rulesets describe the operations, definitions and constraints that apply to an organization in achieving its goals.”
This definition is very broad. It includes business habits, manuals, policies, program code, customizing etc. This is basically everything that makes a business. There were some attempts with so called expert systems (http://en.wikipedia.org/wiki/Expert_systems#Prominent_expert_systems_and_languages) to describe the definitions and operations of a business in a knowledge base. However, trying to apply such a concept to the complete organization is a huge effort and it is very difficult to manage the knowledge.
More pragmatic approach
Today, we take business rule management systems (BRMS) to create and organize business rules. These rules do not have the goal to describe the entire company but focus on some specific parts of it. Typically, business rules are used where frequent changes to business practice are needed and the changes should be applied by business users, not IT experts. We can exclude all technical rules (e.g. decision on sorting algorithms or key types). And we can exclude all the framework code and fix parts of a software application.
This means software applications that utilize the business rules idea are written in such a way that there are parts which remain unchanged and parts that are subject to changes. Application developers usually want to keep some level of control of what can be done with the application. Otherwise, the application may end up in an inconsistent state or with corrupt data.
The flexible parts to be delegated to a BRMS include:
- Automating procedures (e.g. credit approval, claims processing)
- Diagnosis and validation (e.g. detection of incomplete/invalid data or states)
- Derivation and classification (e.g. customer groups, risk profiles)
- Matching (e.g. products, responsibility determination)
- Calculations (e.g. overhead costs, pricing)
All those tasks can be delegated to the BRMS. A good BRMS allows the business user to define, document and organize the rules. Business users should be able to search rules and understand how the software system behaves in distinct situations. This externalized knowledge may grow over time and the BRMS helps to react much quicker on changes because an IT involvement with specification, development and testing phases is not required anymore[SAP1] . Furthermore, a good BRMS allows you to select from various representation metaphors:
- Decision Table
- Decision Trees
- Flow Models
- Text Rules
There is no standard technology for rules such as the relational database systems that have been emerging as a standard with SQL as a query language. Although the RETE algorithm (http://en.wikipedia.org/wiki/Rete_algorithm) has become a standard for inference engines, there are many other approaches that are equally good or even better for some problems, e.g. code generating engines or learning engines. RETE is often used for text rules and code generation is used for decision tables and trees.
Many applications are not connected to a rules engine but offer customizing tables or scripting exits. Although this is much less convenient and flexible, business rules can also be modeled with a set of customizing tables.
Connecting an application with a BRMS can have some drawbacks:
- Performance problems because of data transfer, different protocols, etc
- Business users need to leave “their” system and learn to use another application
- Additional license costs
- Data inconsistencies (BRMS uses outdated values)
- Missing integration (BRMS cannot use actions provided by application)
This brings us to the two levels of integration of a BRMS:
- Backend integration (direct calls instead of Web Service calls, share repository and database, application lifecycle with back-ups, data import/export, …)
- Front end integration (embedding and customizing of BRMS UI components such as decision tables into the application UI)
Ideally the rules engine is integrated in such a way that the business users do not perceive a technology or user experience break. They will automatically use the business rules engine when working with the application. Additional training is not required.
Importance of the Business Rules part in a software application
The business rules parts of an application are sometimes rather small: e.g. when a BRMS is used for account determination. Although important this is a rather small part of a financial application. The rules engines may be included in some customizing steps. It adds to the flexibility of the application. The application could also exist without usage of the BRMS and use customizing tables or a code exit instead.
In contrast to that there are also applications that are rather an interface and additions to a BRMS. Let’s take applications for tax declarations. Most of the tax laws can be transferred into business rules. The job of the application is to collect and to persist user data. The calculation, validation, user messages etc is all coming from the business rules which makes the BRMS the heart of such applications.
Recommended Reading: Getting Started with Business Rule Management from Rajagopalan Narayanan