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 policies’

‘Business Rule’ Means These 3 Things

Software vendors and others mislead people (badly) about the true meaning of business rule. Let’s set the record straight. The OMG standard SBVR (Semantics of Business Vocabulary and Business Rules, 1.4) defines business rule as a rule that is practicable and is under business jurisdiction. The definition has these three parts: (1) rule, (2) practicable, and (3) under business jurisdiction. Let’s look at each part in turn. 1. Rule Rule in business rule means real-world rule – in other words exactly what the dictionary says rule means. Here are the relevant meanings of rule from Merriam-Webster Unabridged Dictionary [MWUD].

guide for conduct or action [MWUD ‘rule’ 1a]

one of a set of usually official regulations by which an activity (as a sport) is governed [e.g.,] *the infield fly rule* *the rules of professional basketball* [MWUD ‘rule’ 1f]

A real-world rule always tends to remove a degree of freedom.  If it does not, it’s not a rule. Also, a real-world rule is declarative. It never does anything. It merely shapes behavior or decisions. If you’re using an approach where rules can actually do things (e.g., execute an action, set a flag or variable, call a function, etc.), they’re not business rules. You’re in TechnologyLand, and a procedural one at that. 2. Under Business Jurisdiction    Business rule includes only rules that the business can opt to change or to discard. A business rule is always under business jurisdiction of your organization. The important point with respect to external regulation and law is that your organization has a choice about how to interpret the regulations and laws for deployment into its day-to-day business activity – and even whether to follow them at all. So external regulations are not business rules per se. Business rules include only the rules that a business creates in response to external regulation. SBVR explains:

“… legislation and regulations may be imposed on [the company]; external standards and best practices may be adopted. 

These things are not business rules from the company’s perspective, since it does not have the authority to change them. 

The company will decide how to react to laws and regulations, and will create business rules to ensure compliance with them.  Similarly, it will create business rules to ensure that standards or best practices are implemented as intended.”

3. Practicable Practicable means a rule is sufficiently detailed and precise that a person who knows about it can apply it effectively and consistently in relevant circumstances. In other words, the person will know what behavior is acceptable or not, or how some concept is to be understood. A practicable business rule is one ready to become a deployed business rule – i.e., applied in day-to-day business activity. Whether the guidance is to be deployed to staff or ultimately to machines is immaterial. You should get the same results either way. Business policies are generally not practicable in this sense. Business rules always are. ~~~~~~~~~~~~~~~~~~~~ Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015 Get the book:http://www.brsolutions.com/b_building_business_solutions.php Get the training: Instructor-led, online, interactive training: October 4-6, 2016 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php ©Business Rule Solutions, LLC 2016. wwwBRSolutions.com 

Continue Reading

Classifying Business Rules: I Go By What the Standards Say

      In classifying ‘rules’ I go by the standards … Business Motivation Model (BMM): business policies vs. business rules
  • Business rules are always practicable – workers can apply them directly.
  • Business policies are not – they must be interpreted first.
SBVR: definitional rules (necessities) vs. behavioral rules (obligations) vs. advices (possibilities or permissions).
  • Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
  • Behavioral rules are about shaping conduct (and can be violated).
  • Advices are non-rules; they provide practicable guidance but do not remove any degree of freedom.
I would add only these observations: 
  • The kinds of rules you see in decision tables are generally definitional. Since they represent only a subset of all definitional rules I call them ‘decision rules’ for convenience.
  • Condition-Action or Event-Condition-Action (ECA) rules are not business rules at all. They are representations of business rules (for a class of implementation platforms).
  • My smart phone can tell me in spoken English where the nearest gas station is. It’s only a matter of time before machines start ‘reading’ regulations, contracts, agreements, business policies, etc. to help people formulate (through dialog) practicable (and implementable) business rules. Can you imagine the productivity benefits?!
  • Decision tables are great. Everybody should use them. But they are a lot harder to design well than you might think.
  • The DMN standard can move things along significantly … if it is good, and it isn’t overhyped (which it already has been in certain quarters). I’m looking forward to it impatiently. But standardization (in equal parts a political process and a technical process) do take some time!

Continue Reading

Why Business Rules Will Always Remain in Structured Natural Language

