USING BUSINESS RULES TECHNOLOGIES TO BRIDGE
THE GAP BETWEEN BUSINESS AND BUSINESS
APPLICATIONS
Marko Bajec, Rok Rupnik, Marjan Krisper
University of Ljubljana, Faculty of Computer and Information Science
Tržaška 25, 1000 Ljubljana, Slovenija
Tel: +386 61 1768367; fax: +386 61 1264647
e-mail: marko.bajec@fri.uni-lj.si
Abstract
Business rules represent a significant aspect of every
business environment, since they define and constrain
business processes in enterprises. Therefore, many
business-governing rules have to be implemented in
business-supporting applications, in order to reflect
the real business environment. In fact, software
engineers have been doing that, for as long as the
applications have been built. However, not every
approach is appropriate. For example, if business rules
are buried into program code, applications become
very difficult to maintain when business changes. This
paper examines business rules from the applicationdevelopment perspective, discussing traditional and
contemporary business-oriented approaches to
business rule implementation. A special focus is given
to the modern technologies that support isolation of
business rules in the application architecture.
Therefore, a lot of effort has been put into developing
applications, which would be flexible and easier to
change and adapt, if possible without any developers’
involvement. Most of today’s applications do not
apply to the above characteristics, demanding to
implement changes by modifying low-level program
code.
According to the various discussions [1,3,4,6,9],
business rules are the ones that have a significant
affect on business application’s scalability. While they
define business environment, they are found very
difficult to manage and maintain, if not represented
properly, especially if buried into the program code.
The most common problems that arise from that are:


1 INTRODUCTION
Rapid and constant changes that are very common to
today’s business environments affect not only the
business itself, but also supporting applications,
requiring their constant change, adaptation and
renovation. Since information systems (IS) are in the
core of every business, demands on IS departments to
change, adapt and extend their applications to reflect
business changes are increasing.
Unfortunately, the predictions of being able to
develop applications without any programming effort
[10, 11] have not yet come true. We all know that
even when minor application changes are required, we
still have to get an IT professional (developer) to do
the job. Besides rarely available developers, we deal
with communication obstacles, which coexist among
users as business professionals and developers as
engineers. According to some reports, those obstacles
are often found responsible for many IS project
failures [12, 13, 14].
-1-



