Business Rules
Subject Index - Links, References and Notes
|
Business RulesSubject Index - Links, References and Notes |
|
| Home Page | Business Rules | Rule-Based Systems | Rule Engines | Under the Hood |
Note: This section contains more or less permanent links
( at least I hope they are permanent, let me know if they are not ).
The Grand Daddy of business rules sites is Business Rule Community, run by Ron Ross. If one is at all interested in the subject of business rules, it's well worth the time to sign up. They send you one newsletter a month about new articles on the site - no big mailing lists, no spamming.
Another excellent site is Business Rules Group, run by John Zachman, Ron Ross ( again ), Terry Moriarty and many other big names in business rules.
In addition to his work in business rules, John Zachman deserves a separate mention for his development of he the Zachman Framework, one of the essential tools of conceptual modeling.
Advances in information technology in the last 20 years have made it easier to purchase products and services. Although the impact of information technology has been stunning, I think many people would assert that it has made dealing with business their lives haven't been made easier on the whole, quite the opposite.
Consider the classic rule of a business rule, "any customer payment which is more than 60 days overdue will be send to a collection agency". It's distinct and atomic rule that should be enforced on the enterprise level. Yet how often is it obeyed to the letter of the corporate law. If a good and loyal customer calls with a complaint about overcharges or some other issue, how often will a customer service representative allow an extra 30 days to straighten out the mess before sending the debt to collections. The answer is almost always. There are exceptions to any rule and perhaps more so for high-level business rules
There is an essential difference between the programming behemoths of yesteryear and an advanced business rules system. One of the most import differences is that the representative who tells the customer that the company is will wait a week more for a payment will not also have to tell the customer to ignore the nasty letters generated by the computer system in the interim. An advanced business rule system will know not to send nasty letters to the customer in the middle of a payment muddle or legitimate dispute over billing or what ever the reason. It is often in the ability to make useful exceptions to business rules that the real power of business rules technology manifests itself
In fact, I have argued ( sometimes successfully ) that rigid application of rules is contrary to one of the essential benefits of business rules technology, that is, flexibility or "agility" as it is often called these days.
While a certain number of errors and inconveniences must be expected in any automated business process, the ability to apply rules flexibility and adapt business rules to specific situations can be a critical factor in the making of happy customers who keep coming back for more.
From the Business Rules Community staff, A Brief History of the Business Rule Approach, 2nd ed. Nov. 2006. They trace the first use of the term "business rules" to Daniel S. Appleton's article "Business Rules: The Missing Link," ( Datamation Magazine, October 1984 ). In fact, the idea was bound up in some of the 'structured methodologies' of the late 1980s.
The article stresses the dual-nature of business rules, the business perspective versus that of the technical culture. Until the early 1990s, the technology of rule-based systems ( often called 'expert systems' ) were largely a solution in search of a problem. Astute business people were particularly interested in the potential for short-loop development cycles, utilizing iterative development of prototypes rather than the monolithic "waterfall" approach.
The idea of externalizing program logic was vigorous in the 1980s, frequently expressing itself as table-driven applications. Some applications were quite ingenious, almost like an early form of the Document Object Model. Maybe a hundred or so of these COBOL behemoths are still running to this day.
One might say that, in a sense, even the most advanced rule-based technology is no more than a table-driven applications on steroids.
Ron Ross and the Business Rule Community was mentioned above.
Another important person in the history of business rules is Barbara Van Halle, who has been an indefatigable supporter of the technology ever since ... I'm not sure when. She wrote excellent articles about business rules in Database Programming and Design magazine the early 1990s. She can be found at Knowledge Partners.
First a note - the methodologies as described in these business rule sites are waaay more than is needed for a simple 'semantic web rule' methodology. They are shooting for 99.99% completeness and accuracy in transaction process systems that may be driving multi-billion dollar business units. The goals of this enterprise are far more modest.
One of the great 'classics' of business rules is the article
Defining Business Rules ~ What Are They Really?"".
It lays out the foundation of the popular GUIDE methodology. The acknowledgments
at the end are like a roll call of the BR Greats.
Terry Moriarty is one of the earliest and most prolific practitioners of the
art. You'll need to click around a bit to find the good stuff.
Select one of the subjects from the main menu to the right and when the subject
appears, click on the "related articles" to the lower right.
There you will find reprints of his many excellent articles in Database
Programming and Design and Intelligent
Enterprise.
David C. Hay been in the field for many years. He has many good articles
on his
Essential Strategies site.
Terry Halpin created a very powerful methodology called Object Role
Modeling ( ORM ), with a simple and intuitive graphical modeling
notation.
This is nicely written article with an extended example of Object Role
Modeling from Microsoft, entitled Object Role Modeling: An Overview.
See the Business Rules Manifesto in the Appendix. It's consistently cited as being the kickoff of the BR movement.
From a Wikipedia discussion about the term business model:
A definition from Osterwalder, Pigneur and Tucci (2005) is that a business model is:
... a conceptual tool that contains a set of elements and their relationships and allows expressing the business logic of a specific firm. It is a description of the value a company offers to one or several segments of customers and of the architecture of the firm and its network of partners for creating, marketing, and delivering this value and relationship capital, to generate profitable and sustainable revenue streams.
The model proposed by Osterwalder (2004) synthesises the different conceptualizations into a single reference model based on the similarities of a large range of models. The author's conceptualization describes a business model as consisting of nine related business model building blocks. Thus, a business model describes a company's business:
* value propositions: The company's offers which bundle products and services into value for the customer. A value proposition creates utility for the customer.
* target customer segments: The customer segments a company wants to offer value to. This describes the groups of people with common characteristics for which the company creates value. The process of defining customer segments is referred to as market segmentation.
* distribution channels: The various means of the company to get in touch with its customers. This describes how a company goes to market. It refers to the company's marketing and distribution strategy.
* customer relationships: The links a company establishes between itself and its different customer segments. The process of managing customer relationships is referred to as customer relationship management.
* value configurations: The configuration of activities and resources.
* core capabilities: The capabilities and competencies necessary to execute the company's business model.
* partner network: The network of cooperative agreements with other companies necessary to efficiently offer and commercialize value. This describes the company's range of business alliances.
* cost structure: The monetary consequences of the means employed in the business model.
* revenue model: The way a company makes money through a variety of revenue flows.
http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/
Conceptual Overview
A CRC cards is an index card that is use to represent the responsibilities of classes and the interaction between the classes. CRC cards are an informal approach to object oriented modeling. The cards are created through scenarios, based on the system requirements, that model the behavior of the system. The name CRC comes from Class, Responsibilities, and Collaborators which the creators found to be the essential dimensions of object oriented modeling.CRC cards where introduced by Kent Beck and Ward Cunningham in there paper "A Laboratory for Teaching Object-Oriented Thinking" released in OOPLSA '89. There original purpose was to teach programmers the object-oriented paradigm. When Kent Beck wrote the draft version of their paper he change Collaborators to helpers. Ward Cunningham changed it back to Collaborators when he reviewed the paper. The initials of Cunningham's son are CRC.
Why uses CRC cards?
Although CRC cards where created for teaching, they have proven useful for much more. They become an accepted method for analysis and design. The biggest contributing factor to there success is the fact that they provide an informal and non threatening environment that is productive to working and learning.
There must be many dozens of business rule architectures and frameworks. They are of interest, but usually not critical to the technical perspective. For now, links and references to business rules technology will have to be scheduled for the future.
Microsoft's entry in the BR technology arena, Biztalk.
http://www.microsoft.com/biztalk/default.mspx
Bizrules.info has good links to almost every aspect of business rules
technology, focusing on "building rule-based and knowledge-based applications, along with our experiences and best practices on rule harvesting, design, development, and
management".
Bizrules.info also makes an interesting disitnction between rule-based and knowledge-based systems,
Deciding between a Rule-Based or Knowledge-Based solution
These guidelines can help you decide which type of solution is best for you:
Best Practice: Rule-Based systems are best for real-time decisioning systems and compliance systems that have many simplistic rules and broad logic.
Best Practice: Knowledge-Based systems are best for advising systems and product selection systems that have more complex rules and deep logic.
They see rule-based systems as running in real-time with fairly simple rules,
for example monitoring some stream of data. Knowledge systems are advisor
system, running upon demand rather than continuously.
Some more definitions from Haley. I left in their product blurbs because they are largely true - their statement of features also include important criteria for evaluating the effectiveness of a rules engine. Haley is a a very solid, low cost solution. The Haley definition are so good that I've taken the liberty of including most of them, for future reference. No definition of "Semantic Web", alas.
Business process automation : occurs when technology components substituting and/or supplementing manual processes to manage information flow within an organization to lower costs, reduce risk, and increase consistency.
Business rules management systems enable business process automation.
Business rule :is a statement that defines or constrains some aspect of the business. A business rule asserts business structure to control or influence the behavior of the business, i.e. a process or procedure.
Business rules authoring tool : a technology application that captures, organizes, manages, allows for testing of business rules. HaleyAuthority is a technology-leading business rules authoring tool that not only enables users to capture, organize manage, and test business rules, but does so using real English.
Business rules inference engine :is the component of a BRMS system that performs the reasoning function or the runtime execution of rules authored with a business rules authoring tool. HaleyRules is the highest performance, most scalable business rules inference engine and has the smallest footprint.
Business rules management : is the use of rules platforms to automate business polices (such as pricing) as opposed to system policies (such as data validation and data integrity). Through the use of business rules management, ABC Company has gained the agility and flexibility to manage and change dynamic business logic - such as policies and procedures - without incurring IT development time and costs.
Business rules management systems (BRMS) : are software tools that work alongside or inside enterprise IT applications that enable enterprises to automate decision-making processes typically consisting of separate business rules authoring and rules execution applications. Haley's business rules management system enables businesses to extract business logic from core applications such as claims processing and CRM systems for 24/7 rules capture and implementation.
Knowledge base : is a database for knowledge management that provides the means for computerized collection, organization and retrieval of knowledge. Haley's natural language understanding makes it easier to make changes to the rules once the knowledge base has been built.
Natural Language (Natural Language Understanding or Natural Language Processing) : is a subfield of artificial intelligence and linguistics. It studies natural language understanding devoted to making computers "understand" statements written in human languages. Natural language business rules systems like Haley's business rules management system empower business users to program in English, the language of business.
Ontology:is a systematic arrangement of all of the important categories of objects or concepts which exist in some field of discourse, showing the relations between them. When complete, an ontology is a categorization of all of the concepts in some field of knowledge, including the objects and all of the properties, relations, and functions needed to define the objects and specify their actions.The Business Ontology Exchange (BOX) is a web-based exchange for business ontologies, where Haley partners and customers can share business and industry-specific knowledge bases.
Rules engine : see also: business rules inference engine. A software system that helps businesses manages business rules by allowing users to register, classify and manage all these rules, and verify consistencies between them.The HaleyRules business rules inference engine is the industry's fastest and most scalable business rules engine.
Rule Mark-up Language (RuleML) : The goal of the Rule Markup Initiative is to develop RuleML as the canonical Web language for rules using XML markup, formal semantics, and efficient implementations. RuleML covers the entire rule spectrum, from derivation rules to transformation rules to reaction rules. RuleML can thus specify queries and inferences in Web ontologies, mappings between Web ontologies, and dynamic Web behaviors of workflows, services, and agents.
Rules platform : is a framework either in hardware or software that allows software to run. So a rules platform is a software or hardware component that will allow you to run rules on your computer.Rules Repository : contains the domain knowledge coded in the form of rules. Both the rules authoring tool and the rules engine employ the rules repository.
HaleyAuthority and HaleyRules share a rules repository where from multiple users across the business enterprise can capture and share domain rules knowledge.
SOA, service oriented architecture : is the integration of the business as a set of linked, repeatable business tasks, or "services" (reusable software modules) which are independent of the applications or computing programs on which they run. SOA provides a framework for agile integration across applications. SOA allows different types of OS, for example, to communicate with a program.Haley's SOA-based Business Rules Web Service helps to advance rule server independence.
Tabular rules or decision tables : allows users to lay out in tabular form all possible situations which a business decision may encounter and specify which action to take in each situation. Both are also precise way to model complicated logic, similar to if-then-else and switch-case statements.
One of the programs supported by the SOA-based business rules Web Service will be tabular rules or decision tables.
Web Services : are web-based applications that dynamically interact with other Web applications using open standards that include XML, UDDI and SOAP. Such applications typically run behind the scenes, one program "talking to" another (server to server). Microsoft's .NET and Sun's Sun ONE (J2EE) are the major development platforms that natively support these standards.HaleyRules Web Services supports both XML over HTTP as well as Java Messaging Service that allows for asynchronous communication for sending and receiving messages.
Can the phrase "Web Rule" stand in place of "Business Rule" ?
RFP- Business Semantics of Business Rules
[ Note: it's in PDF format, 233K ]
Objective of this RFP
There is no generally accepted approach for defining or representing business rules. The objective of this RFP is to allow business people to define the policies and rules by which they run their business in their own language, in terms of the things they deal with in the business, and to capture those rules in a way that is clear, unambiguous and readily translatable into other representations.
Among those representations are presentation forms for business people and software engineers, and executable rules for many kinds of automated systems.
This RFP solicits proposals for the following:
• a metamodel for the specification of business rules by business people, with a MOF representation;
• a metamodel for the capture of vocabularies and definitions of the terms used in business rules;
• an XML representation of business rules and vocabularies based on XMI that permits exchange among software tools that manage, display, use, and translate business rules.
MetaObject Facility Specification
The MetaObject Facility Specification is the foundation of OMG's industry-standard environment where models can be exported from one application, imported into another, transported across a network, stored in a repository and then retrieved, rendered into different formats (including XMI, OMG's XML-based standard format for model transmission and storage), transformed, and used to generate application code.
These functions are not restricted to structural models, or even to models defined in UML - behavioral models and data models also participate in this environment, and non-UML modeling languages can partake also, as long as they are MOF-based.
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, 2006. 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.
| Home | Business Rules | Rule-Based Systems | Rule Engines | Under the Hood |