I was reading a fascinating article in The Economist about how robots, including military drones and driverless automobiles, increasingly need ethical guidance[1]. What does that have to do with business rules, you ask? Read on … In the next five years, software systems will begin to appear that bypass programming going more or less straight from regulations, contracts, agreements, deals, certifications, warranties, etc. (written in English or other natural language) to executing code. Think about the economics of the equation! If for no other reason (and there are many others), you’ll quickly see the why a snowballing migration to such platforms is inevitable. And these tools will do the same for business rules based on business policies. I said more or ‘more or less’ above because the tool will have to make certain assumptions about the meaning of what it ‘reads’. For example, if I say, “a person must not be married to more than one other person” most of us would probably assume that means “at a given point in time”. But automated tools could easily be held responsible for making the wrong interpretation. It should therefore err on the safe side, and at the very least, log all its reasoning. That’s where the article comes in. Concerning robots that make liability-laden decisions, it contends that principles are needed …

“… to determine whether the designer, the programmer, the manufacturer or the operator is at fault if an autonomous drone strike goes wrong or a driverless car had an accident. In order to allocate responsibility, autonomous systems must keep detailed logs so that they can explain the reasoning behind their decisions when necessary.” [emphasis added]

That explanation better be in a form that humans (and lawyers too) can actually read. That means structured natural language. The article went on to make the following astute observation …

“This has implications for system design: it may, for example, rule out the use of artificial neural networks … decision-making systems that learn from example rather than obeying predefined rules.”

Right! Where there is social liability, there will always be natural language. P.S. To vendors: If your meaning of ‘business rule’ doesn’t compel you toward this debate, then you’re simply not really doing ‘business rules’(!).


[1] “Morals and the Machine”, The Economist, June 2, 2012, p. 15

Continue Reading

What Does Business Governance Have To Do with Business Rules? … Everything!

Business governance and business rules are directly linked. Bear with me for a moment while we go over what some words mean. So as not argue over them, let’s go to an authoritative source. The following definitions are from Merriam-Webster Unabridged Dictionary. govern [1a]: to exercise arbitrarily or by established rules continuous sovereign authority over; especially: to control and direct the making and administration of policy in Note the high-profile roles of (business) policies and (business) rules in this definition. I didn’t make that up. So ‘governing’ a business involves coordinating how business policies and business rules are created (the making … of) and deployed (managed, distributed and monitored) within day-to-day business operations (administration). governance [1]: the act or process of governing [2a]: the office, power, or function of governing [4a]: the manner or method of governing [5]: a system of governing Based directly on these definitions, here’s my definition for business governance. business governance:  a  process, organizational function, set of techniques, and systematic approach for creating and deploying business policies and business rules into day-to-day business activity Why haven’t more people recognized the direct link between business governance and business rules?! I wish I knew. Sooner or later, they will. ~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

Continue Reading

What is Agile? … Or Rather, What is It We Really Want to Be ‘Agile’?

This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php ~~~~~~~~~~~~~~~~~ Agile in software development is an IT development method featuring rapid iteration and prototyping. Agile software methods and business agility have nothing to do with each other. Agile in software development leaves off exactly where business agility picks up – at deployment. In working with clients we frequently come across systems that feature a very ‘open’ environment with few enterprise controls. Typically, this ‘flexibility’ resulted from diligent efforts by IT to satisfy many stakeholders individually. But the ‘flexibility’ is just an illusion. The failure of business-side stakeholders to come together and develop a collective business solution before ‘agile’ software development commences can plague the company for years to come. It reduces overall productivity, lowers customer satisfaction, and diminishes the capacity to make sound operational business decisions. It makes apple-to-apple financial comparisons virtually impossible. And it always costs a lot in ‘maintenance’. There are simply no magic bullets for building business solutions. Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing. All artificial (IT-based) production freeze dates for deployment disappear and the software release cycle becomes irrelevant. The only constraint is how long it takes business leads and Business Analysts to think through the change as thoroughly as they feel they need to. So the answer to my question is that business should be agile. Here then is our definition of business agility: being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and Business Analysts can determine the full business impact of the change and assess whether the change makes good business sense.

Continue Reading 2 Comments