Every change of business rules requires
programming.
Business rules are distributed across the
application logic; thus the place where the change
has to be made is hard to find.
Business rules are dependent and interrelated
chunks of logic. Therefore they have to be
modified carefully, considering the possible effect
on the other rules.
Since requirements for change primarily arise out
of business need that developers are not
necessarily familiar with, we risk business rules
will not be understood and implemented
correctly.
It is very difficult to control business rules, since
there is no common and single purpose store for
them.
The problems mentioned above are at the same time
the main reason that brought about some new modern
development tools, based on so-called business rules
approach. The main idea of this approach is that
business rules should be logically separated from the
application data and functionality. Moreover, they
should be easy to access, view, modify and manage,
for both, developers and business users. Achieving
those goals would result in improved applications’
scalability, making applications much easier to change
and maintain.
2 BUSINESS RULES
Unfortunately, neither today-in-use development tools
nor methodologies address business rules explicitly,
but they deal with them from data and function
perspective only.
Because the term “business rule” is many times
misused and misinterpreted, we should first clarify it,
as well as other terms that usually occur together:
business policy, business statement. According to [1]
these terms could be defined as:
The shortcomings of this implicit handling of business
rules were first pointed out by Mr. Zachman, who
published a rather different view on the framework for
information systems architecture, in a form of a
matrix [17]. Instead of representing a development
process as a series of steps, he organised it around the
points of view (columns), taken by various actors
(rows). In the rows he included the planner, who is
responsible for organisations’ strategy, the owner,
who runs the business, the designer, who wants to
represent the business in a disciplined form, the
builder, who applies specific technologies to solve the
problem of the business, and finally the system itself.
He then defined columns, describing the kinds of
things, where actors should be looking at, when taking
their part through the development process. At first,
he included only data and functions as addressed by
most methodologies, but he soon discovered this was
not enough. According to his opinion, additional focal
points are necessary: the location, where business is
conducted, the people and organisations involved,
events which cause things to happen, and the
motivations and constraints (business rules) which
determine how the business behaves.
Business Policy: A general statement of direction of
an enterprise.
Of course, to have a blitz on the business rules
requires additional tasks to be carried out and many
new deliveries to be produced through the traditional
development life cycle. Within the analysis, business
rules have to be captured, within the design, they have
to be modelled, and finally, within the implementation
phase they have to be implemented, using a right
technology. Many of this aspects (mostly from the
design phase) are covered in Mr. Ross’s book [16],
who have introduced a complete and rigorous theory
of how to define business rules in a precise and
unambiguous manner. However, a lot of researchwork, still has to be done, in order to be able to
manage business rule when developing and
maintaining business applications. In this paper, we
focus on the implementation phase, describing the
available technologies, their pros and cons.
Example:
If a student has failed the examination more than
three times, the board of examiners must be convened.
Before we discuss the concepts of business rules
approaches and tools, we should first clarify what
business rules are, and how they are implemented in
traditional applications.
-2-
Example:
Only students that fulfil all the conditions required
are allowed to register to an exam.
Business Rule Statement: A declarative statement of
structure or constraint, which the business places upon
itself or has placed upon it.
Example:
If a student has failed the examination more than
three times, the board of examiners must be convened.
In addition, the student must pay for the examination.
Business Rule: A statement that defines or constrains
some aspect of the business. It is intended to assert
business structure or to control or influence the
behaviour of the business. It is atomic in that it cannot
be broken down or decomposed further into more
detailed business rules. If reduced any further there
would be loss of important information about the
business.
Because business rules are usually informal
statements (sometimes referred to as business speech
or business rambling), they require some more formal
representation like logic language specification [2] or
graphical notation [15].
For example, a structured English example of a formal
rule statement (as an expression of the business rule
above) is:
If Student.registration(exam_id) > 3 then
Convene Board of Examiners(exam_id,stud_id)
End If
As shown in Figure 1, business rules are based on
business rule statements, which are further based on
business policy. Business rules are expressed formally
in formal rule statements that follow some formal
expression type.
related to
Business
Rule
Statement
3 TRADITIONAL WAYS OF
BUSINESS RULES
IMPLEMENTATION
part of
Business
Policy
based on
basis f or
part of
related to
In order to make applications adaptable and flexible,
developers have been using several different
approaches, for a long time. The most common
traditional methods include parameterisation and
using database triggers and stored procedures.
source of
based on
Business
Rule
an expression of
expressed in
Formal
Rule
Statement
3.1 Parameterisation
f ollow
One method of adding flexibility and adaptability to
an application is to parameterise the application and
its components. These parameters may be then set in a
configuration file or in a database, and can be
managed through a configuration utility. Doing so, the
application can be adapted to different environments
and situations just by parameter settings, without any
programming effort [19].
is conv ention of
Formal
Expession
Type
Figure 1: The origin of business rules
Another important fact that relates to business rules is
that business rules are declarative and not procedural.
They describe desirable, possible state that is either
required or prohibited. However, they do not describe
the steps to be taken to achieve the transition from one
state to another, or the steps to be taken to prohibit a
transition.
The most common mistake is to classify requirements
that have nothing to do with business process, as if
were business rules. See the following examples:
1. Past due accounts should be displayed in red in
the interface.
2. The application should enable concurrent
connections to support multi-user environment.
These, of course, are not business rules. Neither they
describe nor they constrain or influence the business
behaviour, but they only tell how some aspects of
business process should be implemented. Therefore,
we suggest referring to them rather as
Implementation Rules. In contrast to the business
rules,
which
are
platform
independent,
implementation rules involve the actual software
architecture and for that reason depend on selected
development tools, operation system, hardware etc.
These rules are very important, especially in
application design; however, since there is no
straightforward connection between them and
business rules, we should refer to them no further.
-3-
The parameterisation technique proves useful when
used to parameterise business rules. Although the
business rules remain hidden in the application logic,
they can be modified through the parameters, without
any need for changing the program code. In addition,
business rules modifications can be made by business
people, if they provided with simple and user-friendly
configuration utilities.
However, this approach presupposes that the
development team can foresee all kinds of changes
that are likely to be required. Moreover, it
presupposes that the development team is sufficient to
manage for all additional cases to be programmed and
parameterised. This requires the parameterisation of
all logical decisions (decision logic has to be used or
bypassed, and the variables used have to be stored as
modifiable parameters). Consequently, it turns out this
is extreme burden on the application developer. In
addition, an application testing suffers from
combinatorial explosion effect that sometimes
requires an additional application in order to configure
the parameters correctly. Often, these parameters
themselves will be interrelated, requiring assumptions
and rules to be encoded in the parameter-modifying
application, with similar problems [19].
3.2 Using Database Triggers and Database
Procedures
Most applications rely to a greater or lesser extent on
a persistent data store that is usually based on
relational database technology. Relational Database
Management Systems (RDBMS) provide so called
“triggers” that have ability to execute actions,
immediately before/after particular events occur.
These events occur when a record is inserted into a
database, when a record is modified, or when a record
is deleted from the database. Actions executed by
triggers are written in Structured Query Language
(SQL) and are stored either as the trigger body, or as
database procedures.
The characteristics above make triggers convenient
for implementation of business rules. For example, by
using "before-insert" trigger the record can be
checked (and refused if violates any business rule)
before it is actually inserted. Since the implementation
of the business rules (formal rule statements - see fig.
1) resides in the database itself, modifications are
application independent and can be performed without
accessing the application logic. There are several
advantages of using database triggers to force
business rules:
 The formal representation of business rules is





