Business Rules Management - How it works

The Old Way

The New Way

Rules written in COBOL or 3GL programming languages are buried deep in the system code of a single application.

Rules are written in a simple rule language and managed separately from system code.

Rules can be executed only by the application they were originally written for, in the manner they were originally coded.

Rules can be used in many flexible ways to reach decisions that can be carried out by virtually any application or business process.

Rule changes, which require reprogramming and can even involve reverse engineering, mean queuing up for IT help.

Rule changes can be made quickly and inexpensively by business users without requiring help from IT.

New application development takes a long time because programmers must try to anticipate and code for every possible combination and interrelation of variables and conditions. Given today's complex business environment, that's just not possible any more, so long development cycles are soon followed by extended enhancement cycles.

Rules management solutions enable new applications to be developed quickly, without the need to anticipate every possible decisioning scenario. As new situations and information emerge, enhancements are made by business users. New rules can be added at any time, without interrupting operations and with the rules engine sorting out how and when to execute them.

Adding rules to legacy systems can be risky, given the fragility of some of these systems and the complexity of trying to make them perform functions they were never designed to support.

Rules management services can be called by existing applications. This enables legacy applications to be reinvigorated with new capabilities without actually having to mess with them.

Extending decisioning across new channels usually requires building a duplicate application, from the ground up, to run in the new environment.

Decisioning applications can be written once and deployed without modification across most any operating environment. IT can deploy and maintain a single application across multiple channels.

Development and deployment are often delayed because of difficulties translating complex business processes and requirements into code. There's too much opportunity for something to get lost between what the business people say they need and how the programmer interprets that in rules. It usually takes numerous revision cycles to get it right.

Decisioning applications and services are developed usually by IT or a technically inclined business analyst--using a rules language that closely approximates the way business people talk about policies. Little interpretation is needed, so development goes smoothly. Developers can also let nontechnical business users write many of the rules themselves using graphical trees, tables or Web forms.

Precision

Business rules give you the ability to easily segment customer populations, target offers and develop detailed rulesets, in order to make a decision that is more finely tuned to the specific opportunity or circumstance.

Consistency

With business rules you can automatically ensure that different staff and different systems will make the same decision.

Agility

It’s easy to change business rules in order to launch a new product, introduce a new offer or change terms and conditions.

Speed

Business rules automate decisions that must otherwise be made manually. They also accelerate the development of new applications.

Cost

Automating decisions using rules saves the cost of staff time needed to make operational decisions. In addition, business rules can reduce the cost of developing new applications by up to 80%, and the maintenance of applications by up to 75%.