Some of the newer technologies that are critical to advanced business technology are based on 'open' standards, such as CORBA, J2EE and XML.  However, many of the implementation architectures that use these components are either proprietary or heavily-dependent upon closed technology. Often, they are called frameworks.   IBM is particularly active in providing technological infrastructure for business rules systems and, it must be said, providing strong support for open standards as well.  

Some of these solutions have a strong data management flavor.  Data quality is a constant concern for the financial services industry and is also a major concern of business rules.  The meta-data ( data about data ) collected by corporate business rule initiatives can often feed directly into existing data modeling and administration tools. 

There is also the other 'parallel dimension' of business rules, that is Business Process Modeling ( BPM ), encompassing large-scale integration of distributed business processes, perhaps spanning globally distributed business units.  This high-end type of system is largely supported by Service Oriented Architectures ( SOA ).         

The term "business rules technology" can take many forms.  There are wide range of 'data driven' applications that utilize business rules technology, for example front-ends for web servers that are not specifically business rule systems, but use a rule engine to create complex, customized documents ( "dynamic content" ) over the Web.     

At the center of the technology and its unique feature is the rule engine.  Sometimes it is difficult to explain what rule engines do, so it may help to use an analogy that many people understand - the spreadsheet.        

There are several interesting feature of the definition, first of all in what they call it, which is an "inference engine".  An inference is the act of deducing what is not explicitly known from what is explicitly known.  The inference engine performs something like logical calculations on rule equations ( the rules ) and derives new values from those calculations. 

In a way, this is similar to the operation of a spreadsheet.  The important feature is that the spreadsheet keeps data and the formulae where they are used in synch.  When a value changes that is used in a formula, the value of the formula changes automatically to reflect the change in the data.  For instance, a formula adds together numbers in two cells, say the numbers 1 and 2, totaling 3.  If the number 2 is changed to 3, the total will automatic change to 4.  

This is very similar to the workings of a rule engine, except the rule engine uses formulae with logical values of 'true' and 'false' instead of numerical values.  The rule engine automatically maintains the truth value of logical expressions ( rules ), guaranteeing that all assertions about the truth of derived facts are in synch with the underlying rules that support them, that is, they are internally consistent.  This is what Haley describes as the "reasoning function"

A second interesting feature of the Haley definition is the "runtime execution of rules authored with a business rules authoring tool".                              

There are two major components of the existing technology:

Business rules methodology - a systematic way of going about understanding and using business rules in the context of the entire business, that is The Enterprise .

Technical facilitators - "rule engines", databases and communications networks.  The purpose of the "rule-based" processing environment is to derive valid inferences from a set of data and associated business rules and then react appropriately to the situation.

There are several open architectures for knowledge-intensive applications.  

Some can be quite sophisticated and complex, but a simple example is shown below.  It is based roughly on the well-established Carnot process-oriented architecture, which has been extended to provide direct support for business rules.   Inside each of the boxes are "components", in a formal sense of "architectural components".   

A Simplified Implementation Architecture for Knowledge Applications

The architectural components required to implement applications within this architecture can be either built internally or bought from an external source.  In a real world application, some software component would be needed to fill the each of the vacancies defined by the architecture.

From the simplified perspective of the Semantic Web, the three major components are semantics, presentation and data.

Semantic Services – knowledge discovery and modeling, schema and metadata, translation and semantic integration services, workflow and business rule definitions.

Presentation Services – HTML, HTTP server, JSP and XML/XSL engines.

Data Access – all database access, particularly access driven by a rules engine, to data sources such as SQLServer, mySQL, Oracle and Access databases.

In larger scale business systems, additional components are distribution, support/ infrastructure and communication.

Distribution Services – transaction processing, communicating agents, workflow management, repository management, legacy system access and administration.

Support Services – naming, directory services, messaging and security. If applicable, this layer would also include most of the facilities of CORBA, Object Adapters and Object Request Brokers. It could also include DCOM, MQ/Series, etc..

Communication Services – OSI, TCP/IP, Internet and DCE.

As the technology of the Semantic Web continues to evolve, others component may become feasible, particularly workflow management. 

There are some links about rule engines on the Technical site.