Business Rule Concepts
Roux Bakeley
Within the context of the MVC pattern, the Controller and View components are only concerned with user interactions (the Controller with reacting to requests and the View with presenting the UI). All other code, including the business logic and database access goes in the Model component.
As the Model is usually quite large, it should have an additional internal structure, but that goes beyond the scope of the MVC pattern.
Commonly, the Model is structured in layers, with a layer for the business logic, a separate layer for the database access, and possibly additional layers.
Business rules are a pervasive responsibility of the application. The view should prevent the creation of conflicting schedules by not allowing them as an option; the controller should identify interactions and prevent their being formed in conflict. The model should prevent storage of conflicting schedules.
His newest works are:
- Business Rule Concepts: Getting to the Point of Knowledge,
4th Edition (2013, first published in 1998)
providing an easy-to-read, non-technical explanation of business rules.Order your copy now.
Building Business Solutions: Business Analysis with Business Rules,
with Gladys S.W. Lam. An IIBA Sponsored Handbook
Finally, a practical, proven, innovative guide to building great business solutions.Order your copy now.
Business rules guide the everyday decision-making within businesses by outlining the relationships between objects, such as customer names and their corresponding orders. This translation of an organization's business activities into concrete business logic allows software engineers and business analysts to apply these rules within workflow tools or other applications to enable process automation. Without them, updating processes can become more arduous and time-consuming, and documents can be subject to more human error and inconsistencies. By implementing business rules across an organization, a business can save time and money by streamlining work to the right stakeholders and reducing churn.
Some people can confuse the terms, business rules and business requirements, but they are actually very distinct and different. As a result, it's worth noting how they are used within business settings.
Business rules provide the foundation for automation systems by taking documented or undocumented information and translating it into various conditional statements. For example, when conducting a purchase order, there may be a different approval process depending on the cost. Tools and services that are under five thousand USD may only need manager approval, but as costs get higher, they may require approval by the C-suite. Business rules formalize this process by setting thresholds under which invoices are sent to upper management vs. first line managers. Conditional statements, such as these, are applied across a number of business processes.
Business requirements establish the success criteria for a given project. By specifying the tasks and resources needed to complete the project, teams can more clearly see the gaps and barriers to achieving their goal. This exercise is usually completed at the start of a business project to set expectations among stakeholders and address any additional needs for project completion.
Business rules can be classified in several ways, and they can vary in their classification depending on the source of information. However, irrespective of their categorization business rules are typically expressed using formal logic qualifiers, such as: "IF-THEN", "IF-ELSE", "ONLY IF", "WHEN", et cetera. This syntax is used across the following different types of business rules:
These types of rules are the foundation of rules engines, allowing organizations to automate business decisions to expedite a variety of processes, like customer orders and shipping. They enhance business processes by providing guidance on when these processes should be initiated, stopped or altered in order to enforce policies consistently across the business.
To help organizations remain responsive and agile, decision process automation software makes it possible to manage business rules independently from other business computing processes. In particular, business rules management systems (BRMSs) are capable of automating the creation and implementation of business logic in real-time without dependencies on other applications and processes, so that a single repository of decision logic can easily be shared across the entire enterprise.
Common tools for defining and managing the decision logic and a common runtime environment allow both developers and stakeholders with less technical backgrounds to efficiently implement and change automated decision-making processes. They also enable complex rule sets to be enforced consistently across large environments.
A business rules engine transforms one or more business rules into business logic that functions in a runtime production environment. Today, most business rules engines are integrated into full-scale BRMS solutions that can be integrated into services-oriented or microservices-based architectures. Modern BRMSs often employ machine learning or rules-based expert systems to optimize decision-making, improve customer experience and facilitate smoother operations.
I have an after business rule that runs on insert and update on the sys_user table. I create a new record in another table and need to check to see if the action on the sys_user table is an insert or an update.
I have tested multiple times and it is working. But whenever I add a condition to the condition builder or condition script, the business rule is not working. I have tested multiple conditions that should work, even one like Active is true. But no matter what condition I add, it makes the business rule not work.
Business rules should be externalized from processes and established as a separate resource. Rule Independence permits direct management of the business rules, so they can evolve at their own natural pace rather than that of the software release cycle. Other benefits include better process models, and much closer tie-in to the business side (a.k.a. business alignment). Business rules put your company on the road to true agility.
In the human body, control is provided by the nervous system, an organized collection of nerves that connect to the muscles. Business operations must have similar coordination of behavior. This coordination or guidance is supported by business rules.
Yet the idea of rules in business systems is ironically foreign to many people. Say "rules" and many IT professionals, for example, think vaguely of expert systems or artificial intelligence - approaches deemed appropriate for only very specialized or very advanced kinds of problems. Recognition has come only slowly about how central business rules actually are to basic, day-to-day business operations.
Not coincidentally, many business-side workers and managers have become so well indoctrinated in procedural views for developing requirements that thinking in terms of business rules might initially seem foreign and perhaps abstract. Virtually every methodology has been deficient in this regard, whether for business process reengineering, system development, or software design.
That omission is highly detrimental and very costly. Thinking about the control aspect of any organized activity in terms of rules is actually very natural. For example, imagine trying to explain almost any game you can think of - chess, checkers, baseball, football, tennis, and so on - without explaining the rules on which the moves in the game are based. Even if it were possible (that's doubtful!), explaining things that way would certainly not be very effective.
You naturally want each business rule to be specified once and only once. One-place specification (single-sourcing) means the business rule will be easier to find - and to change quickly. If you want true agility, business rules are the ticket.
Collectively, the set of business rules represents a separate rulebook for the business game. This rulebook should, of course, be automated, to provide scalable support for the origination and management of the business rules. You need special tooling for the rulebook, which I call a general rulebook system (GRBS).
Do business rules complicate matters for the business? No! Doing business is no more complicated by having independent business rules than are the games of chess, baseball, and football by having their own independent rulebooks.
Are business rules all that matter? Of course not! You still need artifacts for other needs, including process models, use cases, etc. These latter deliverables are needed to produce the raw power to do work - muscles for the business to flex. Business rules represent a well-developed nervous system, a way to ensure your business works smart.
A first step in understanding business rules is simply to relate them to the issue of guidance. The sidebar below presents a light sampling of typical business rules, each categorized informally according to the kind of guidance it provides. Note how far-ranging these categories really are. Every aspect of guidance for business operations can be addressed by business rules.
A second step in understanding business rules is to understand how they relate to a structured business vocabulary (often portrayed as a graphical fact model). Rules build directly on fact types. Basically, expression of a business rule simply adds a sense of obligation or necessity to terms and wordings already set up in the fact model.
Terms, Facts and Rules
The focus of business rules has often been described as terms, facts, and rules. Under the rigorous formal prescriptions of the new standard Semantic of Business Vocabularies and Business Rules (SBVR) this mantra, which dates to the early 1990s work of the Business Rules Group (www.BusinessRulesGroup.org), is not 100% technically accurate. Nonetheless it's memorable and certainly adequate for an initial understanding.