"Business Rules" are individual pieces of logic that are normally captured in specifications by systems analysts, and put into application program code by programmers. There are two major problems with this approach.

• The rules are usually written down in text documents. In this format it is difficult to see what makes up one rule. A given rule may be redundantly restated in different ways that make it easy to misinterpret. Finally, in text form the rules cannot easily be linked to each other or the objects (such as data elements) that make them up.
   
• If all business rules have to be hand-programmed by programmers, applications cannot be changed quickly. Quite often, application code often has to be reverse-engineered to understand what the rules are before any change can be made. This may be needed to understand what impact changing one rule will have on other rules. Once a change has been made, testing needs to be done to ensure that the programmer has correctly interpreted the new specifications.

Thus, traditional systems development metodologies tend to create applications that are "Black Boxes", whose inner workings are often unknowable, and which are difficult to change. The business rules movement is addressing these issues in a number of ways. Tools and techniques are being developed for capturing rule definitions. Additionally, business rules engines are being created. These allow business rules to be defined, and then executed without programmer intervention. A number of commercial rules engines are available, and may suit the needs of many organizations. However, at the same time there are often requirements that do not justify the purchase of a rules engine product, but call for adding some degree of rules engine functionality to an application to extend its usability. The question then arises of how to design such rules engine components, and it is the design issues involved in such architectures that this site, and the book How to Build A Business Rules Engine, are devoted to.