Rule Independence[1] means that business rules are expressed directly, rather than embedded (and lost) in the flow of processes or application programs. That way the rules can be managed as an asset in their own right, separately from other artifacts. When people hear ‘separately’ sometimes they think that business processes and business rules are isolated from one another and never ‘talk’. No. You simply want to let them ‘bind’ as close to real-time business operation (‘run-time’) as possible. ‘Separately’ also means you can:

• Represent business rules in their natural form – declaratively – rather than procedurally.
• Simplify processes hugely, while at the same time create far more agile solutions.

Rule independence yields another benefit – reusability. By externalizing business rules from applications, you can single-source your business logic. Methodologies for business analysis that are comprehensively rule-friendly do exist and have been proven in practice.[2] They show you how to:

• Capture, express and validate business rules.
• Work with the business rules in the context of other deliverables.
• Set up the business rules to be managed for the long term.

~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Celebrating the 10^th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #5 Question: How do business rules support business agility? Think of business rules as expressing business practices. These practices can cover a wide range of business concerns, including the composition of products, the customization of services for individual customers, operational hand-offs with suppliers, implementation of regulatory constraints, and so forth. Historically, rules have been embedded (hard-coded) in processes, in many different places and often inconsistently. There is no easy traceability for any given rule. Changing rules inevitably requires IT intervention, along with the associated cost and delay. From a business perspective, the resulting business support is simply not agile. Business rules support business agility by providing pinpoint means to evaluate and modify business practices. Rules are expressed and managed independently of processes (a.k.a. rule independence). By that means they can be consolidated (single-sourced) and evolved more rapidly and reliability. From a platform point of view, the Manifesto says it this way …

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.

Clearly some platforms are far better than others in this regard. The quality of their support for rules should be a critical factor in selection and design. Unfortunately, many organizations are trapped as much by legacy platforms as by legacy systems. True business agility requires migration to new platforms as quickly and easily as possible. For example, a central concern of many organizations these days is mobile computing and social media – capabilities not even on the horizon ten years ago when the Manifesto was written. There’s no end to platform innovation in sight – and companies will always want to get on-board faster and faster. Is there any way of doing so without knowing your business rules? No! So the Manifesto recommends …

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

Always remember that business rules are what you need to run your business, not to design systems, at least directly. There will never be a future platform for which you do not need to know your business rules.  

Celebrating the 10^th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #3 Question: How do business rules relate to business processes? First, be clear that rules and processes are not the same. The point seems obvious, but it’s surprising how much difficulty many IT professionals have perceiving the difference. Indeed, if you’ve come up coding procedural programs or specifying use cases, seeing that rules are something different than procedural statements can be quite challenging, at least at first. So the Manifesto makes the point explicitly …

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

The result of separating rules and processes is rule independence, a pervasive idea across the Manifesto’s ten Articles. Its implications are far-reaching. For one thing, rule independence permits re-use of individual rules across all the processes and procedures of a business solution. Although IT professionals readily ‘get’ the importance of ‘re-use’, it’s probably not exactly the right term, however, to use for rules. If you were playing a game of chess or football, you wouldn’t say, “we re-use individual rules any time we can”. People don’t naturally talk like that. Instead, you’d probably say something like, “we apply individual rules wherever relevant.” In talking with business people and subject matter experts, we should be careful about wrapping what we say around implicit IT thinking. Rule independence also provides a new, high-power lever for rule quality, something difficult to achieve when rules are embedded in processes or procedures. Just as for the rulebook of a game, rules for the business need to be cohesive – that is, not conflicting, misleading or incomplete. You also need to apply the rules consistently, so your processes get consistent results in like circumstances. The Manifesto summarizes these important points as follows …

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.

 

Celebrating the 10^th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #2 Question: How do business rules fit with requirements? Rules are all around us in the real world – in the games we play, in the laws and regulations of society, in the limits we set for our children – everywhere. Yet for whatever reason, rules are seldom featured in requirements and IT methodologies. That’s very strange if you think about it. So the very first point of the Manifesto aims to correct that omission, and by doing so, to bring better balance to requirements …  

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

This first point does not suggest that business rules are more important than other requirements – for example, process models – but rather, co-equal. How can you organize or model any kind of activity without knowing the rules?! That understanding leads to the second point of the Manifesto …

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

The “discrete part of” in this statement is crucial. It means that rules should not be embedded in other deliverables – for example, use cases – so that the rules can be written once and then applied everywhere (single-sourcing). It also means the rules can be validated directly with business people and subject matter experts. The result is better requirements – and better communication. Another result is rule independence. The rules can now evolve independently of other architectural components, often much faster. By not hard-coding rules into application programs, much more agile business solutions can be achieved. The Manifesto makes the point this way …  

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.

 

Celebrating the 10^th Anniversary of the Business Rules Manifesto http://www.businessrulesgroup.org/brmanifesto.htm Question: What does the business rules ‘mantra’ mean? The traditional business rule mantra, a central idea of business rules, dates back to at least the mid-1990s. It is expressed in the Business Rules Manifesto (Article 3.1) this way:

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

Perhaps not obvious in the statement is the insistence on declarative expression of business rules. When business rules are expressed declaratively, no meaning (semantics) can be hidden in the sequence of the statements (“in between the lines”). Literally, you can read the statements in any order, and get the same meaning. The liberation of business rules from procedural means of capture and expression (e.g., processes, procedures, use cases, etc.) means that each statement can be validated on its own merit. It also produces the highest degree of reusability (for the business rules). The importance of ‘rule independence’ is expressed by the subtitle of the Manifesto: The Principles of Rule Independence. What do you get when you express business rules declaratively? Encoded knowledge, or as I prefer to say, know-how. The importance of capturing and retaining core business knowledge (know-how) is even more urgent today than when the Manifesto was written in 2002. It is emphasized by the heading of Article 3: Deliberate Knowledge, Not a By-Product (of requirements and IT development). Additional Note: In early 2012, SBVR was revised to focus more directly on real-world language and concepts (always its original intent)[1]. So the Mantra today would be more accurately expressed:

Business rules are based on verb concepts, as expressed by wordings. Verb concepts are based on noun concepts as designated by terms and names.

Literally, you need nouns and verbs to write sentences. A good business rule statement is always a sentence.