based on the SQL language that is close to natural
language.
The business rules are independent from the
application logic, since they are stored in the
database.
The business rules reside on the database server
(on the one single place). Therefore, they are not
dispersed over number of clients.
Modifications of business rules can be performed
remotely (remote accessibility is one of the most
important features of the database servers).
The place where the particular business rules are
implemented is easier to be found, since we know
the actions that initiate them.
Adding a new business rule does not necessary
require application code to be changed.
However, this approach suffers from being data- and
database-dependent. Moreover, it cannot easily
provide rule support for client or middle-tier
applications dealing with complex business objects
and business processes. Despite the similarity between
SQL language and natural language expressions,
managing database triggers still requires an SQL
professional. Ultimately, such an approach forces the
data store to be a process engine, a task that database
engines are not optimised for [19].
4 MODERN WAYS OF BUSINESS
RULES IMPLEMENTATION
Modern ways of business rule implementation follow
the business rule approach and manipulate business
-4-
rules in an explicit manner. Within the context of the
business rules approach, a business rule represents an
important meta-element that needs to be captured,
formalised and implemented apart from the other
elements constituting the application architecture.
Today, several development tools are available, based
on business rule-oriented technologies. Considering
how they represent, implement and execute business
rules, they can be classified as follows [3]:
 Database-independent tools: business rules are
implemented within a database, using triggers and
stored procedures. However, they are generated
automatically and managed by the development
and not database tool.
 Server-based tools: business rules that are created
by a development tool become middle-tier
application services and reside on an application
server.
 Rule-based systems: instead of specifying
