|
The rules are well
documented, safeguarding your business knowledge. Businesses run
the risk of losing rules that are locked away in the minds of its
employees, if those employees leave the company.
|
·
|
Rules are committed to an open rules repository, and not hidden
away in code or OO-objects. |
|
·
|
Rules are specified in a non-technical way, to facilitate easy
communication between technical people and users. |
|
·
|
Rules can be shared across applications, allowing you to define
them only once. |
|
·
|
Rules can be defined at atomic level, without having to
overview the full process. |
|
·
|
Rules are combined with other rules at run time automatically
to realize business functions and are therefore always evaluated
when needed. |
|
·
|
Programmers become focused on the business, and are hence
transformed into analysts. |
|
·
|
Communication between IT-department and business units improves
dramatically. |
|
·
|
The Rules Engine, and not the programmer, determines when a
rule needs to be invoked. When business policy changes, the changes
are implemented by updating the business rules only. |
|
·
|
A direct result of developing systems with business rules is
that the number of "lines of code" is reduced by orders of
magnitude when compared to other approaches. More complex systems
are built faster, and with less staff than with other methods. And
because fewer staff are involved, the systems are developed more
efficiently. |
|
