In-Depth
Business Rules show power, promise
- By Ellen Gottesdiener
- July 25, 2001
While a business rules approach can present many challenges to I/S development
managers, backers of the approach view it as an effective way to identify core
business requirements.
The term 'business rules' has different meanings for business and I/S professionals.
Within I/S, 'business rules' can have different connotations depending on whether
the perspective is 'data-oriented', 'object-oriented' or 'expert system-oriented.'
The elasticity of 'business rules' is further stretched by vendors using the
term in marketing literature and World-Wide Web sites. Nevertheless, 'business
rules' has become an accepted I/S buzzword.
An understanding of business rules is spreading, though it is still a newer
area of focus. Business rules are beginning to be recognized as a distinct concept,
practice, methodology and/or requirements technique.
This article will address several questions on business rules -- what they
are?; why they are important?; and how they are used? The article will also
examine the debates and products in the business rules world.
What is a business rule?
A business rule is "a statement that defines or constrains some aspect of
the business. It is intended to assert business structure or to control or influence
the behavior of the business." (See Reference
1.)
When a business rule statement is elicited from a business person, however,
it is often worded in an ambiguous, non-rigorous manner. In such a situation,
each business rule statement may actually decompose into numerous discrete business
rules. For example, a businessperson might state: "the total number of regulated
products sold in a country must not exceed the threshold defined by the regulatory
limits of the country of origin." This statement resembles 'business rambling,'
a term coined by Barbara von Halle, business rule expert and co-founder of Knowledge
Partners Inc., Mendham, N.J. This 'business rambling' statement contains many
discrete business rules. There are implied definitions ('regulated product',
'country',); derivations ('total number of ...', 'threshold', 'regulatory limit');
facts ('products sold in a country', 'limits defined by country of origin');
and constraints ('total' not exceeding 'threshold').
When decomposed to its most elementary form, a business rule is as atomic
(indivisible) as possible while still inclusive enough to be a complete thought.
A business rule does not contain control flow statements, such as notification,
database updates and sequence typically found in program logic. (See box,
"Procedural versus declarative.") An atomic business rule written in a declarative
(non-procedural) fashion, using standard grammar in a natural language that
business people can readily understand, is not ambiguous.
A business rule is independent of the modeling paradigm or technical platform.
A rule is defined and owned by business people. To summarize, business rules
are:
- Declarative (non-procedural);
- Atomic (indivisible yet inclusive);
- Expressed in natural language;
- Distinct, independent constructs;
- Business, not technology, oriented; and
- Business, not technology, owned.
Commercial enterprises are comprised of thousands of combinations of such
rules, which work at an operational level running the business. Business rules
define and control the life cycle of products and services and the supporting
infrastructure. Business rules direct how enterprises buy, create, sell, cultivate,
conform, employ, manufacture, research, report and plan. As such, they are the
core of the enterprise. (See Fig. 1.)
Fig. 1: Business Rules of an Enterprise
Business rules are the core of an enterprise
in that they direct how enterprises buy, create, sell, cultivate,
conform, employ, manufacture, research, report and plan.
Source: EBG Consulting Inc.
|
|
Ron Ross, editor, Database Newsletter and author of "The Business Rule
Book" (See Reference 2.), likens business rules to
the periodic table of elements. In fact, he has devised an atomic chart of several
dozen rule types. These atomic rule types can be combined to form an unlimited
number of compound rule types, which he calls derivatives. "Individual business
rules make a business understandable, but it's their chemistry that brings it
to life," said Ross. >p> Articles on business rules began to appear during the
early 1990s. Today, there are publications dedicated to business rules and business
rule tools. In addition, there are seminars and a conference on business rules.
An active guide committee completed a three-year effort and published its first
white paper on business rules in 1995. Industry analysts are beginning to write
about business rules and related tools. Large corporations, particularly in
the insurance, finance and banking industries are beginning to invest in building
or buying business rule servers.
Business rules and expert systems
The fields of business rules and expert systems do overlap. (See box,
"Rule-based systems have roots in AI.") "Rules have been
used extensively as a way to represent knowledge by the Artificial Intelligence
(AI) community since the late 1960s. In the 1970s, expert systems emerged as
an identifiable part of AI and logic began to be used as a programming language
(Prolog)," said Margaret Thorpe, president of Tangram, a Washington D.C. consulting
firm. Traditionally, expert systems have been used to derive or confirm knowledge
based on a complex network of rules. They have not traditionally been associated
with operational systems, but that is changing as they become embedded in more
conventional business applications. "Business rules are something that by and
large are enforced in real time. You want to influence and control behavior
as the business occurs," said Ross.
The technology underlying expert systems may be one way to automate business
rules, based on the success of the Knowledge Acquisition and Rule Management
Assistant (Karma) application at the Federal National Mortgage Association (Fannie
Mae), Washington D.C. (See box, "Fannie Mae's Karma helps
to get to rules.") Karma's Business Rule Server provides business rule validation
for Fannie Mae loan applications.
I/S attraction to business rules
Business rules can offer several benefits, including: technical independence;
faster application development; better quality requirements; ease of change;
and a balance between flexibility and centralized control. The approach starts
with a core -- business rules defined by business people. "Business rules are
understandable to business people more than any other component we have used
in developing systems," says von Halle of Knowledge Partners. Business rules
place business people at the center of any software activity. "The business
rules approach seeks to be a true integration between business people and technology,"
echoed Bonnie O'Neil, director of data warehousing and business rules at Northern
Lights, a Saratoga Springs, N.Y., consulting firm.
Allowing business rules to be defined and managed separately, and tying software
engineering into them by generating and maintaining applications from the business
rules, has great potential for evolving the I/S state of the art. The idea of
'separation' is not new. The value of separating business rules from data and
presentation is central to the much discussed three- or n-tier logical client/server
application architecture (See Fig. 4.) Separating business rules from
the data and presentation layers facilitates change, promotes reuse and permits
heterogeneity and scalability of the technical architecture.
However, what is often meant when vendors and analysts reference such an ideal
architecture is application logic, not declarative business rules. They frequently
mean procedural code, within which business rules are embedded. Some products
that claim to provide separate business rule management have, in the proprietary
'business rules' specification, language which includes procedural verbs, for
example: 'Call', 'Get', 'Forall', 'Replace', 'Display,' and 'Execute.' Thus
the 'business rules' are not separately managed (e.g. in a repository) nor are
they non-declarative.
The widely used term 'business rules' is further diffused when database facilities
are touted as business rules management. Database triggers and procedures are
used to implement certain types of business rules, such as facts, constraints,
actions, enablers and derivations. Triggers, for example, are commonly used
to enforce referential integrity, a constraint type of rule (for example, "an
order must be placed by only one customer,") which is translated into database
events (such as an order is being inserted or deleted). Stored procedures and
triggers enhance application performance. They violate the ideal of separating
logical application layers by coupling business rules to a particular database.
Separation yields flexibility. Business rules should be logically separated
into what Bonnie O'Neil, calls "a virtual tier." This tier can be moved to any
technical platform that suits the application's performance and platform requirements.
"The business rule layer can be physically implemented anywhere, but logically
resides between the interface and data layers," said von Halle.
Fig 3: Modeling points of view
Business rules break away from the traditional
point of view to look at requirements as a set of business rules
that must be enforced.
Source: EBG Consulting Inc.
|
|
Changes in policies, regulations, recipes, standards, formulas or any other
precept of the business causes changes to one or more atomic business rules.
A business rule approach which has captured and automated those business rules
should provide the flexibility to change the rule immediately and propagate
it throughout the software applications that subscribe to the rule. Additionally,
a business rule approach has huge potential for re-thinking how to business
process reengineer. "Business rules allow you to address key business constraints
independently of responsibility -- who is responsible?, where they are enforced?
and so on. By doing so, you are in a position to re-optimize the rules," said
Ron Ross.
The business rule approach is evolving due to the increased complexity of
business and system development environments, said Tangram's Thorpe. "We have
different applications, running on different platforms, developed using different
methodologies, coded in different programming languages and accessing a variety
of DBMSs. The business requirements are rarely maintained at the level of the
business model or the specification. As a result, we have business logic replicated
and buried throughout systems, oftentimes out of synch. The business rule approach
holds the promise of consistency and control of both specified and implemented
business requirements," Thorpe said.
Although I/S may suggest implementing a business rule approach, business people
are the sponsors and benefactors. They readily understand the benefits from
ease of use gains and improved communications. An additional benefit is speed
of change. "Giving the business community the tools to quickly define, modify
and check business rules for consistency as well as to get those changes quickly
implemented in the production environment has made them able to respond much
more quickly to changes in the business environment," said Thorpe.
The "P" word
Depending on whether one's orientation is object-oriented, data-oriented,
business process-oriented or something else, business rules may or may not represent
a new I/S paradigm. Enthusiasts see a business rule approach as a new paradigm
for thinking about and organizing models and information systems. (See Fig.
5.) Some in the 'data' world debate the new paradigm suggestion since they
have traditionally been representing business rules in data models and they
usually capture other types of business rules in documentation. "Accommodating
business rules is not a paradigm shift, but something we've been doing all along,"
said Tom Bruce, principal of Tabset, a Berkeley, Calif., consultant, and author
of "Designing Quality Databases with IDEF1X Information Models." (See Reference
3.)
The weakness in using solely a data modeling approach is clear. "In information
modeling, we can do a good job of capturing business rules as part of defining
entities, attributes and cardinality," said Bruce. "What we don't do a great
job of is defining rules like 'checking account can be provided overdraft protection
by a credit card only if the account and credit card has a common owner.' Such
rule types are not accommodated in model graphics. Most data modelers will notice
this and pass it on -- in lists of rules or somewhere else."
Interestingly, many of the foremost promoters of the business rule approach
hail from the data modeling community. "Data modeling is disciplined. In addition,
business rules are a shared resource, like data," observed von Halle. "Unlike
other systems development approaches, the need evolved from the business and
from people experienced with I/S methodologies. Adaptability is a central need
of the business," added Ross.
Object proponents disagree on where to put the business rules in object/class
models. Some believe that rules are already implied in the model. Still others
in the object-oriented modeling community are working to synergize numerous
paradigms, including business rules. (See box, "Merging data and object
models with business rules.")
Dan Tasker, senior I/S consultant in the systems integration unit of Air New
Zealand, Auckland, New Zealand, and author of "The Problem Space." (See Reference
4.), notes: "Each paradigm has a specific set of 'constructs' which it defines
and utilizes to model something. No single paradigm covers all aspects. For
example, data modeling, and object modeling, do a poor job of modeling the event
perspective. Event models do a good job of modeling events, but have limited
ability to describe data. The rule paradigm has, as its primary strength, modeling
conditions, but is not strong in the area of workflow. By their nature, we want
our rules to be declarative, leaving the issue of 'how' hidden or left to the
implementation," said Tasker.
Business rules as part of requirements gathering and application enforcement
have not been ignored by data, object, information engineering or other methodologies.
Those methodologies, to varying degrees, subsume or represent business rules
as part of notation schemes used to specify application requirements. Business
rules are not data, domains, object, classes, messages, events, procedures or
actions. Business rules, says Barbara von Halle, "just are."
"Business rules are a classic paradigm integrator which enable you to 'cross
paradigms' between object-oriented modeling and relational design," said O'Neil.
"Most other shifts like Information Engineering and object-orientation involved
technology only, and for the most part, are invisible to business people. I/S
doesn't need another modeling paradigm. The key is being able to express the
business in terms everyone -- I/S and business -- can understand."
Defining requirements for application development has traditionally focused
on a combination of data and process or on objects which encapsulate data and
process. Business rules break away from those points of view, putting business
rules in the center. (See Fig. 3.) The approach asks business and I/S
people to look at requirements differently -- as a set of business rules that
must be enforced. These same rules, however, may change at any time due to external
forces or internal policy changes. This presents an opportunity to express and
think about those requirements in a different way.
Table 1: Examples of uses of expert systems
Source: EBG Consulting Inc.
|
Industry |
Use |
Construction |
*Cost control and financial planning of costs involved in construction,
planning and maintenance of commercial and residential buildings
*Geotechnical data interpretation; determining suitability of soil
properties in design based on soil test results and descriptions |
Civil Engineering |
*Power usage/demand of hydroelectric plant operation *Determining
dam safety based on signal traces from the dam
*Diagnosis of fault conditions in power stations
*Noise signals from nuclear reactors |
Medical Diagnostics |
*Interpretations of signals from respiration monitoring
*Interpretation of acoustic signals from fetal heart
*Interpretation of capnograms (carbon dioxide waveforms) of anaesthetised
patients |
Insurance |
*Determining insurance risk from actuarial data
*Commercial underwriting |
Airline Maintenance |
*Parts specification
*Installation timing, priorities |
Investments |
*Stock, bond, money-market, market induces data |
Loan |
*Loan risk factor, underwriting |
Credit |
*Credit checking, detecting stolen credit cards |
Legal |
*Risk assessment in securities law |
Manufacturing Logistics |
*New product planning based on bills of materials and allowable
component configurations |
Retail |
*Spending patterns |
|
Business rule templates
A solid application architecture is based on well-designed models, such as
data, process or class models. Rather than building the models from scratch,
I/S can buy the models from a third-party, tweak them for a specific business
and then generate software using a CASE tool. (See Reference
5.) This presents opportunities for implementing a business rules approach.
"I hope we'll start seeing templates which include data models and business
rules as deliverables. Then analysts can go in and change the templates and
customize the package," said von Halle.
IBM's Insurance Application Architecture (IAA) template uses the construct
of business rules. The IAA, first shipped in 1992 and eventually licensed to
25 sites worldwide, was created by a consortium of 40 insurance companies in
a project coordinated by IBM. IAA templates include three models: a data model
with some 170 entities; a function model with about 500 functions; and a function
flow model describing events, control flow and data conditions.
The IAA data model separates business rules in two entities for generalized
treatment -- Classification and Specification. Rules around each data element
are stored in the Classification entity and can be combined and rolled-up using
the Specification entity to form complex business rules. A set of Classifications
such as "customer that owns two vehicles"; "a minivan vehicle" are used to define
a Specification such as a product with certain coverages and services. In this
way, the Classification and Specification entities are used to store business
rules and permit their reuse.
Business customers and I/S, working with the IAA Classifications Manager (a
CASE-like tool) in Joint Applications Design (JAD) -facilitated sessions, define
and model product-specific business entities. The IAA separately handles derivation
rules within the function flow model as part of procedural logic.
In addition to the interest of business customers to manage a business at
a business rule level, sales of IAA have been driven by business process reengineering
(BPR), said Tom Romeo, asset manager in IBM's Insurance Solutions Department.
"Reuse should come from the business process level. Reuse is not coming from
relational technology. We need a model that is abstracted and has business rules
separated from business classes."
Business rule automation
"Having the rules doesn't really help that much if you don't have an automated
way to enforce them," said O'Neil of Northern Lights. Vendors that have added
the term 'business rules' to product descriptions vary in how they interpret
the term. In fact, many of the products provide incomplete and non-integrated
support for business rules. Some use the term to describe how a tool implements
business logic (procedural code). Few actually implement rules in a business
rule repository. (See Table 1.)
Application Generators that integrate business rules
ObjectStar from Antares Alliance Group, Dallas, generates applications using
a proprietary business rules language which reads like conditional statements,
according to Erika Kelly, systems supervisor at the Farm Bureau, an Indianapolis,
Ind., insurance firm. Farm Bureau selected the ObjectStar tools to extend its
mainframe applications so the software can be moved to client/server environments
when necessary. The Farm Bureau will continue running mainframe software for
data management and business processing services.
Fig. 4: Three-tier client/server architecture
Separating business rules from the data and
presentation layers facilitates change, promotes reuse and permits
heterogeneity and scalability of the technical architecture.
Source: EBG Consulting Inc.
|
|
ObjectPool from Sapiens, Tel Aviv, Israel, encapuslates business rules within
models it calls objects. The tool includes five types of rules, including two
that are more procedural. ObjectPool rules are: local check rules which validate
domain values; local computation rules which declaratively define algorithms;
and derivation rules which constrain or trigger actions. The procedural are: Call
and Fetch. ObjectPool has a GUI painter and a repository for storing rules. The
tool uses a proprietary inference engine to execute rules. The declarative approach
yields less code, said Peter Barber, executive vice president of Sapiens' North
American unit, based in Raleigh, N.C. For example, one Cobol application rebuilt
using ObjectPool required one-third the lines of code of the original, he said.
Performer, a model-driven application development tool from Texas Instruments
Inc., Plano, Texas, promotes business rules. Performer produces models that
are rooted in information engineering techniques -- data model, logic design
(essentially structured pseudo-code) and window navigation. The logic design
portion of the tool is promoted as managing business rules, but is actually
a scripting language comprised of some 40 verbs, both declarative and procedural.
Code is generated by models stored in the repository.
Repository-driven application generators
Two products stand out for automating declarative business rules using a centralized
repository: Vision Builder from Vision Software, Oakland, Calif., and Usoft
Developer from Usoft Corp., Brisbane, Calif. The Vision Software and Usoft tools
are based on different architectures and can be coupled to different products.
But both use the notion of declarative business rules and a business rules 'engine'
to drive the development process and permit automatic regeneration of application
components based on business rules.
Vision Builder uses three views, or logical layers -- presentation, business
rules and data -- to build multitier client/server applications. The presentation
layer uses Visual Basic or Vision Builder's own screen painter. Business rules
are defined as triggers and stored procedures, and are imported from CASE tools,
or as declarative statements captured in Vision Builder's Business Rules Designer.
The Designer facility captures rules in an English-like format using a set of
tabbed pages based on validation rules (domain checking on columns), derivation
rules (calculations), relationship rules (referential integrity enforcement)
and conditional action rules ("if" checks or circumstances for executing stored
procedures). The data layer is defined by the database structure which can also
be imported from a CASE tool or generated in the product itself.
Fig. 5: Paradigm shifts
Enthusiasts see a business rule approach as a
new paradigm for thinking about and organizing models and information
systems.
Source: Terry Moriarty
|
|
The Vision Builder repository is built on Microsoft Access. Business rules
on the client are implemented as Visual Basic code or Java-based HTML. The middle
tier is generated as Visual Basic and C++ code. Business rules on the data layer
are implemented as triggers and stored procedures using SQL Server or Oracle
on the server.
Usoft Developer uses business rules as the central paradigm for all aspects
of a development life cycle. Using a data model and declarative business rules
written in Ansi standard SQL, Usoft Developer builds multitier, distributed
client/server and Web-based applications. In addition to partitioning capabilities,
Usoft exploits the use of a centralized repository to control the application.
The repository is the source for generating data schema, business rules enforcement
and presentation layers.
While Vision Builder uses database stored procedures and triggers, Usoft Developer
uses a 'rules engine,' which generates application code for all tiers. Create-read-update-delete
(Crud) -related rules, including referential integrity, are generated by the
engine. The engine uses rules from the repository as a parameter for controlling
the runtime environment. All business rules are added, modified and retired
only through the centralized repository.
"It's not another tool, it's another way of doing work," says Bob Brown, vice
president for business improvement and I/S at Burlington Klopman Fabrics, a
division of Burlington Industries, Greensboro, N.C. The division is using Usoft
to migrate code into flexible, multitier client/server applications.
Usoft Developer is changing the way Burlington Klopman builds applications,
not only by focusing on up-front data modeling and business rules analysis,
but also by shaving months-long projects into weeks. "The business rules are
not old and obsolete. The processes in the systems that use the rules are old
and obsolete. Defining business rules does not mean we are going to do business
differently. That's a fallacy. Usoft lets you re-architect systems and then
modify how you do business, if you want to," said Brown.
Table 2: Sample business rules taxonomies
Source: EBG Consulting Inc.
|
Source |
Taxonomy |
Guide Business Rules Project |
*Structural Assertion (terms, facts)
*Action Assertions (integrity constraints, conditions, authorizations)
*Derivations (calculations, inferences) |
Ron Ross, Database Research Group |
*facts
*terms
*rules (constraints, derivations, inferences, timing, sequence, heuristics) |
James Odell, Independent Consultant |
*Constraints: (stimulus/response, operation, structure)
*Derivations: (inferences, compulations) notes: rules can be global,
local and/or
temporal |
Tom Romeo, IBM |
*structural (relationships, domains), cardinality, optionality,
*behavioral (pre-conditions, post conditions, derivations) |
Margaret Thorpe, Tangram |
*definitions
*basic integrity constraints
*general declarative constraints
*procedural constraints
*inferential
*derivation |
Barbara von Halle, Knowledge Partners |
*definitions
*facts
*constraints
*derivations
*inferences |
Usoft Corp. |
*restriction (constraints, domain)
*deduction
*behavioral
*representation |
Dan Tasker, Air New Zealand |
*action restricting
*action triggering
*constraint |
Brightware |
*business
*policy
*workflow
*decision heuristics |
Vision Software |
*validation
derivation
relationship
conditional actions |
|
Burlington Klopman's approach for extrapolating business rules of business
users called first for creating an English language process flow model of the
current system. I/S determined the business owners of the rules defined in the
flows and then validated the rules by implementing them in Usoft Developer prototypes.
Teams of three to five developers work in 90-day chunks to develop applications.
"You need to want to make the paradigm shift to business rules," said Brown.
"This means you do not want 'stovepipe' applications to spread throughout the
enterprise."
The Texas Department of Health's Vendor Drug Program built its Pharmacy Rebate
Information Management System using the Usoft tool. The system handles pharmacy
rebate billing, collections and data query and analysis for statewide usage
of prescription medication by Medicaid-eligible recipients. Usoft Developer
was picked to build applications that can respond quickly to changing policies
and guidelines from federal and state agencies, said Andy Vasquez, the health
department's I/S Manager.
Development began by validating the conceptual design in JAD sessions with
customers. The data model was designed using Usoft Developer's data modeling
facility. Functional requirements were recorded using a word processor. Subsequently,
the business rules were extracted from the functional requirements, validated
with business users and used as the basis for defining the business rules in
Usoft Developer. The functional requirements also served as a basis for determining
test criteria. "Using Usoft's iterative methodology, the migration of rules
to working prototype was quick. End users were very responsive to this approach,"
said Vasquez.
Moving to business rules
Business rules are categorized in different ways. (See Table 2.) There
is also no standard for expressing atomic business rules. "I believe a taxonomy
is not as important as business rule grammar," said Northern Lights' O'Neil.
"The key to this grammar is rigorous definitions. We are working to bridge that
gap by building a tool that grammatically represents declarative business rules.
This way, business people can directly modify a rule which is then loaded into
a business rule repository."
Regardless of which categories or formalism is used, discovering and eliciting
business rules must be integrated into the development life cycle. Business
rule enthusiasts have different approaches for weaving the rules into the process.
"I knew the industry needed a proof that it's possible to state rules independently
of how or where they are enforced. Now there are tools available to implement
business rules. The next step is to have a business rule methodology," said
author Ross.
Business rule analysis or modeling, especially when coupled with a business
rule automation tool, accelerates the software development life cycle. "Business
rule modeling alone helps reduce business ramblings about requirements into
meaningful English language statements that are easily verifiable by business
people," said O'Neil. "If done properly, it will extend requirements gathering
forever, so systems are always up to date and flexible. In this way, applications
change instantaneously with changes in business rules."
Warren Keuffel, editor of the Business Rules Alert! (See Reference
6.) newsletter, contends: "If you're going to build a system using business
rules, and if you're going to use a tool that supports business rules, requirements
tracability is an absolute necessity. If you follow half-baked methodologies
that pay lip service to business rules, or employ tools that add business rule
support in a superficial manner, you've lost before you started, and 'business
rules' can become another almost meaningless buzzword, like object orientation
and groupware."
Making the transition to a business rule approach requires business commitment.
Business people are responsible for defining and maintaining business rules.
Ironically, when defining business rules in facilitated sessions, I have discovered
that business people themselves often have a conflicting or foggy concept of
the myriad rules that govern their business. (See Reference
7.)
In addition to conflicting and ambiguous business rules, exposing the business
through business rule modeling inevitably reveals what Barbara von Halle calls
"suboptimal business rules." Suboptimal rules provide excellent, but often politically
charged, business reengineering opportunities.
These phenomena are not new to analysts or modelers seeking to define a business
with some notation or formalism. Resolving deficiencies and conflicts and making
decisions about business rules require strong and continued business ownership.
Enabling better questions
With opportunities to use a business rule approach, one can experience the
power and promise of the business rule paradigm. Working with business and I/S
personnel, focusing on business rules is both difficult and complex while simultaneously
being a liberating endeavor.
The cliché 'paradigm shift' was introduced by physicist turned historian Thomas
Kuhn. His notion was that at significant points in time, practitioners of science
can undergo a transformation of vision, which can alter or shift an established
reference framework. "It is rather as if the professional community has been
suddenly transported to another planet where familiar objects are seen in a
different light and are joined by unfamiliar ones as well," said Kuhn. (See
Reference 8.)
Business rules are really a familiar concept. When viewed then from a different
perspective, however, one can center them and then bind them with existing elements
and goals of software applications -- separation, flexibility, business ownership,
model-driven development, reengineering, rapid development and enforcement.
Business rules can now be seen in a new light. Paradigm shifts do not necessarily
provide new answers. They represent new frameworks which enlighten existing
notions and help to raise better questions. In this sense, a business rule approach
enables better questions, a redefinition of application design constructs and
the eliciting of business requirements in new and innovative ways.
Table 3: Representative sampling of business rule tools
Source: EBG Consulting Inc.
|
Vendor |
Product
|
Business Rule-Repository Based Applications
Generators |
Usoft
Brisbane, Calif. |
Usoft Developer |
Vision Software
Oakland, Calif. |
Vision Builder |
Knowledge-based/Expert System Application
Generators |
Brightware
Novato, Calif. |
ART*Enterprise |
Intellicorp
Mountain View, Calif. |
LiveModel |
Intelligent Environments
Burlington, Mass. |
Applications Management |
Neuron Data
Palo Alto, Calif. |
Elements |
Platinum Technology
Oakbrook Terrace, Ill. |
AionDSRule Server |
Applications Generators that use Business
rule specification/Modeling |
Antares Alliance Group
Dallas |
ObjectStar |
Dynamics Research Corp.
Andover, Mass. |
Visual Magic |
Magic Software Enterprises, Inc.
Burlington, Mass. |
Magic |
Sapiens
Durham, N.C. |
ObjectPool |
Texas Instruments
Plano, Texas |
Performer/Composer |
Business Rule Extraction of Legacy Applications |
ReGenisys Corp.
Phoenix, Ariz. |
rulefind:R and analyze:r |
McCabe & Associates
Columbia, Md. |
Slice Tool |
Case Tool for Business Rules |
Asymetrix
Bellevue, Wash. |
rInfoModeler |
References
1. Guide Business Rules Project, Final Report, 11/95.
2. Ross, Ronald, "The Business Rule Book: Classifying, Defining and Modeling
Rules," Database Research Group, 2nd edition, 1997.
3. Bruce, Thomas, A., "Designing Quality Databases with IDEF1X Information
Models," Dorset House, 1992.
4. Tasker, Dan, "The Problem Space: Practical Techniques for Gathering and
Specifying Requirements using Objects, Events, Rules, Participants and Locations,"
1993, electronic book, self-published by the author: Dan Tasker, 100241.2337
@compuserve.com
5. Gottesdiener, Ellen, "RAD Realities: Beyond the Hype to How RAD Really
Works," Application Development Trends, August, 1995, vol. 2, no. 8.
6. Business Rules Alert!, Database Research Group, Inc.
7. Gottesdiener, Ellen, "Facilitated Business Rule Workshops: 12 Guidelines
for Success," Database Newsletter, Jan/Feb, 1997, vol. 25, no. 1.
8. Gleick, James, "The Paradigm Shifts," New York Times Magazine, p.
25, December 29, 1996
9. Sobieski, J, Krovvidy, S, McClintock, C., and Thorpe, M. "KARMA: Managing
Business rules from Specification to Implementation," paper presented at American
Association of Artificial Intelligence Conference, Innovative Applications of
AI track, Portland, Ore., 7/96.
10. Business Rule Summit, February 26-28, 1996, Miller Freeman Inc., 600 Harrison
Street, SanFrancisco, Calif. 94107.
11.Database Newsletter, Database Research Group, Inc.
12. Gottesdiener, Ellen, and von Halle, Barbara, "Breaking the Rules On Purpose:
(An Introduction to the 'whys and hows' of facilitated rule breaking)," Database
Programming & Design, September, 1996, pp.9-12, vol. 9. No. 9
13. Hurwitz, Judith, "When Rules Meet Development," DBMS Magazine,
January, 1997.
14. Kara, Dan, "Rules-based tools: business rule specification is job 1,"
Application Development Trends, November. 1996.
15. Moriarty, Terry, "The Next Paradigm," Database Programming & Design,
February, 1993.
16. Odell, James, "Business Rules," Object Magazine, republished in
Wisdom of the Gurus: A Vision for Object Technology, Charles Bowman, ed., Sigs,
1996.
17. Ross, Ronald G. and von Halle, Barbara, "The Business Rules Approach,"
Addison-Wesley Publishing Company, to be published in 1997.
18. Seybold, Patricia, "Start Your Business Rules Engine," Computerworld,
December 9, 1996.
19. Seybold, Patricia, "My Love Affair with Business Rules: Separating Business
Rules from Application Logic," Distributed Computing Monitor, December 1996,
Vol. 11, No. 12.
20. von Halle, Barbara, "Data Architect" column covering business rules, Database
Programming & Design, Miller Freeman, http://www.dbpd.com
21. Wright, David, "Business Rules," Data Management Review, December,
1996, http://www.dmreview.com