constraints on specific data elements or tables, a
logic-oriented approach captures the higher-level
business logic and rules associated with different
situations. At run-time special engines are used to
process the rules and to generate appropriate
responses.
4.1 Database-independent tools
As stated above, database-independent tools use
database triggers and stored procedures to implement
business rules. However they support code for triggers
and procedures to be created automatically, and
managed within the tool. This approach effectively
moves the creation and management of data-centred
business rules up one level to an application
development tool rather than a database-specific tool.
Development tools that are based on such an approach
presuppose that business rules form, together with
implementation rules, sufficient information to
develop any classical business application. Through
interviews and business area analyses the analysts
begin to form structure for the data elements required
by the end user. The analyst identifies tables,
columns, data types, data relationships and other
structure-based rules (data rules). Instead of requiring
the end user to verify the data model, the tool creates
components for the database and a window interface
to review the structure by working with the
application (based on those rules). If the application
does not match the rules of the business, the analyst
can immediately change the structure rules. The userinterface is then specified further by using
implementation rules (presentation rules). Finally, the
specification of all other business rules takes place.
The tool usually provides interfaces to capture,
describe, formalise, and to implement business rules.
Data
Rules
Data
Model
Business
Rules
Business
Model
Database
server
that contain business rules. Thus the main application
and data-related logic reside on the application server
and not the database itself.
Database
Server
Database
Management Tier
Middle Tier
DCOM,
CORBA
Rules
Processor
Application
server
Presentation
Rules
Presentation
Model
Desktop Tier
Application
(VB, Java, ..)
Desktop
Application
Figure 2: From Rules to Application
Figure 3: Rules Processor: Middle-Tier Service
A good example of this type of product is Vision
Software's Vision Builder, that automatically
generates the appropriate stored procedures and
triggers that reside in the target database.
The most important benefit of using such an approach
to develop business application proves itself well
when the application needs to be changed and
maintained. Because the complete information is
stored in one place – in the repository – modifications
can be easily made and the components can be
automatically regenerated. However, this presupposes
that the application is, and can be, 100% generated
from the repository information. What is 100%
generation is the questions that goes beyond the scope
of our discussion, however, who has ever tried such
tools knows that they are based on sophisticated
libraries and templates’ sets of classical business
applications modules.
4.2 Server-based tools
Another way of ensuring business rules is to
implement them in a manner of an application service.
An example of a product associated with this type of
approach is Usoft’s Developer, which like previous
database-independent tools assures that the
application is automatically derived from the business
rules (including implementation rules). However,
once the business rules are captured and stored in the
repository, no further programming is required to fire
and process those rules. All is automatically done by
the business rules processor. The tool also creates
both the database and the other required components
of three-tier architecture. Client-side applications
invoke objects, methods, or functions on the server
-5-
Such an approach brings additional advantages.
Developers do not need to worry about when the rules
need to be fired and in what order they should be
fired, because all this is handled by the rules
processor. Another important advantage is
technological independence. While the application
architecture follows the three-tier architecture industry
standard (known as ANSI/SPARC three-tier
architecture), the different components of a business
application remain independent. In this way, as better
technologies are developed to implement the separate
tiers, these new technologies can be “plugged in” to
supersede less efficient methods.
4.3 Rule – based systems
The development tools that belong to the third group
are all based on a specific rule language (rule-based
language) and special mechanisms (rule engines) that
take care of rule execution.
All procedural languages are built upon the
foundational concept of procedural flow, sometimes
called the control flow. Programs written in languages
like C, C++, Java, Basic, etc are all based on flow of
control. The text of such programs is executed left to
right, top to bottom, as the source code would be read.
If we know the statement of procedural code being
executed, we can always determine which statement
will be executed next.
The benefits of procedural languages are
predictability and the straightforward mapping to
today’s serial, Von Neuman architectures, which
make them very popular and widespread used
program languages [20]. However, they suffer from
being difficult to use. The fact is that if we want our
computer to compute something, we must first take all
the specifications and constrains out of the problem
and then organise them into a set of loops and
conditional sentences that correctly describe how the
computer should behave in the face of every problem
it might encounter. This, of course, is not an easy job,
otherwise there would be not shortage of software
engineers, and maintenance costs would be probably
much lower.
Mainly because of these difficulties, the alternative
approaches emerged. One example of a program
language that follows to a rather different philosophy
is a Rule-based language. The most important
characteristic that distinguish it from the procedural
language (beside that there is no control flow in the
rule-based language) is, that with a rule-based
language the system is responsible for mapping
specifications and constraints into executable code,
and not a software engineer. Unlike the procedural
languages, the rule based languages take independent
statements of if-then-else rules and automatically
integrate their if parts into a single, integrated and
efficient conditional logic, which is directly
executable by an inference engine. The inference
engine is the core of every rule-based system. It
monitors the applicability of the conditions of rule
against a database. Whenever the database changes,
whether by adding, deleting, or modifying a record in
the database, all the rules are checked and fired if
necessary.
Rule-bases languages have been used for a long time,
since they are in the core of every expert and
knowledge-based system. While they can be very
useful as a language for specifying conditional or
declarative knowledge, they prove also as business
rule-specification language. In fact, the findings of the
GIGA Information Group [4] tell us that “the interest
in business rules will fuel expand use of rule-based
systems in commercial applications”. According to
their declarations “the business rules products that are
easily integrated with a variety of languages,
platforms, and legacy systems will be the most
successful”. The ability of integration and coexistence
is actually the essential difference between the socalled expert systems products of the 1980s and
contemporary rules products. Those can be easily
integrated with different procedural program
languages, various databases, and even with leading
GUI tools. Neuron Data's Elements Expert and
ILOG's ILOG Rules are good examples of such
products.
-6-
App
Server
Database
Rules
Engine
GUI
DBMS
Business
Rule Base
Figure 4: Rule-based System
The classical rule-based system architecture is shown
in the figure 4.
There are many benefits of using rule-based systems
instead of conventional development tools, when
engineering systems for change. The most important
are gathered bellow.
Key benefits of rule-based systems
 Incremental development and rapid prototyping.




