Jump to content

Business rule: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
YurikBot (talk | contribs)
m robot Modifying: de:Geschäftsregel
Line 43: Line 43:
* [[BPEL]]
* [[BPEL]]
* [[BPMN]]
* [[BPMN]]
* [[Ws policy]]


== References ==
== References ==

Revision as of 05:04, 20 June 2006

Business rules or business rulesets describe the operations, definitions and constraints that apply to an organization in achieving its goals. For example a business rule might state that no credit check is to be performed on return customers. Others could define a tenant in terms of solvency or list preferred suppliers and supply schedules. These rules are then used to help the organization to better achieve goals, communicate among principals and agents, communicate between the organization and interested third parties, demonstrate fulfillment of legal obligations, operate more efficiently, automate operations, perform analysis on current practices, etc.

Introduction

It is important to keep in mind that strategies and tactics are distinct from business rules. Business rules are the foundation on which strategies and tactics are built. The rules simply tell an organization what it can do while the strategies and tactics tell it how to do it to be successful in obtaining its goals. An analogy for the relationship between business rules and strategies would be the relationship between a road map and a path along the map to reach a destination.

Example business rule domains include:

  • marketing strategies
  • pricing policies
  • customer relationship management practices
  • human resources activities
  • regulatory forces
  • product and service offerings or operation work flows.

How business rules are gathered

Organizations may choose to proactively describe their business practices in a database of rules. For example they might hire a consultant to come through the organization to document and consolidate the various standards and methods currently in practice.

More commonly, business rules are discovered as part of a formal requirement gathering process during the initial stages of a project. In this case the collecting of the business rules are coincidental. Projects, such as the launching of a new product, might lead to a new body of business rules for an organization. I.e. this new product would require the employees to conceptualize about what the purpose of the organization is in a new way. This practice of coincidental business rule gathering is vulnerable to the creation of inconsistent or even conflicting business rules within different organizational units, or within the same organizational unit over time.

Real world applications and obstacles

Despite many software vendors, consultants and research institutions offering business rules solutions, business rules are usually only gathered when dictated by law, as the first step in the automation process or as an ephemeral aid to engineers. This is mostly due to the overhead and effort required to maintain this database of rules. This becomes most severe the more dynamic and fluid the business rules for an organization are, for example in start-up companies. Another factor mitigating usage is the lack of incentive for employees to part with their most valuable asset to the organization; their knowledge of the business rules. A third factor is access to viable technology for maintaining business rules. A classic solution is the Rule engine, but this still remains more the domain of University research.

Software packages automate Business rules using Business logic. The term Business rule is sometimes used interchangeably with Business logic; however the latter connotes an engineering practice and the former an intrinsic business practice. There is value in outlining an organization's business rules regardless of whether this information is used to automate its operations.

Best practices

  1. Declarative: A business rule is a statement of truth about an organization. It is an attempt to describe the operations of an organization, not an attempt to prescribe how an organization should operate. This is why business rules are said to be discovered or observed and not created.
  2. Atomic: A rule is either completely true or completely false; there are no shades of gray. For example a rule for an airline that states passengers may upgrade to first class round-trip tickets if seats are available and they pay the fare increase does not imply that this deal is available for just one leg of the journey.
  3. Distinct, independent constructs: Separate the things that define your business (the rules) from the processes (i.e. strategies and tactics). Don't build complex and cyclical dependencies - simplify and flatten the constructs.
  4. Expressed in natural language: In order to appeal to the broadest audience, it is almost always best to express business rules in a natural language without the use of a lot of technical jargon.
  5. Business, not technology, oriented
  6. Business, not technology, owned

Formal specification

If the situation merits this, business rules can be expressed in a very formal language. Highly technical enterprises such as the building of a bridge would be a potential case in point. Another might be if the goal is to automate the business rules gathering process. Example languages include UML, Z notation, Business Rules Markup Language, BPEL and BPMN.

It's also possible to write business rules in English, and to support them with a formal inference process. An advantage is that one can then automatically get English explanations of the reasoning. Please see the link to Internet Business Logic, below.

See also

References

  • Principles Of Business Rule Approach, Ronald G. Ross (Aw Professional, 2003) ISBN 0201788934
  • Business Process Management with a Business Rule Approach, Tom Debevoise (Business Knowledge Architects, 2005) ISBN 0976904802