« June 2005 | Main | August 2005 »

July 19, 2005

My Thoughts on the Business Rules Manifesto

I think I finally figured out what my contribution to the Business Rules Manifesto was...

The Business Rules Group, an independent standards group of business and IT professionals, published The Business Rules Manifesto, principles of rule independence in 2002.

I liked the idea and drafted an "article of independence" about the difference between a Business Rule and an IF-THEN Statement. I sent that in, along with other positive feedback, to Ronald G. Ross, who edited the Manifesto. When I ran into Ron later on at one of the rules conferences, he asked if I noticed how my input had made its way into the new version of the Manifesto. At first glance I couldn't tell.

But recently I looked again at Version 2 of the Manifesto and I think I found it. Now, I'm not certain, but I think that my thoughts below helped development of article 6.3:

My comments: "Business Rules derive inferences and arrive at conclusions by reasoning about facts or premises using either deduction or induction... Business rules can explain their reasoning process in order to justify their conclusions, decisions, and recommendations..."

Article 6.3 of the Business Rules Manifesto: "6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action."

Pretty cool - - mystery solved.

The Business Rules Manifesto

The Business Rules Group, an independent standards group of business and IT professionals, published The Business Rules Manifesto, principles of rule independence.

It looks like a "Declaration of Independence for Business Rules", and it is pretty interesting reading for people interested in the rules movement. The original document is here: http://www.businessrulesgroup.org/brmanifesto.htm



The Business Rules Manifesto*

Article 1. Primary Requirements, Not Secondary

1.1. Rules are a first-class citizen of the requirements world.

1.2. Rules are essential for, and a discrete part of, business models and technology models.

Article 2. Separate From Processes, Not Contained In Them

2.1. Rules are explicit constraints on behavior and/or provide support to behavior.

2.2. Rules are not process and not procedure. They should not be contained in either of these.

2.3. Rules apply across processes and procedures. There should be one cohesive body of rules, enforced consistently across all relevant areas of business activity.

Article 3. Deliberate Knowledge, Not A By-Product

3.1. Rules build on facts, and facts build on concepts as expressed by terms.

3.2. Terms express business concepts; facts make assertions about these concepts; rules constrain and support these facts.

3.3. Rules must be explicit. No rule is ever assumed about any concept or fact.

3.4. Rules are basic to what the business knows about itself -- that is, to basic business knowledge.

3.5. Rules need to be nurtured, protected, and managed.

Article 4. Declarative, Not Procedural

4.1. Rules should be expressed declaratively in natural-language sentences for the business audience.

4.2. If something cannot be expressed, then it is not a rule.

4.3. A set of statements is declarative only if the set has no implicit sequencing.

4.4. Any statements of rules that require constructs other than terms and facts imply assumptions about a system implementation.

4.5. A rule is distinct from any enforcement defined for it. A rule and its enforcement are separate concerns.

4.6. Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.

4.7. Exceptions to rules are expressed by other rules.

Article 5. Well-Formed Expression, Not Ad Hoc

5.1. Business rules should be expressed in such a way that they can be validated for correctness by business people.

5.2. Business rules should be expressed in such a way that they can be verified against each other for consistency.

5.3. Formal logics, such as predicate logic, are fundamental to well-formed expression of rules in business terms, as well as to the technologies that implement business rules.

Article 6. Rule-Based Architecture, Not Indirect Implementation

6.1. A business rules application is intentionally built to accommodate continuous change in business rules. The platform on which the application runs should support such continuous change.

6.2. Executing rules directly -- for example in a rules engine -- is a better implementation strategy than transcribing the rules into some procedural form.

6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.

6.4. Rules are based on truth values. How a ruleís truth value is determined or maintained is hidden from users.

6.5. The relationship between events and rules is generally many-to-many.

Article 7. Rule-Guided Processes, Not Exception-Based Programming

7.1. Rules define the boundary between acceptable and unacceptable business activity.

7.2. Rules often require special or selective handling of detected violations. Such rule violation activity is activity like any other activity.

7.3. To ensure maximum consistency and reusability, the handling of unacceptable business activity should be separable from the handling of acceptable business activity.

Article 8. For the Sake of the Business, Not Technology

8.1. Rules are about business practice and guidance; therefore, rules are motivated by business goals and objectives and are shaped by various influences.

8.2. Rules always cost the business something.

8.3. The cost of rule enforcement must be balanced against business risks, and against business opportunities that might otherwise be lost.

8.4. More rules is not better. Usually fewer good rules is better.

8.5. An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.

Article 9. Of, By, and For Business People, Not IT People

9.1. Rules should arise from knowledgeable business people.

9.2. Business people should have tools available to help them formulate, validate, and manage rules.

9.3. Business people should have tools available to help them verify business rules against each other for consistency.

Article 10. Managing Business Logic, Not Hardware/Software Platforms

10.1. Business rules are a vital business asset.

10.2. In the long run, rules are more important to the business than hardware/software platforms.

10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.

10.4. Rules, and the ability to change them effectively, are fundamental to improving business adaptability.

*Version 2.0, November 1, 2003. Edited by Ronald G. Ross.

Copyright, 2004. Business Rules Group.

Permission is granted for unlimited reproduction and distribution of this document under the following conditions: (a) The copyright and this permission notice are clearly included. (b) The work is clearly credited to the Business Rules Group. (c) No part of the document, including title, content, copyright, and permission notice, is altered, abridged, or extended in any manner.



Note: The original document is here: http://www.businessrulesgroup.org/brmanifesto.htm

July 02, 2005

Quotes by Jim Sinur, VP, Gartner, Inc.