The rules can be run and tested the moment when
they are added to the system. Unlike in traditional
programming tools such as C++ or C, changes to
the rules do not require recompilation, re-linking
and re-deploying.
Understandable units of business practice. Rules in
the rule-base are self-contained chunks of logic,
representing single concepts. This helps their
readability and understandability.
No control flow. Unlike a conventional program
that usually has a single starting point and a set
sequence of execution, there is no control flow in a
rule-based approach. Rules can start to execute
from any point in the rule-base.
Consistency. In comparison to conventional code,
incomplete, incorrect, irrelevant or redundant rules
are much easier to be found, since they stick out
by the system.
Ability to work with incomplete and missing
information. In many business situations, it is not
always possible to provide complete and verifiable
data. Rule-based systems can deal with such cases
of incomplete information - rule engine is able to
work with special values "unknown" (not relevant
in case of particular calculation) and "not-known"
(the value is not known).
5 WHERE DO THE BUSINESS
RULE APPROACH FIT
when they are to decide, whether to use a traditional
and tested technologies or to be ambitious and take
risk with contemporary ones.
Business rule approach is an important system
development strategy that cuts across the lines of most
applications. However there are certain areas that
particularly fit for this kind of solution, such as when
you:
A lot of information concerning business rules
approach, business rule-oriented tools, organisations
and people can be found in [21].


6 CONCLUSION
have many decisions
have interrelated decisions: decisions that
depends on other decisions
would like to have individual services for every
customer,
frequently introduce new products and new
service offerings for customers,
need to support business rules that change
frequently
need flexible and easy-to-understand software
(user-maintainable)
need to understand how results are being
determined
Business environments exposed to rapid and intensive
changes are the major problem causing software
engineers to change, adapt and reengineer business
applications continually. While business rules are
used as a business-specification language to specify
policies and standards of enterprises, they need to be
described formally and incorporated into supporting
business applications. We have shown in the paper
that it is essential to address the business rules
properly and to deal with them in an appropriate
manner. The development process may otherwise
result in an application that is inflexible and hard to
change. Not to mention the maintenance costs that
may quickly become uncontrolled.
There is a large range of business lines that use rulesdriven solutions. The most typical are the following:
Business rules approach that has been introduced in
the paper follows this philosophy, forcing the
application developer to deal with business rules
explicitly. The tools based on such an approach
efficiently devise the business rules apart from the
other applications components, describing them in
both, business and formal language. There is no such
a tool, on the other hand, that would support the
intuitive path leading from definition to
implementation of business rules [9]. Once business
rules are articulated by business users, application
developers must still define these rules within the
application [3].









