Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘Business Rules Manifesto’

What Role for Business Rules in *Requirements*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th 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.

 


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.

Continue Reading 1 Comment

Business Rules Manifesto FAQ #1 – The *Business Rules Mantra*

Celebrating the 10th 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.      

[1]For discussion, see ‘Concept Model’ vs. ‘Fact Model’ … Where in the World are the Instances? http://goo.gl/Oz6UA.

Continue Reading

R.I.P. Straight-Line, Old-School Processes!

Consider the business rule: A vehicle must not exceed the posted speed limit. Some of the issues for this business rule are (a) how do you detect a violation and (b) how do you respond to a violation. These issues raise the question, whose process is it? Are we talking about the process of the person driving down the street, or the process of the policeperson operating the speed trap? The two processes are obviously related in some way, but definitely not the same. The cop’s process is best viewed as interrupting the driver’s process. Let me come back to that point in a minute. There are two fundamental kinds of business rules[1]:
  • Decision rules (or a little more broadly, definitional rules). These are the kind of business rules that expert systems traditionally addressed. It’s the kind you find in decision tasks – e.g., whether someone should be given credit.
  • Behavioral rules. These are business rules that can be violated – e.g., speeding down the street, or being off-sides in football. For behavioral rules you need cops or referees or whatever to interrupt a more basic process when a violation occurs. It’s just the natural way to do things (if you don’t want anarchy).
Aside: You might say the examples of behavioral rules I’ve cited (speeding and off-sides) are not automatable. Well, I’m less and less sure about that these days. I see a lot of cameras where I live ‘watching’ for cars running red lights. The camera takes a picture of your license plate and the position of the car in the intersection and you get a ticket in the mail. For the record, I haven’t gotten one. But they do make me more careful about yellow lights. In any case, a great many behavioral rules are automatable. They arise as interpretations of some law, act, statute, regulation, contract, agreement, business deal, MOU, business policy, license, certification, warranty, etc.  For these kinds of business rules, you need a ‘watcher’ outside the process, standing ready to interrupt the process if a violation occurs. A classic example: The fuel rods in a nuclear power plant must be covered with water. If a process of operating the power plant ever violate that rule, I want an immediate violation response to interrupt the guilty process(!). That business rule is about operating a power plant, but the same idea holds true for business processes in general. Detecting violations of behavioral rules is how you can stitch together dynamic processes in real time. Such dynamic processes cannot be achieved by embedding business rules in either a model of the business process, or the process itself. The ‘watcher’ must be on the outside, protecting the interests of the larger (business) community. Such rule independence is the fundamental idea of business rules, as expressed by the Business Rule Manifesto[2]. R.I.P traditional, hard-wired processes!    


[1] Based on SBVR, the OMG standard Semantics of Business Vocabulary and Business Rules. See the SBVR Insider section on www.BRCommunity.com for more information. [2]http://www.businessrulesgroup.org/brmanifesto.htm The Manifesto (2 pp, free) been translated into 15 languages.
 

Continue Reading 4 Comments

To: Business Process Manifesto … From: Business Rules Manifesto … Re: How Business Processes and Business Rules Relate

When the Business Rules Manifesto was published in 2003 (http://www.businessrulesgroup.org/brmanifesto.htm), I co-proposed the six items below related to business processes as an additional (eleventh) Article. The Business Rules Group (BRG) decided (probably wisely) to avoid that potentially controversial area, however, and concentrate on the core message of business rules. Since a Business Process Manifesto has been in the works, it’s worth going back over the proposed items. I believe they remain valid. So I dug them out of my Editor archives, cleaned them up a bit, and presented them below. Aside: In 2003 the BRG wasn’t careful about saying “business rule” (instead of just “rule”) and business process (instead of just “process”). But that’s what we meant – real-world rule and real-world process – not technical specifications. I’m very careful about that clarification these days. A great many people have a hard time seeing the difference. Item 1. Business rules guide business processes.

Comment: If this one is not self-evident, all bets are off.

Item 2. Business rules should be substituted for any activity in a business process where the result(s) of that activity can be produced by the business rules.

Comment: This item refers to what SBVR calls definitional rules – business rules that can derive, classify or compute something. For any given ‘something’, there might be only a single business rule, or a very large number of business rules. The ‘something’ could be an operational business decision requiring many dozens or hundreds of decision rules organized into decision tables.

One thing the item doesn’t say is that not all such ‘somethings’ need to be supported by business rules from the very beginning. In fact as Item 8.5 says, they don’t need to be. Business rules are very good for incremental development. (Development of what? Smart business processes.)

Item 3. Business rules can cause business processes to be initiated under appropriate circumstances.

Comment: Circumstances can arise that require the business to respond in a pre-scripted manner – e.g., low inventory status, potential fraud or intrusion, etc. Some business rule(s) should identify the circumstances involved in such ‘spontaneous’ business events.

Item 4. The default explanation or message for any error that occurs in a business process for a business reason is a business rule.

Comment: This item is truly ground-breaking. Business rules express the do’s and ‘don’ts’ of business activity; therefore, any error that occurs under a business process for a business reason is ‘explained’ by a business rule. What else could it be?!

Keeping systems carefully aside, and noting the obvious possibility of providing additional or alternative ‘explanations’, I like to say ‘the business rules are the error messages’. By the way, I’ve been saying that since 1994 – I have the slides (transparencies actually) to prove it. If you have doubts about this item, please provide examples(!).

Item 5. Any delay in the ability to enforce a business rule must be coordinated with business processes.

Comment: In SBVR, behavioral rules are business rules that can be violated. (Definitional rules can’t be.) An example where such delay might occur is a business rule that requires an approval or sign-off on something (e.g., an extra-large order on credit) by somebody (e.g., the branch manager) who is not immediately available. The business process for that particular something must be suspended until some future time.

Note: Additional business rule(s) providing appropriate suspense criteria (e.g., 24 hours) would be wise in such cases. We don’t want an order sitting in limbo forever(!).

Item 6. Business rules cannot constrain the workings of a business process directly, but only the following: (a) the state required for the business process to be performed; (b) the state while the business process is being performed; and (c) the results – that is, the state – the business process seeks to leave behind when finished.

Comment: I think of a business process as being like a black box with respect to business rules. The business rules cannot and should not ‘look’ inside. Instead, all matters of state should be externalized so business rules – and business people – can know it and talk about it. Get ready for this: This item indicts BPMN with its token-based approach to process state. The future lies with externalizing semantics. Sorry guys!

Continue Reading 24 Comments