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:

1. Declarative (non-procedural);
2. Atomic (indivisible yet inclusive);
3. Expressed in natural language;
4. Distinct, independent constructs;
5. Business, not technology, oriented; and
6. 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