INSURANCE: new insurance products appear
constantly, customers are processed individually
TELECOMMUNICATIONS: billing rules are
customer oriented and are frequently updated
FINANCE: services highly depend on state
regulations, polices and various customer-related
facts
ELECTRONIC COMMERCE: computer-aided
selling, personalised services
Today, several development tool vendors offer their
systems, based on the business rule technologies [18,
19, 20, 21]. Majority of them are built around an
inference engine (rule-based systems) and usually
support not only the implementation of business rules,
but rule acquisition as well.
Although business rule approach is a promising and
interesting system development strategy, it is not as
present in a real world, as one would expect. One of
the main reasons for that is the price of the businessrule-oriented tools, which is rather high. Secondly,
there has not been yet any real comparison made (or
at least not published) between rule tools (using some
pre-defined list of criteria), what makes the evaluation
of technology difficult [22]. And ultimately, the
business rule-oriented technologies are still immature.
This has, of course, a great effect on IT professionals,
-7-
The reason business rules are not getting appropriate
attention within
the traditional application
development cycle, arise out of development
methodologies that do not handle business rules
systematically and in an accurate manner. Although
business rules are at the very heart of the structural
and behaviour models, built in analyses and design –
regardless of whether the analyst is taking traditional
or object-oriented approach – they are not fully
supported neither by traditional nor by object-oriented
methodologies [5].
Despite the fact that a business rules approach can be
used in a variety of situations, it may not be applicable
to all development needs. It must be emphasised that
business rules approach is not intended to replace
conventional development methods, but to
complement them. However, while engineering
systems that are ordinary update-intensive, such
approach comes at a price.
20. Original source: The Standish Group
International, The High Cost of Chaos,
http://www.standishgroup.com
7 REFERENCES
[13] Lawrence, B., Designers Must Do the Modeling!,
IEEE Software, March/April 1998, pg. 30-33.
[1] GUIDE International Corporation, Guide
Business Rules Project, Final Report, revision
1.2, October 1997,
[14] Marko Bajec, User Involvement in IS Analysis
and Design, Master Thesis, December 1998.
http://www.businessrulesgroup.org
[15] James Martin, James Odell, Object-Oriented
Methods, A Foundation, Prentice Hall, 1998.
[2] Jos B. Warmer, Anneke G. Kleppe, The Object
Constraint Language: Precise Modelling With
UML (Addison-Wesley Object Technology
Series), Addison-Wesley, 1999.
[16] Ronald G. Ross, The Business Rule Book:
Classifying, Defining and Modelling Rules, 1997.
[17] John Zachman, A Framework for Information
Systems Architecture, IBM Systems Journal, Vol.
26, No. 3, 1987.
[3] Michael Barnes, David Kelly, Play by the Rules,
Byte (Special Report), June 1997.
[4] John R. Rymer, Business Rules: A Promising
Technique, But Not a New Paradigm, Giga
Information Group, 1997,
[18] USOFT Inc., Business Rules Automation: A
Proven Approach and Software Technology to
Implement Computing Applications,
http://www.ilog.com/products/rules/analyst.cfm
http://www.usoft.com/whitepapers/business_rules
[5] Ellen Gottesdiener, OO Methodologies: Process
& Product Patterns, Component Strategies, Vol.
1, No. 5, 1998.
[19] Neuron Data, Inc., Architecting For Change: The
Rule-Engine Proposition,
[6] Judith Hurwitz, When Rules Meet Development,
DBMS, January 1997.
[20] The Haley Enterprise, Inc., Eclipsis User’s Guide,
http://www.neurondata.com
http://www.haley.com
[7] Mieczyslav Lech Owoc, Violetta Galant,
Validation of Rule-Based Systems Generated by
Classification Algorithms, Proceedings:
Information Systems Development – Evolution
and Challenges in System Development, pg. 459467, Plenum Publishers, New York, 1999.
[8] Karel Richta, Specification-Driven Maintenance
of Integrity Constraints, Proceedings: Information
Systems Development – Evolution and
Challenges in System Development, pg. 271280,Plenum Publishers, New York, 1999.
[9] Paul Dorsey, Business Rules – The Quest for the
Holy Grail, Dulcian Inc.,
www.dulcian.com/magazines
[10] Martin James, Application Development Without
Programmers, Savant Research Studies, 1981.
[11] Jeffrey A. Hoffer, Joey F. George, Joseph S.
Valacich, Modern Systems Analysis and Design,
(second edition), Addison-Wesley, 1999.
[12] The Standish, Few IS Projects Come In On Time,
On Budget, Computer World, 12 Dec. 1994, pg.
-8-
[21] Business Rule Solutions, Inc.
http://www.BRSolutions.com
[22] Keri Anderson Haley, Panel Discussion on The
Business Rules Approach in Practice, Originaly
presented at the 1998 Business Rules Forum,
Chicago, 3-5 November 1998.
http://www.brsolutions.com/dawnloads/panel.html