Everything You Ever Wanted to Know about Business Rules
Abstract
This paper is the result of a personal investigation on Business Rules (BR). Last year, when I presented a paper about a custom solution for the documentation and coding of BR, I thought I knew enough about them. Then, I began to investigate a bit more, and I discovered that there was much more than I thought. But then, the search wasn’t easy. There were resources, for sure, but not any easy spot that covered everything I wanted to know. So I decided it would actually be good to try to have some resource of this kind, that would help whoever wanted to know that same information to achieve it easier and faster.
So, this is what this paper is about: the general ideas on BR, the products, articles, authors, books, technologies, and bits and bouts I found and was able to put here. I warn you reader: now I know there is even much more to know! So, this paper is not perfect, and for sure not really up to its title! It is my personal vision of it all, and it probably has its share of mistakes in it. I apologize in advance if I don’t render the authors or products as they really deserve. Let it be said that this is just and only the result of my personal investigation, most of it from over the internet, at night times, without direct contacts with the products or practitioners, expressed in my own way, and that it must be read and taken in account as such. </disclaimer> I hope you find it helpful and enjoy it.
(Note: an informal survey on BR was conducted on the ODTUG mailing lists. Some of the most relevant results are indicated here. The full results are available on my personal web page).
Business Rules – What are they?
BR: Some definitions
Let’s start with basics. Over the years, BR have been defined and redefined. Here are some definitions from recognized practitioners and organizations, from all times:
“In my opinion, a business rule is a constraint placed upon the business“ – Terry Moriarty, 1993 [Moriarty 1].
“An explicit statement stipulating a condition that must exist in a business information environment for information extracted from that environment to be consistent with business policy” - Daniel Appleton, cited in [Moriarty 1].
“Natural language sentences that describe data requirements to the business users” - Barbara von Halle and Alice Sandifer, cited in [Moriarty 1].
“... a discrete operational business policy or practice. A business rule may be considered a user requirement that is expressed in non-procedural and non-technical form (usually textual statements)... A business rule represents a statement about business behavior...” - Ronald G. Ross, 1994 [Ross 1].
“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” – GUIDE Business Rules Project, 1995 [GUIDE 1].
“A term, fact (type) or rule...” – Ronald G. Ross, 1997 [Ross 2].
“A Business Rule is a directive that is intended to influence or guide business behavior. Such directives exist in support of business policy, which is formulated in response to risks, threats or opportunities”- Business Rules Group. 2000 [BRG]
“An atomic piece of reusable business logic, specified declaratively” - Ronald G. Ross and Gladys S. W. Lam, 2000 [Ross 3], BRSolutions, the BRS Business Rule Methodology, 2000.
So, what do these definitions tell us? Quite a lot actually: BR are constraints, conditions, data requirements, business policies or practices, statements that define or constrain, user requirements; they assert, control and influence; they are terms, facts and rules; directives, business logic. Anything else?
Yes, BR can be a lot of things, but all in all, everything revolves around the same thing. As Ellen Gottesdiener puts it: “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” [Gottesdiener]
What they really are
So, there it
is, BR is now an accepted buzzword, so we can confidently use it, even if we
can’t remember all these definitions. Just in case, if we are not yet too sure,
Ronald G. Ross clarifies in an interesting article [Ross 4], what BR are, and
to begin with, what they are not. BR,
he says, are not software. Nor are they process, “in any sense of the word”. BR
represent the “know”, or the motivation, the “why” things are done the way they
are. And that has to be separated from the flow, the what, where, when and
etc. That ‘know’ part of the business
processes is the
A Framework for understanding
That is
actually nicely represented in a famous framework created by John A. Zachman many years ago. The framework is “a logical
structure for classifying and organizing the descriptive representations of an
|
|
Data What |
Function How |
Network Where |
People Who |
Time When |
Motivation Why |
|
Scope (Contextual) Planner |
List of things important to
the business Entity= Class of Business
Thing |
List of processes the
business performs Function= Class of Business
Process |
List of locations in which
the business operates Node= Major Business
Location |
List of organizations
important to the business People= Major Organizations |
List of events significant
to the business Time= Major Business Event |
List of business Goals/Strategies Ends/Means= Major Bus.
Goal/Critical Success Factor |
|
Enterprise Model (Conceptual) Owner |
e.g. Semantic Model Ent= Data Entity Reln= Bus. Relationship |
e.g. Business Process Model Proc= Business Process I/O= Business Resources |
e.g. Business Logistics
System Node= Business Location Link= Business Linkage |
e.g. Work Flow Model People= Organization Unit Work= Work Product |
e.g. Master Schedule Time= Business Event Cycle= Business Cycle |
e.g. Business Plan End= Business Objective Means= Business Strategy |
|
System Model (Logical) Designer |
E.g. Logical Data Model Ent= Data Entity Reln= Data Relationship |
e.g. Application
Architecture Proc= Application Function I/O= User Views |
e.g. Distributed System
Architecture Node= I/S Function Link= Line Characteristics |
e.g. Human Interface
Architecture People= Role Work= Deliverable |
e.g. Processing Structure Time= System event Cycle= Component Cycle |
e.g. Business Rule Model End= Structural Assertion Means= Action Assertion |
|
Technology Model (Physical) Builder |
E.g. Physical Data Model Ent= Segment / table / etc. Reln= Pointer / Key / etc. |
e.g. System Design Proc= Computer Function I/O= Data Elements/Sets |
e.g. Technology
Architecture Node= Hardware / System
Software Link= Line Specifications |
e.g. Presentation
Architecture People= User Work= Screen Format |
E.g. Processing Structure Time= System Event Cycle= Component Cycle |
e.g. Rule Design End= Condition Means= Action |
|
Detailed Representations (Out of Context) Sub-Contractor |
E.g. Data Definition Ent= Field Reln= Address |
e.g. Program Proc= Language Stmt I/O= Control Block |
e.g. Network Architecture Node= Addresses Link= Protocols |
e.g. Security Architecture People= Identity Work= Job |
e.g. Timing Definition Time= Interrupt Cycle= Machine Cycle |
e.g. Rule Specification End= Sub-condition Means= Step |
|
Functioning |
e.g. DATA |
e.g. FUNCTION |
e.g. NETWORK |
e.g. ORGANIZATION |
e.g. SCHEDULE |
e.g. STRATEGY |
Table 1 – The Zachman Framework
In this framework, the rows represent the different perspectives that are found in any organization with respect to information systems (Planner, Owner, Designer, Builder, Sub-Contractor)[1]. The columns represent product abstractions: Data (What), Function (How), Network (Where), People (Who), Time (When), and Motivation (Why). Each cell is an “artifact”, handled by the appropriate role player from its perspective. The framework is neutral with regard to the processes or tools used for producing the descriptions. (In table 1 you will see that examples are given for every cell, but these are just that: examples).
The Framework so, is a map of our enterprise. There, is stuff with which we usually identify clearly, and other that we might not. Things (columns) that most of us usually deal with in clear, obvious ways are for examples Data and Function. ER and DFD diagrams among others, are widely known techniques that can be used for these columns at the perspective of the Architect. The Network and People columns are pretty clear too. The Time column might not be used by everybody. And then there is the Motivation column. That is the one we care about here. See why by reading the examples in each cell: List of Business Goals/Strategies; business plan; business rule model; rule design; rule specification.
The beauty of this model (in this case) is in that it prescribes a dimension of its own for the BR, putting them in a framework where they cooperate with our other “already-known” elements like Data and Function. Assuming we accept this framework as a good idea (and many have been doing this for a long time already), it brings several insights on the BR:
1. BR are a dimension of their own, not mixed nor included in Data or Function.
2. They are not a particular technique or technology either (how many alternatives to ER or DFD do you know?).
3. There are several (6 in this case) visions of them, different perspectives (just like for the other columns). Each will require its corresponding techniques, tools, definitions, vocabulary, etc, just like it is happening in the other columns.
4. Just like Function and Data cooperate in ways we are sure aware of, so do the BR with these (and the other columns as well).
What I mean here is that this BR buzzword doesn’t mean that the industry discovered yet another new silver bullet that will replace everything we know so far. For one thing, it is not a silver bullet, and beside that, it will not replace but add to the things we know already, enriching our models and techniques, making them more complete, efficient, and easier. Just like the other paradigms actually...
As to what the correct definition of BR might be, well, maybe we need six of them, one for each row of the framework, but for now, we could just use two of them. The first paper of GUIDE is widely accepted and referenced. It was written from a row 3 (designer’s view) perspective while the following paper (now from the Business Rules Group) is written from the row 2 perspective (Owner’s view). Let’s use these two definitions for these rows.
Row 2/Owner’s view: “A Business Rule is a directive that is intended to influence or guide business behavior. Such directives exist in support of business policy, which is formulated in response to risks, threats or opportunities”.
Row 3/Designer’s view: “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”
We would in theory still need some definitions for the remaining 4 rows, but I guess these ones cover the matter pretty much enough.
But is it New at least?
BR are nor new nor old. In fact, we have always been dealing with them, but for the majority of us, we have not been treating them like the resource of their own that they are: buried in code, or in workflow descriptions, they were everywhere, and then, nowhere.
Ellen Gottesdiener says: “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 the notation schemes use to specify application requirements. Business rules are not data, domains, object, classes, messages, events, procedures, or actions. They as Barbara von Halle says, ‘just are’”
“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 our existing notions and help us to raise better questions. In this sense, a business rule approach enable better questions, a redefinition of application design constructs and the eliciting of business requirements in new and innovative ways” [Gottesdiener].
What is relatively new to all this is the attention that BR are receiving and the quantity of products available on the market that claim to be BR oriented in some or other way. Subsuming all this then, BR are not new nor old, but we could say maybe that what is new, or at least deserves our attention now, is the BR Approach.
Business Rules Approach
Past methodologies did not elevate sufficiently the importance, visibility, traceability, and accountability, of the decisions and rules behind the tasks, as we have seen. Now that we are aware of the great importance of the ‘know’ as a primordial factor in every enterprise, and as every day more a greater importance is given to the knowledge, it is relevant to refocus our perception of processes as collections of decisions and underlying rules that guide the actors in responding to the events. (See [KPI]).
The Business Rules Approach would be just that. We saw that a definition of BR would be “Terms, Rules and Facts”. “A BR, then, can (1) define a term, (2) connect terms into meaningful facts, (3) produce the result of a calculation, (4) test conditions to produce a new fact, or (5) test conditions to initiate action. The last three categories form a category of BR, called rules. Thus, you can think of a business rules approach as encompassing the collecting of terms (definitions), and rules (calculations, constraints and conditional logic). A formal business rules approach addresses all of these categories, with special emphasis and formalism on the expression, management, and automation of rules”. [KPI]
BR at the most elementary level answer the question why. I wonder if the rest of the people see the Zachman Framework in the same light, or if even I will keep seeing it that way for long, but it seems to me that the “why” column in fact drives all the other ones. Why is your data the way it is? Why do you need to know certain “facts” and “terms” (entities and relationships)? Why do you process this way and no the other? Why isn’t this or that allowed? In fact all these questions have always been done. They just weren’t recorded appropriately in our models.
Personally I have been wanting to relate the “justification” of every process, data, constraint and everything else we were designing and writing from my very first project. I am quite happy I finally found something that seems to do it, and not only that: it also explains it, gives a rational for it and tools as well.
“A BR approach to automation refocuses the systems development process so it aims first to understand and document the rules of the business. Then, it aims to automate these rules in a way that makes them traceable (for impact analysis and ability to the change) and accessible (for communicating violations and compliances back to the business community). Taken one step further, a formal approach to expressing, managing, and automating rules will deliver rigor in producing reusable, executable atomic pieces of code.
This is a better way to automate the business because it bridges the gap between the business and information systems community. It also delivers back to the business, through its automation, its decision-making capability and value system for guidance and scrutiny” [KPI].
A business rules approach “allows IT professionals to become business-focused”. It “is not a new paradigm, but simply the result of putting business priorities above technological priorities” [von Halle].
The reasons for choosing such an approach seem pretty evident, at least they will be to the business people. Maybe the IT people won’t all be willing to enter an approach that somehow rests importance to their department. There are several cases in which the IT department did not approve the introduction of BR technology and still resists it when its business people have made steps on their own to have such kinds of products, so that’s a factor to take in account (see [BRF]), but let’s see, what would the benefits be.
Benefits
The benefits of a business approach, from what is said in the articles and study cases, are quite interesting. The most important benefit seems to be (hang on to your hats) the business perspective that is applied to the whole thing, reempowering the business users. By having the BR documented and organized, and knowing that these same BR are actually what is driving the “real” systems, as opposed to some manuals (if you’re lucky) that are sleeping on the shelves and the actual and real technical impossibility to know if and where and when the rules they contain are applied, that is quite a difference.
That empowers the business users with regard to their systems, something I am sure many of them want desperately. (Oh yes, more than one would be more than happy to kick out their IS department if they could). Besides that, it also makes it easier to have them involved in the process and the results. (Ever heard that before?) Why? Because the “business rules speak” is much closer to the common ways of expression of the usual people (that is, non-IT people, of course), so more accessible to them. Ever seen a manager approve a proposal whose main document was a 2 meters by 2 meters ER diagram with a hundred entities? Not a pretty sight. But what follows goes worse. If the user can understand the system, much better.
That is the main benefit of it all, something I remember was to be achieved by OO (or so was saying Yourdon): a common language, a language familiar to the user, and usable by the IS people. Of course, in this case, it implies that the rules have to be usable in the systems just like they are expressed. I don’t know if all, but many of the proponents of the business rules approach insist on that point: rules have to be in a declarative language.
That’s not the only benefit though, there’s more: “faster application development; better quality requirements; ease of change; and a balance between flexibility and centralized control” [Gottesdiener].
And from an IS point of view? Well, I’d say these are good news for us too. Clearer requirements, better productivity, adaptability. Actually our requirements meet with the ones of the business people, don’t you think?
And... Does it work?
It seems it does. The industry is flourishing with BR oriented products, and the people that were in it 15 years ago are still there, and still in it, and there are more of them. There are more books, more resources too. That by itself should prove it. Beside that, there are the success stories that are told. Of course, that is always relative, but you can look at them and judge by yourself. (see [KPI] and [Gottesdiener]).
The reports in [KPI] of several success stories are about speed of delivery, productivity improvement in customer service, customer satisfaction, speed of change, and that comes to put the IS department in an interesting position. Here are some excerpts from three cases. Read on:
“After development of a data model, the specification of the rules and interface development were completed within four months. The system went into production four months later. The application involved over 200 windows, 200 tables, hundreds of rules, and interfaces with several legacy systems. Most importantly, within 1 year, the organization measured 40% productivity improvement in delivering service to the customer, achieved 97% customer satisfaction, became profitable, and re-established itself as a market leader in the field”.
“The system supports portfolio management and life and pensions policy administration. It needed to be independent of database and operating systems. It needed to incorporate electronic trading and Internet access. The system was delivered on time, within budget, and supports all desired functionality. It will be rolled out to 750 locations, serving 2000 users. It consists of 500 tables, 700 complex business rules, and 2000 windows. Of most interest is the fact that system changes are implemented within 24 hours of request. The business rule repository is large, 25 megabytes in size. The technical environment has changed operating systems 5-6 times with no significant impact on the operations of the application”.
“At the moment, Klopman Fabrics now has two business rule systems in production, with two more ready to go into production. All new development, beyond year 2000 enhancements, will now follow a business rules approach. Brown emphasizes that the business rules approach makes such a significant difference in I/T’s ability to deliver systems fast, that the business community is not always able to keep up. While this is a nice position to be in for I/T (not to mention, a bit unfamiliar!), Brown also states that I/T should be prepared to change its organizational infrastructure to better leverage the business rules approach”.
These are real cases, from real companies, reported by a real consulting company, and as you can see, they are about “real systems” in terms of complexity, functionality and size. Interesting results, no?
And now, would it be that a business rules approach is for everybody? It seems to me that it is, yes, because its characteristics fit into a model that is universal (there is no system without BR), and the benefits seem to apply universally too. But then, maybe there will be cases in which the cost of the technology will not make it affordable. In these cases, we will see later that there are alternatives within the technology, and even home grown solutions that could be affordable. The important point anyway is to have a business rules approach. As we have seen with the Zachman Framework, the cells represent artifacts that are independent of a particular product or technology. “It’s not another tool, it’s another way of doing work” [Gottesdiener]
Business Rules Technology
Now, even if the approach is independent of whatever technique or technology, we want to know how all this is put to work, right? Actually pretty badly it seems. I feel that way, and so do the people that took the survey. When asked to rate their actual knowledge of commercial products and their capabilities from 1 to 5 (1 being “no knowledge” and 5 “perfect”), 68% answered “1”, and 32% “2”! There wasn’t even a single answer above “2”! (Vendors, hear).
When asked if they needed to know more of BR in the different categories of “overall”, “conceptually”, “technically” and “commercial products”, with a scale from 1 to 5 where “1” was “not at all”, “3” “I could use something” and “5” “absolutely yes”, there was a nearly uniform response in all the categories: “I could use something” scored 39%, “4” 33% and “absolutely yes” 28%. See any tendency here? People are in need of information.
So let’s take a look at the technology and products. But I must warn here: I have used none of the products mentioned here, and everything that follows is extracted from other people’s work or from the companies’ web sites. The products here are not rendered in all their aspects, this is just a bird’s eye view of the subject. (I qualify for a “2” in actual knowledge in the survey). Anyhow, you will find here a quite complete list of available products to orient your search. The list is not guaranteed to be complete or even correct in all aspects, and I apologize to any vendor I would have missed.
Coverage
First, let’s recall that, according to the framework, there are several views of the columns, so there will be different ways to deal with a same aspect. Therefore we should find tools and techniques that address the BR aspect from different perspectives.
Figure 1: Coverage of the Zachman Framework by Centerprise.
Beside that we should of course find a variety of outlooks on the subject, and companies that intend different kinds of coverage: the famous definition of BR “Terms, facts and rules” includes the data (as terms and facts), so most probably we will see that the data column is an important concern for BR products. Then there is the fact that BR constrain and orient behaviors. So, it is highly probable that we will see a lot about the Function column too. Then of course, any tool that deals with data and function will have to cover the human interfaces or at least help to it, so there goes the People column too. And finally, as it is very normal that companies make their best to offer the best coverage possible, we might just as well find out that the offerings happen to address the other columns in some way.
In Figure 1 is the claim of coverage of the Framework by Centerprise.
Business rules capture tools
These tools are for the recording and organizing of the
· QSS DOORs (a requirements management tool actually) (www2.telelogic.com/doors)
· Rational’s Requisite PRO (idem) (www.rational.com)
· Riverton’s HOW (www.riverton.com)
· Usoft’s Teamwork (www.usoft.com)
· Business Rules Solutions’ BRS Ruletrack (www.brsolutions.com)
Business rules products
Here we have the
products with which you implement real working systems. They have been classified
in different ways by different people. Apparently, some products generate the
rules into triggers and procedures that go into the database. Others have a
rule engine, which is invoked to take care of the
|
Company & Product(s) |
Triggers/ procedures |
Inference |
Data
Driven |
OO |
Comments |
URL |
|
Astera Centerprise |
|
? |
? |
X |
Downloadable demo |
|
|
Brokat. Blaze Advisor Solutions
Suite |
|
X |
|
|
|
|
|
Computer Associates. Aion (Originally from Platinum) |
|
X |
|
X |
|
|
|
Efuturia TIMBR (Tools or
Intelligent Management of Business Rules) |
|
|
|
|
Generates rules from structured English for different vendors’ rule engines. |
|
|
Haley Eclipse and others |
|
X |
|
|
|
|
|
ILOG ILOG Rule Kit |
|
|
X |
|
|
|
|
Mindbox ARTEnterprise |
|
X |
|
|
|
|
|
Netron Inc. Netron HotRod EE |
|
? |
? |
|
Specializes in applications mining, COBOL applications |
|
|
Oracle CDM RuleFrame |
X |
|
|
|
Downloadable trial |
|
|
Rule Automation RuleFactory |
|
X |
|
|
|
|
|
RuleMachines Corporation Business Rule Studio Visual Rule Studio |
|
X |
|
X |
Downloadable demo |
|
|
Sterling Commerce E-Marketplaces |
|
X |
|
|
|
|
|
Usoft Usoft Developer (and others) |
|
|
X |
|
ANSI SQL as its specification language |
|
|
Versata Visual Age Application
Rules Partner: IBM |
|
|
X |
|
|
Table 2: BR Products
The first
surprise has been to find out that there actually were products that dealt
directly with
Triggers and procedures
The generation of triggers and procedures relates to very familiar concepts for us, as we do that all the time. We can relate that to the TAPI that Designer generates, and in fact several people are using that mechanism, or generating their own TAPI to implement their business rules. Oracle’s CDM RuleFrame does it, and so do others in their practices (see [Wendelken], [Gougeon]).
Data driven rule engines
The Data Driven model isn’t quite clear to me. What I understand of it is that the rules are referred to the data model in a direct way, so that when a DML operation happens, the engine knows what to do about it, and for that it follows procedural actions. Ellen Gottensdiener [Gottensdiener 2] classifies both Usoft and Versadata as Data Driven, but I was unable to get a clear idea of the mechanisms themselves from the documentation. (I must admit I wasn’t thorough). The vague idea I got of it is that it is pretty much the same than the first model, but with the very great difference that everything that relates to BR is managed apart, in an engine. That brings a lot of advantages, of course.
Rule-based inference engines
The rule-based inference now, that is something that was completely new to me (and probably to most of you too: 75% of the people taking the survey did not associate BR with AI). Of the preceding list, 50% of the products claim to have rule-based inference engines. So what is that technology that appears to be so useful in BR engines? It is something that comes from the realms of Artificial Intelligence (AI). It once was the shining star of that discipline and has now become mainstream for the management of BR and other areas.
Rule-based inference engines capture knowledge and reasoning and store it in the form of rule. These engines work with several components: a rule base (or knowledge base), an inference engine and a set of case-specific data. Rules are normally expressed as “if then else” constructs, where the “if” part is called a premise and the “then” or “else” part a conclusion. These engines are capable of “reasoning” in that they can look for rules to evaluate based on the facts that are informed, and then look for the rules to evaluate based on the conclusions, which come to be new facts or, actions. Then the new facts, or the actions, are evaluated again and might provoke new rules to be evaluated.
These engines
are based on several algorithms that try to optimize this behavior, most of
them based on the “Official Production Systems” developed during the seventies.
These rule-based languages are OPS5 (from the
Be ready to read those names in the documentation.
The need for inferencing
Ron Ross, while defining what BR were and were not, happened to write: “note that the 1997 GUIDE Business Rules Project definition includes both the word ‘control’ and the word ‘influence’ in reference to business behavior. If you think of ‘rules’ only as hard and fast ‘constraints’ (asserting strict control), you miss at least half the scope of business rules. Guidelines, heuristics, inferences, etc. are also business rules!” [Ross 4]
Kirk Wilson is a bit more explicit as to why and when we might need inferencing. He sees that activities can be classified with regard to their position on a scale of rule use, from “Rule-Constrained Activities” to “Rule-Based Activities. (see Figure 2)
Figure 2: Sliding scale for Insurance Underwriting Activities
“Core business processes (i.e., critical work flows) are complex,
always consisting of many types of activities. Many of these activities are
operational tasks governed by constraints (and hence clearly fall under the rule-constrained
paradigm), others require standard business decision procedures, while a few
may call for creative decision-making. Key activities in core business
processes most likely lie in the second category and require standard decision
making procedures. The question is, Are these standard decision procedures to
be conceived of as rule-constrained or rule-based? Many such procedures are
neither purely rule-constrained nor purely rule-based. (Nevertheless) the
activities that are the most critical for core business processes tend to be
(best seen as) rule-based” [
So, as usual,
everything is relative to the needs. Rule-based technology is pretty new for
most of us and might be intimidating. Besides that, “Rule based activities
generally have experts to apply the rules because of the complexity” [
Concluding on Inference
Of course, it is the ability of these engines to resolve complex networks of rules and to maintain them apart from the data structures and from the processes which makes them desirable. They have been successfully used, and we need not worry just because they come from the unknown (?) and foreign (?) world of AI. (To make AI less unknown, see [Haley 3])
Business rule engines: do we need them?
Anyway, being based on inference engines or not, the BR engines seem to be doing some good work and support the paradigm we’ve been discussing here all along.
In 1996, Patricia Seybold predicted that Business Rules Engines would become much more popular in the next few years. She even said that is an off-the-shelf application or development tool did not have one, we should look elsewhere [Seybold]. Then in 1999, Ron Ross said that within the next 5 years “the idea of building a business application without a rule engine for business rule support will seem as silly as building one today without a DBMS for data support” [Ross 5].
Paul Dorsey [Dorsey] on the other hand says that a rule-based approach and a State Transition Engine (STE) are equivalent ways to handle process-related business rules. And that he prefers an STE because they make the logical flow of the objects always explicit and easier to manage when the flow is complex. He is actually using an STE successfully in production systems. The STE approach has been used in other projects also. (See [Gougeon])
And of course, there is the triggers/procedures approach too, which is successfully used by many. (See [CDM] and [Wendelken])
So, like always, there is not a unique possibility, and every approach will have to be measured up against the requirements to see which fits better. Remember, the approach is the most important. The technology or techniques can vary a lot within it.
Conclusion
I personally believe that Business Rules are here to stay, and that is was about time. My reasons? The Zachman Framework gives me the mental comfort of a reason for that. The increasing quantity of products that take the Business Rules Approach indicates that the market is responding to it. The success stories are very encouraging. We are having this Business Rules Symposium for the second time at the ODTUG conference and the Business Rules Forum is about to happen for the fourth time. There is only one new book on the subject, that’s true, but at least it is from C. J. Date, a known name of the Relational field... (See below). Ron Ross and his company BRSolutions seem to be doing well... You are reading this paper...
And speaking of you, most of the people taking the survey agreed on that. Asked if BR were here to stay, 33% said there was a possibility, 39% that there was a good possibility, 22% that definitely. And only 6% said “No”. That gives us 94% of positive thinking on the subject! Another remarkable fact from the survey is that 63% said they planned to use BR tools sometime! 37% answered that they didn’t know, and 0% answered that they would not. That must be good news for the vendors.
Besides that, there are even some aspects that demonstrate that the business rules approach is growing even more: a company which has tools for the business rules analysis, design, modeling and management translates the rules for different business rules engines! (see [eFuturia]). And IBM released in 1999 a product that allows for the communication of executable business rules between enterprises using heterogeneous rules systems (see [IBM]), giving birth to the Business Rules Markup Language (BRML)! (See [BRML]) This means that the market has grown enough to be needing this kind of features (desirable ones by the way).
Yes, like Terry Moriarty wrote (see [Moriarty 2]): “Business Rules are Happenin’ ”.
Resources
To finish this paper, I wanted to give a list of different resources that could be of help, in many senses. So here is a list of the books available, the online resources, and the consulting companies that I know are using BR as a fundamental part of their practices. The “must read” articles are in the reference list. I had promised an extensive list of articles with rating and URL in the original abstract. This list will be made available on my web page by the time of the symposium. Check Alain_Gougeon.tripod.com. (That is also where the complete results of the survey will be put).
Books
The Business Rule Book
Classifying, Defining and Modeling Rules, Version 4.0 - Ronald G. Ross – 1997 (Second Edition)
“Business rules represent a radically new approach to expressing user requirements. Based on data models (or object models), they take non-procedurality to a level never seen before. They will revolutionize analysis and design techniques for database systems.
The Business Rule Book introduces Ross Method, a graphic technique for expressing business policies and practices directly in rigorous fashion. More than simply a collection of functions or processes to execute, it views a business as a collection of rules. Its ultimate goal is to make turning these rules on or off as easy as flipping light switches.
At the heart of the Ross Method is a classification of business rules, called the Chart of Atomic Rule Types. In the new chemistry of information systems, these atomic rule types are formed easily into powerful compounds. Ross Method shows how.” (From the back cover of the book).
Business Rule Concepts
The New Mechanics of Business Information Systems - Ronald G. Ross - 1998
“The human body has three basic mechanical components: skeleton, muscles and nerves. Each is essential, integrated and specialized. The result – highly adaptable, highly intelligent behavior.
In Business Rule Concepts, Mr. Ross – the world’s leading authority on business rules – shows you how you can follow the same basic principles to make business behavior more adaptable and intelligent. The key ingredient – business rules. Find out what business rules are about, and why they represent a fundamental breakthrough for IT and the business.” (From the back cover of the book)
WHAT Not HOW
The Business Rules Approach to Application Development - C. J. Date - 2000
“(It) is a concise and accessible introduction to this new technology. It is written for both managers and technical professionals. The book consists of two parts: Part I presents a broad overview of what business rules are all about; Part II then revisits the ideas in Part I and show how they fit squarely into the solid tradition of relational technology. (...) Overall, the book provides a good grounding in an important new technology, one poised to transform the way we do business in the IT world”. (From the back cover of the book)
Review by Old Owl, July 2000, on the BRCommunity site at: http://www.brcommunity.com/cgi-local/x.pl/resources/b019.html
Online Resources
BRCommunity: www.brcommunity.com (Best resource ever!)
The Business Rules Group: www.BusinessRulesGroup.org
The
Information on the products themselves is of course available on the sites of the companies. White papers as well. Many articles can be found at some of the Consultants web sites too (see next section). A big list of online articles should be available on my web site by the time you read this.
Business Rules Conference
The very fact
that we are having this BR Symposium for the second time at the ODTUG conference
is a very good sign of the healthy growth of
Consulting Companies
This list of consulting companies is in no way an endorsement or even a recommendation, nor does it pretend to be complete. It is listed just to satisfy some curiosity as to who’s “into it”.
These consulting companies are listed at the “support” page of BRCommunity. All these people actively participate to the content of the BRCommunity web site and in the press in general, for many years already. See the page at www.brcommunity.com/cgi-local/x.pl/resources/support.html
· Business Rules Solutions, LLC (Ron Ross) (www.brsolutions.com)
· EBG Consulting, Inc (Ellen Gottesdiener)(www.ebgconsulting.com)
· Essential Strategies (David C. Hay) (www.essentialstrategies.com)
· Inastrol (Terry Moriarty) (www.inastrol.com)
·
Knowledge Partners, Inc. (Barbara von Halle) (www.kpiusa.com)
On the “Business Rule Contacts” from the Business Rules Group (www.businessrulesgroup.org/brglink.htm), we find these same companies, plus this one:
·
CrossLogix, Inc (www.crosslogix.com)
And finally there are these companies which I know are “into it” through the papers and activities of their members:
·
BizRules.com
(Rolando Hernandez) (www.bizrules.com)
· CaseTech, Inc. (David Wendelken and I.Michael Snyder) (www.casetech-inc.com)
· DACOM (David Appleton) (www.dacom.com)
·
Dulcian, Inc. (Paul Dorsey) (www.dulcian.com)
References
[BRCommunity] Business Rules Community, Technology Review by Neal Fishman, The ‘RETE’ Algorithm. Available at www.brcommunity.com/cgi-local/x.pl/resources/b042.html
[BRF] Business Rules Forum 2000, Birds of a feather sessions, Practitioner’s Panel, The Dos and DONTs of Business Rules. Available at www.businessrulesforum.com/BRF2000_panel.htm
[BRG] The Business Rules Group, Organizing Business Plans – The Standard Model for Business Rule Motivation, v1.0, 11/2000. Available at www.BusinessRulesGroup.org
[BRML] Robin Cover, The XML Cover Pages – Business Rules Markup Language (BRML). 1999. Available at www.oasis-open.org/cover/brml.html
[Dorsey] Paul Dorsey, Business
Rules Position Paper. Business Rules Symposium Proceedings,
[eFuturia] eFuturia, TIMBR User Benefits. www.efuturia.com/products/timbrbenefits.html
[Gottesdiener] Ellen Gottesdiener, EBG Consulting, Inc, Business RULES Show Power, Promise. Available at www.ebgconsulting.com
[Gottesdiener 2] Ellen Gottesdiener, EBG Consulting, Inc, Links page. Available at www.ebgconsulting.com/links.htm
[Gougeon]
Alain Gougeon, Alfredo Torrez, Order and Documentation in my Transactions –
[GUIDE 1] GUIDE Business Rules Project, Final Report, 11/95, available at www.businessrulesgroup.org/brgactv.htm
[GUIDE 2] GUIDE Business Rules Project Final Report rev 1.2, 1997, available at www.businessrulesgroup.org/brgactv.htm
[Haley] The Haley Enterprise, Rule-based Languages for Expert Systems. Available at www.haley.com/1202865724032016/RuleLanguages.html
[Haley 2] The Haley Enterprise, Agile Business Rule Processing. 1999. Available at www.haley.com
[Haley 3] The Haley Enterprise, Answers to Common Questions about AI. Available at www.haley.com
[Hay] David C. Hay, Concepts, Logic, and the Zachman Framework, Curmudgeon’s Corner column at BRCommunity, February 2001. Available at www.brcommunity.com/cgi-local/x.pl/features/b052.html and www.essentialstrategies.com
[IBM] Overview of IBM CommonRules 1.0 Alpha Release. www.research.ibm.com/rules/commonrules-overview.html
[KPI] Business Rules Today: A KPI Position Paper. Available at www.kpiusa.com
[Moriarty 1] Terry Moriarty, The Next Paradigm, Database Programming and Design, February 1993. Available on the articles page at www.inastrol.com
[Moriarty 2] Terry Moriarty, Business
Rules Are Happenin’,
[Moriarty 3] Terry Moriarty, Architecting for Evolution, 06/96. Available at www.inastrol.com/articles/9606.htm
[Ross 1] Ronald G. Ross, The Business Rule Book (First Edition), 1994
[Ross 2] Ronald G. Ross, The Business Rule Book (Second Edition) 1997
[Ross 3] Ronald G. Ross and Gladys S. W. Lam, 2000, BRSolutions, the BRS Business Rule Methodology, 2000
[Ross 4] Ronald G. Ross, What is a ‘Business Rule’?, Logical Conclusions column at BRCommunity, March 2000.
[Ross 5] Ronald G. Ross, Your Core Business Processes Need a Rule Engine, Logical Conclusions column at BRCommunity. May 1999.
[Seybold] Patricia B. Seybold, Start your business rules engine, Computerworld, 1996.
[von Halle] Barbara von Halle, The Business Rule Roadmap, Database programming & design, 10/97. Available at www.dbpd.com/vault/9710arch.htm
[Wendelken] David Wendelken, Ed Campbell, Betty Hillbrant Baker, Carrie Anderson, Business Rules-Based Methodology: A Java Application Case Study. ODTUG 2000 proceedings. Available at www.odtug.com
[
[Zachman 1] John A. Zachman,
[Zachman 2] John A. Zachman,
[Zachman 3] John A. Zachman, A Framework for Information Systems Architecture, 1987, IBM Systems Journal, vol. 26, no.3. IBM Publication G321-5298. 914-945-3836 or 914-945-2018 fax.
About the Author
Alain Gougeon is a Systems Analyst with 12 years of experience with Oracle technology. Most of this experience has been in doing governmental financial systems for several countries of South America, hired by international organizations like UNDP, World Bank and IADB. He has a most international career, being French, born in Belgium, from a German speaking mother, married to a Brazilian woman, with two Paraguayan daughters and having worked also in Venezuela, Uruguay and Bolivia. He always had an interest in Business Rules, though he didn’t know they were called that way until relatively recently. He has built several custom solutions to support the documentation and even the generation of Business Rules code, since 1994. The last one of these solutions, developed at the ILACO II project from La Paz, Bolivia, being presented at last year’s ODTUG conference (see [Gougeon]). He welcomes your comments and critics, always willing to know more, just as well as simple salutations: ajmg@excite.com – http://Alain_Gougeon.tripod.com. He is eager to be able to do a full-fledged “business rules project”.