Business rule

Last updated

A business rule defines or constrains some aspect of a business. It may be expressed to specify an action to be taken when certain conditions are true or may be phrased so it can only resolve to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business. [1] Business rules describe the operations, definitions and constraints that apply to an organization. Business rules can apply to people, processes, corporate behavior and computing systems in an organization, and are put in place to help the organization achieve its goals.[ citation needed ] For example, a business rule might state that no credit check is to be performed on return customers. Other examples of business rules include requiring a rental agent to disallow a rental tenant if their credit rating is too low, or requiring company agents to use a list of preferred suppliers and supply schedules. While a business rule may be informal or even unwritten, documenting the rules clearly and making sure that they don't conflict is a valuable activity.[ citation needed ] When carefully managed, rules can be used to help the organization to better achieve goals, remove obstacles to market growth, reduce costly mistakes, improve communication, comply with legal requirements, and increase customer loyalty.[ citation needed ]

Contents

Introduction

Business rules tell an organization what it can do in detail, while strategy tells it how to focus the business at a macro level to optimize results.[ citation needed ] A strategy provides high-level direction about what an organization should do. Business rules provide detailed guidance about how a strategy can be translated to action.

Business rules exist for an organization whether or not they are ever written down, talked about or even part of the organization's consciousness. However it is a fairly common practice for organizations to gather business rules. This may happen in one of two ways.[ citation needed ]

Organizations may choose to proactively describe their business practices, producing a database of rules. While this activity may be beneficial, it may be expensive and time-consuming. For example, they might hire a consultant to comb through the organization to document and consolidate the various standards and methods currently in practice.

Gathering business rules is also called rules harvesting or business rule mining. The business analyst or consultant can extract the rules from IT documentation (like use cases, specifications or system code). They may also organize workshops and interviews with subject matter experts (commonly abbreviated as SMEs). Software technologies designed to capture business rules through analysis of legacy source code or of actual user behavior can accelerate the rule gathering processing.[ citation needed ]

More commonly, business rules are discovered and documented informally during the initial stages of a project. In this case, the collecting of the business rules is incidental. In addition, business projects, such as the launching of a new product or the re-engineering of a complex process, might lead to the definition of new business rules. This practice of incidental, or emergent, 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. This inconsistency creates problems that can be difficult to find and fix.

Business rules approach

Allowing business rules to be documented during the course of business projects is less expensive and easier to accomplish than the first approach[ citation needed ], but if the rules are not collected in a consistent manner, they are not valuable. In order to teach business people about the best ways to gather and document business rules, experts in business analysis have created the Business Rules Methodology. This methodology defines a process of capturing business rules in natural language, in a verifiable and understandable way. This process is not difficult to learn, can be performed in real-time, and empowers business stakeholders to manage their own business rules in a consistent manner.

Categories

According to the white paper by the Business Rules Group, [1] a statement of a business rule falls into one of four categories:

The most basic element of a business rule is the language used to express it. The very definition of a term is itself a business rule that describes how people think and talk about things. Thus, defining a term is establishing a category of business rule. Terms have traditionally been documented in a Glossary or as entities in a conceptual model.

The nature or operating structure of an organization can be described in terms of the facts that relate terms to each other. To say that a customer can place an order is NOT a business rule, but a fact. Facts can be documented as natural language sentences or as relationships, attributes, and generalization structures in a graphical model.

Every enterprise constrains behavior in some way, and this is closely related to constraints on what data may or may not be updated. To prevent a record from being made is, in many cases, to prevent an action from taking place.

Business rules (including laws of nature) define how knowledge in one form may be transformed into other knowledge, possibly in a different form.

Real world applications and obstacles

Business rules are gathered in these situations:

  1. When dictated by law
  2. During the business analysis
  3. As an ephemeral aid to engineers.

This lack of consistent approach is mostly due to the cost and effort required to maintain the list of rules.[ citation needed ]

While newer software tools are able to combine business rule management and execution, it is important to realize that these two ideas are distinct, and each provides value that is different from the other. 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[ citation needed ]. There is value in outlining an organization's business rules regardless of whether this information is used to automate its operations.

One of the pitfalls in trying to fill the gap between rules management and execution is trying to give business rules the syntax of logic, and merely describing logical constructs in a natural language. Translation for engines is easier, but business users will no longer be able to write down the rules.

Formal specification

Business rules can be expressed using modeling approaches such as Unified Modeling Language (UML), Z notation, Business Process Execution Language (BPEL), Business Process Modeling Notation (BPMN), Decision Model and Notation (DMN) or the Semantics of Business Vocabulary and Business Rules (SBVR).[ citation needed ]

Business rules

Business rules encoded in computer code in an operational program are known as business logic.

Similar to how business risks can be structured as:

If <condition(s)> Then <consequence(s)>

a business rule can be structured as:

When <condition(s)> Then <imposition(s)> Otherwise <consequence(s)>

See also

Related Research Articles

Knowledge representation and reasoning is the field of artificial intelligence (AI) dedicated to representing information about the world in a form that a computer system can use to solve complex tasks such as diagnosing a medical condition or having a dialog in a natural language. Knowledge representation incorporates findings from psychology about how humans solve problems and represent knowledge in order to design formalisms that will make complex systems easier to design and build. Knowledge representation and reasoning also incorporates findings from logic to automate various kinds of reasoning, such as the application of rules or the relations of sets and subsets.

<span class="mw-page-title-main">Software architecture</span> High level structures of a software system

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

<span class="mw-page-title-main">Data model</span> Model that organizes elements of data and how they relate to one another and to real-world entities.

A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities. For instance, a data model may specify that the data element representing a car be composed of a number of other elements which, in turn, represent the color and size of the car and define its owner.

The Web Services Business Process Execution Language (WS-BPEL), commonly known as BPEL, is an OASIS standard executable language for specifying actions within business processes with web services. Processes in BPEL export and import information by using web service interfaces exclusively.

A modeling language is any artificial language that can be used to express data, information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure Programing language.

<span class="mw-page-title-main">IDEF</span> Family of modeling languages

IDEF, initially an abbreviation of ICAM Definition and renamed in 1999 as Integration Definition, is a family of modeling languages in the field of systems and software engineering. They cover a wide range of uses from functional modeling to data, simulation, object-oriented analysis and design, and knowledge acquisition. These definition languages were developed under funding from U.S. Air Force and, although still most commonly used by them and other military and United States Department of Defense (DoD) agencies, are in the public domain.

<span class="mw-page-title-main">Requirements analysis</span> Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

<span class="mw-page-title-main">Data modeling</span> Creating a model of the data in a system

Data modeling in software engineering is the process of creating a data model for an information system by applying certain formal techniques. It may be applied as part of broader Model-driven engineering (MDD) concept.

<span class="mw-page-title-main">Business process modeling</span> Activity of representing processes of an enterprise

Business process modeling (BPM) in business process management and systems engineering is the activity of representing processes of an enterprise, so that the current business processes may be analyzed, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. Alternatively, the process model can be derived directly from events' logs using process mining tools.

<span class="mw-page-title-main">Information model</span>

An information model in software engineering is a representation of concepts and the relationships, constraints, rules, and operations to specify data semantics for a chosen domain of discourse. Typically it specifies relations between kinds of things, but may also include relations with individual things. It can provide sharable, stable, and organized structure of information requirements or knowledge for the domain context.

A BRMS or business rule management system is a software system used to define, deploy, execute, monitor and maintain the variety and complexity of decision logic that is used by operational systems within an organization or enterprise. This logic, also referred to as business rules, includes policies, requirements, and conditional statements that are used to determine the tactical actions that take place in applications and systems.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

<span class="mw-page-title-main">Enterprise modelling</span>

Enterprise modelling is the abstract representation, description and definition of the structure, processes, information and resources of an identifiable business, government body, or other large organization.

<span class="mw-page-title-main">Business architecture</span>

In the business sector, business architecture is a discipline that "represents holistic, multidimensional business views of: capabilities, end‐to‐end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders."

The Semantics of Business Vocabulary and Business Rules (SBVR) is an adopted standard of the Object Management Group (OMG) intended to be the basis for formal and detailed natural language declarative description of a complex entity, such as a business. SBVR is intended to formalize complex compliance rules, such as operational rules for an enterprise, security policy, standard compliance, or regulatory compliance rules. Such formal vocabularies and rules can be interpreted and used by computer systems. SBVR is an integral part of the OMG's model-driven architecture (MDA).

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

Business process management (BPM) is the discipline in which people use various methods to discover, model, analyze, measure, improve, optimize, and automate business processes. Any combination of methods used to manage a company's business processes is BPM. Processes can be structured and repeatable or unstructured and variable. Though not required, enabling technologies are often used with BPM.

<span class="mw-page-title-main">Systems modeling</span>

Systems modeling or system modeling is the interdisciplinary study of the use of models to conceptualize and construct systems in business and IT development.

In information technology a reasoning system is a software system that generates conclusions from available knowledge using logical techniques such as deduction and induction. Reasoning systems play an important role in the implementation of artificial intelligence and knowledge-based systems.

In business analysis, the Decision Model and Notation (DMN) is a standard published by the Object Management Group. It is a standard approach for describing and modeling repeatable decisions within organizations to ensure that decision models are interchangeable across organizations.

References

  1. 1 2 Business Rules Group, Defining Business Rules ~ What Are They Really?,