Jim Sinur is Vice President and Distinguished Analyst, Gartner Research

Jim knows more about business rules than anyone I know. His observations on trends and the state of the market are usually "spot on" must-reads for anyone interested in the business rules movement. Here are some articles he wrote or was quoted in:



Taking Rule Technologies for a Test Drive Gartner Research Note, Dec. 15, 2004. "Businesses have only scratched the surface, so far. Rule technology presents a huge opportunity going forward."

Business Rules, OK? February 2004 cbronline.com / ilog.com Rules add to IT flexibility, says Gartner - Analyst stresses growing importance of 'untrendy' rules-based engines. by Miya Knights, vnunet.com 23 Jun 2004 "Rules engines will become more important as companies look to make their IT systems more flexible, according to analyst Gartner. Jim Sinur, senior research director at Gartner, told delegates at last week's European Business Rules Conference in Amsterdam that, while rules might not be considered "trendy", their importance is growing..."

Sidebar: Advise or Control, MAY 23, 2005 (COMPUTERWORLD)

  • "About 50% of business rules engines are used in an advisory role: 'Should I do this or that?' The other 50% are used in business processes," he says.
  • According to Sinur, there are three categories of rules systems: 1. Simple rules externalization... 2. Inference engine.... 3. Behavioral learning......"

How Business Rules help Business Improve Productivity - Nov. 20, 2003, Ft. Lauderdale, FL, SFTA Meeting with FTC Commissioner Orson Swindle

Starting Over With BPM. Michael Hammer, August Scheer and analysts weigh in on the state of business process management, May 29, 2003

The irresistible lure of BPM, Infoconomy.com

Gartner's Jim Sinur says there are 11 core reasons why organisations should consider BPM:

  1. To build new business processes faster
  2. Improve understanding of current business processes
  3. Reduce friction during mergers
  4. More easily accommodate business process outsourcing (BPO)
  5. Better implement new software
  6. Consolidate parallel business processes
  7. Automate more of the management of human activities
  8. Better manage supply chains, particularly where a process joins with another organisation
  9. Optimise processes through process modelling
  10. Analyse the effect of corporate governance legislation before new business processes are implemented
  11. Create models to examine the potential effect of opportunistic or threatening scenarios



THE BIG IDEA, SHRINK-WRAPPED - Adjusting BPM to suit middle market companies made it easier to implement for all companies. Treasuryandrisk.com, February 2005



Gartner on the BPM Market. by Jim Sinur, Gartner, Inc. www.gartner.com



A Better Way To Manage Rules - Automated, centralized control eases management effortBy Tony Kontzer InformationWeek , April 29, 2002



If you see Jim in print, send me the link and I will be glad to update this page.

What is the difference between a Business Rule and an IF-THEN Statement?

Business Rules derive inferences and arrive at conclusions by reasoning about facts or premises using either deduction or induction.

An if-then statement in a declarative rule-based programming language is a business rule. Business rules are designed to solve complex problems that require thinking and knowledge in order to make intelligent decisions. Business rules can explain their reasoning process in order to justify their conclusions, decisions, and recommendations. Business rules are commonly used to create Intelligent Systems that reason and apply knowledge.

An if-then statement in a procedural programming language is not a business rule. It is simply a type of conditional statement designed to either control program branching or to conditionally execute sections of program code. If-then statements are commonly used in conventional programs that process data and manage information.

This was originally published here.

Famous Quotes (about resistence to change and predicting the future)

I am reminded of these quotes every time I talk to someone who believes that rulebases, knowledgebases, and expert systems are a fad...

"The telephone has too many shortcomings to be seriously considered as a means of communication.”
Western Union internal memo, 1876

"The Americans have need of the telephone, but we do not. We have plenty of messenger boys."
Sir William Preece, chief engineer of the British Post Office, 1876 *

"Drill for Oil? You mean drill in the ground to try and find oil? You're crazy."
Response reported by Edwin Drake as he tried to hire workmen who knew oil just bubbled out of the ground, 1895 *

"Everything that can be invented has been invented.”
Charles H. Duell, Commissioner, U.S. Office of Patents, 1899

"It must be accepted as a principle that the rifle, effective as it is, cannot replace the effect produced by the speed of the horse, the magnetism of the charge and the terror of cold steel."
British Cavalry Training Manual, 1907 *

"Airplanes are interesting toys but of no military value."
Marshal Ferdinand Foch (who become the supreme allied commander in World War I), 1911 *

"The wireless music box has no imaginable commercial value. Who would pay for a message sent to nobody in particular?"
David Sarnoff's associates in response to his urgings for investment in the radio in the 1920s.

“Who the hell wants to hear actors talk?"
H.M. Warner, Warner Brothers, 1927

"I think there is a world market for maybe five computers."
Thomas Watson, chairman of IBM, 1949 *

“Computers in the future may weigh no more than 1.5 tons.”
Popular Mechanics, 1949

"I have travelled the length and breadth of this country and talked with the best people, and I can assure you that data processing is a fad that won't last out the year."
Editor in charge of business books for Prentice Hall, 1957 *

"We don't like their sound and guitar music is on the way out."
Decca records rejects the Beatles, 1962 *

"There is no reason in the world anyone would want a computer in their home. No reason.”
Ken Olsen, Chairman, DEC, 1977

"I believe OS/2 is destined to be the most important operating system, and possibly program, of all time.”
Bill Gates 11/87

"640K of RAM ought to be enough for anybody.”
Bill Gates, 1981

"The best way to predict the future is to invent it”
Alan Kay

* Thanks to Jocelyn Paine for these quotes:

Locations of visitors to this page