To speak plainly, most companies have no coherent strategy for integrated compliance. Laws, regulations, contracts, deals, agreements, guarantees, warranties, etc. all represent business obligations, the very essence of business rules.

What form of traceability is needed for business obligations? Traceability from governing rules to automated rules, where:

• Governing Rules include acts, laws, statutes, regulations, contracts, MOUs, agreements, terms & conditions, deals, bids, deeds of sale, warranties, guarantees, prospectuses, citations, certifications, notices, and business policies
• Automated Rules include code tables, parameter settings, procedural code, implementation rule statements, help messages, etc.

Governing rules provide the baseline for running the business. These governing rules must be interpreted and supplemented, ultimately getting implemented in a wide array of platforms and tools.

In most companies today there is virtually no traceability for obligations between governing rules and automated rules. There’s an abyss, a big black hole, where there should be ready knowledge. Where does that leave the company?

• Companies’ corporate memory is riddled with disconnects and gaps. Going back in time, it is difficult or impossible to determine who interpreted what governing rules into what implementation components, or why they did it the way they did.
• Companies consequently are deeply dependent on hero-professionals to retain tacit knowledge. You hope they remember things correctly and thoroughly – and that they don’t leave the company.

A solution to the compliance challenge requires rethinking and reworking the traceability landscape for obligations to feature three layers of rules, not just two. The middle layer, practicable rules, is key.

practicable rule: an expression of a business rule that a capable (authorized) worker can read and understand and decide directly whether or not the business is in compliance in all circumstances to which the rule applies

Practicable rules are ones you can run the business by, whether or not ultimately automated. They should be expressed in structured natural language (e.g., RuleSpeak^®) based on business (not IT or data) vocabulary. Here is an example:

An account may be considered overdrawn only if cash withdrawal is greater than the current balance of the account.

The acid test for whether a business rule is practicable is this:

You can give the statement either to a knowledgeable worker for use in day-to-day business operations to apply manually, or give to IT for implementation in an automated system, and get the same results either way.

Is that possible?! Absolutely!

The re-engineered landscape for compliance and traceability reveals the two distinct interpretations that need to be tracked:

1. First, governing rules are interpreted into practicable rules.
2. Second, those practicable rules that can be automated (by no means all of them) are interpreted into specifications that automated platforms can execute.

The key to operational excellence for compliance is committing both kinds of interpretations explicitly to automated corporate memory right as they happen.

By the way, business-side rule management does not have to be pursued at an enterprise scale. You can start out at any scale, including the project level. 

~~~~~~~~~~~

Read more about the Big-5 business challenges: http://www.brcommunity.com/articles.php?id=b904

Compliance in a broad sense means satisfying obligations and delivering on promises. Even high-quality customer service involves compliance of this kind – your products and services are always what you say they are, and your delivery of them meets customers’ expectations.

Some critical observations:

 

1. Laws, regulations, contracts, deals, agreements, guarantees, warranties, etc. all represent obligations, the very essence of business rules.
2. These obligations are constantly amended, extended and (sometimes) terminated, so you need direct traceability for them.
3. The typical IT view of traceability is far removed from what the business actually needs to manage obligations.

Many professionals are so immersed in system development they cannot easily separate the notion of obligations (business rules) and requirements – e.g., specifications for modifying some system feature or procedure. Say ‘traceability’ and they immediately think traceability for requirements.

How system development needs to trace requirements into system designs is a very different proposition than the traceability needed for business obligations. The two kinds of traceability can and should be separated.

• Requirements are about building systems, whereas business rules are about running the business.
• Requirements generally fade into the background when a system is delivered, whereas deployment sparks a whole new phase of life for business rules.

~~~~~~~~~~~

Read more about the Big-5 business challenges: http://www.brcommunity.com/articles.php?id=b904

Practitioners should stop thinking of business rules as simply another form of requirement. The life cycles of business rules and of software releases are distinct. Each has its own audience and its own natural pace. They need to be radically decoupled. Your company’s business rules are a business asset that needs to be managed directly. For effective rulebook managementyou need a special breed of tool, which I call a general rulebook system (GRBS).[1] Such tools are readily available.[2] What kind of support should a GRBS provide? Business rules and the vocabulary on which they are based are central to the problem of supporting continuous change. They need to be right at the fingertips of both business people and business analysts. You also want traceability from original sources through to the points of operational deployment. You want to know who created what rules, for what purpose, when. That’s called corporate memory. Without it, you’ll never achieve the rapid change and business agility you seek. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

In BRS Question Charts (Q-Charts^TM) we refer to an operational business decision by the question it answers (a very nifty idea we pioneered). Does that mean a decision is a question? Shouldn’t decision refer either to the answering of a question or to the answer itself? To be clear, we definitely do not think or say that the question is the same as the decision. However, if decision is understood properly in a business rules sense (the trick), there is only one question[1] a decision answers. So as a (very) convenient shorthand, you can use the question as the name of the decision. With that issue aside, so which should decision refer to, the answering of a question or the answer itself? The dictionary will support you either way you go. From MWUD[2]:

1a: the act of deciding

1b: a determination arrived at after consideration : SETTLEMENT, CONCLUSION

If you’re a process person, you’d probably pick the first definition. But if you’re a true business rules person, you have to pick the second. From a business rules perspective, a decision is the answer (conclusion) you produce, not the act of producing it. The “act of” is something else altogether.[3] So a decision is an answer. But is answer alone enough? No. Digging a little deeper into MWUD we find these definitions:

determination [2]: the resolving of a question by argument or reasoning

decide [c] to infer or conclude from available indications and evidence

Here’s the point. For business rules it’s crucial to capture the logic path (reasoning, inferences) that gets you to the answer. To say that differently, for business rules just knowing the conclusion isn’t very useful; the determination must be directly traceable (from conditions or cases to conclusions or outcomes, and vice versa). So focusing on answer in isolation for decision doesn’t quite get you where you want to be. The bigger picture is that the answers are traceable. www.BRSolutions.com

I get this question all the time, and it’s a painful one, so let me answer on the record. Question: In our enterprise architecture tooling, there’s a business dimension in which we define Business Concepts (the real business language), and an IT dimension containing Information Objects (data organization model). How can we solve the problem that business expresses rules as they relate to Business Concepts, while IT needs to translate these into rules related to Information Objects? We don’t want to bother business with IT model concerns, nor duplicate the rules in two places. Can you please shed light on an elegant approach to this dilemma? My answer: The standard SBVR[1] provides the ‘elegant’ approach, which is technology that can “read” language based on the business vocabulary (e.g., RuleSpeak) and/or dialog with people to disambiguate those statements. Until such technology is commercially available – and why not, look what IBM Watson can do! – two forms of each statement are unfortunately necessary. The key for your rule management regime is to maintain traceability between them. By the way, the mapping is almost certainly 1:m, not 1:1. I wish I had a better answer, but there just is none today. All I can say is that current implementation technologies for business rules are very, very primitive. ~~~~~~~~~~~ Acks: Tom Andries www.BRSolutions.com

One way of looking at the Zachman Architecture Framework is that it is about asking the right questions in the right ways at the right times of the right people. The number of transformations (between the rows) is fixed … either they happen in your head or they happen via specifications to tools. Some developers have great heads, but personally I prefer the answers to be traceable, auditable, and reversible over time. BTW, the lower-level transformations could be automatable and simple … if only the higher-level specification support were powerful enough. And with machines more powerful every day, they should be.

You can find definitions and discussion of all terms in blue on Business Rule Community: http://www.brcommunity.com/BBSGlossary.pdf ~~~~~~~~~~~~~~~~~~~ rulebook:  the collection of elements of guidance for a business capability, along with the terms, definitions, and wordings that support them

Discussion:  The rulebook of a game enumerates all the do’s and don’ts (rules) of that game along with the terms and definitions (vocabulary) needed to understand the rules.  Each participant in the game, whether player, coach, referee or umpire, scout, spectator, or media person, is presumed to understand and adhere to the rules to the extent his or her role in the activity requires.  The rulebook sometimes suggests how to play the game to maximum advantage, but never dictates playing strategy.

Similarly, a rulebook in business includes the business rules (and advices) needed to perform day-to-day operational business activity correctly or optimally, along with the structured business vocabulary (fact model) needed to understand the business rules correctly.  Each participant in the business activity must adhere to the business rules to the extent his or her role requires.  The rulebook never dictates business strategy, but should reflect, enforce, and measure it. 

Unlike the rules for a game, however, business rules change, often quite rapidly.  Therefore knowing the original source of each business rule, its know-why, and its full history of modifications, as well as how and where the business rule is currently deployed, is essential in effective rulebook management.

rulebook management:  the skills, techniques and processes needed to express, analyze, trace, retain, and manage the business rules needed for day-to-day business activity general rulebook system (GRBS):  an automated, specialized, business-level platform for rulebook management

Discussion:  Key features of a general rulebook system (GRBS) include rich, interactive support for structured business vocabularies (fact models) and comprehensive traceability for business rules (not software requirements). 

Unlike a business rule engine (BRE) a GRBS is not run-time.  Think of a GRBS as more or less like a general ledger system, except for Business Analysts.  Because of the potential of GRBS to support compliance and accountability, a GRBS is indispensable for improved business governance.

~~~~~~~~~~~~~~~~~~ From Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA^® Sponsored Handbook, Business Rule Solutions, LLC, October, 2011, 304 pp, http://www.brsolutions.com/bbs  

Business computing today is characterized by a tangled web of interfaces and data movement from system to system, from source to sink. Knowing the official ‘systems of record’ is basic for resolving discrepancies and demonstrating compliance. But that’s merely a start. What your business really needs today is to know the rules of record. A focus on business rules, rule management, and decision management makes that possible. This post explains. First a little background. If every piece of data in the organization had a single, clear home, identifying official versions would be easy. But in today’s world, operational data is extracted, merged, massaged, re-platformed, and reported many times over, often obscuring original sources. Identifying a ‘system of record’ establishes which source is official for each element (or chunk) of data. In other words, it gives you physical traceability back to source.^[1] That’s a first and very basic step for compliance. What physical traceability doesn’t do is explain why that source may have a different value from the copy of the data you’re actually seeing. You might call that difference semantic drift (although that term probably dignifies what often is just plain sloppiness about the meaning and use of data). Since you can’t be sure what rules were applied to create the official version, you can’t easily do a delta on what you’re actually seeing. In other words, you have no semantic traceability back to source. From a compliance point of view, knowing the rules for source data is paramount. Of course, if those rules never changed, you might be able to reconstruct them at an acceptable price when and as needed for compliance. But today, change — at an ever faster pace — is the name of the game. Add massive personalization and customization to the mix and you quickly reach an impossible threshold of complexity and expense. The solution is simply never putting yourself in a position of having to reconstruct rules. Rather, you want to manage rules in such way to keep them ‘on the record’ — i.e., to maintain rules of record for each operational business decision your company makes. Impossible? Not at all. That’s exactly what business rules, rule management, and decision management is all about. There is proven technology to support it.^[2] All you need to do is change how you look at the problem. References [1] For additional background on ‘system of record’ see: http://en.wikipedia.org/wiki/System_of_record http://www.yourwindow.to/information-security/gl_systemofrecord.htm [2] For example, Raden and Taylor write, “Logging rules as they execute to create a record of how a decision was made is a common requirement of decision services. They can be managed like a typical logging requirement, except that using business rules makes it easier. Using business rules also makes it possible to use the logged information in both customer-facing and regulatory conversations, because the rules are more user-friendly.” James Taylor and Neil Raden, Smart (Enough) Systems: How to Deliver Competitive Advantage by Automating Hidden Decisions, Prentice-Hall (June 2007), ISBN: 0132347962, p. 358. ~~~~~~~~~~~~~~~~~~ The original version of this post appeared as: “‘Rules of Record’ ~ Why ‘System of Record’ Isn’t Enough,” Business Rules Journal, Vol. 9, No. 1 (Jan. 2008) http://www.BRCommunity.com/a2008/b385.html

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’(!).

There are very important differences in the traditions of business rules vs. expert systems. Perhaps that’s why business rules had a completely different origin. In any case, they didn’t start finding each other until the late 1990s. (The first Business Rules Forum Conference was in 1997 … and every year since except in 2000.) The general goal of expert systems was broadly to mimic intelligent behavior – any kind of intelligent behavior. As a colleague put it, that’s like trying to read the mind of God. Human behavior (even the not-so-intelligent kind) is exceeding complex. The goal of business rules was always to capture the rules of organizations, not individuals. That’s one or two or more orders of magnitude easier – those rules have to come from somewhere … and that ‘somewhere’ was originally knowable (even if an arbitrary design decision by some programmer). So the issue with business rules is as much about business traceability (rule management) as it is expression. This problem goes right to the very heart of business governance and business agility. Continuing to embed business rules in procedural code (a) makes the business rules very difficult to trace, and (b) very difficult and expensive to change. It’s like setting the rules in concrete. It also precludes the possibility in the future of supporting specification-time detection of anomalies and intelligent dialogs to help Business Analysts remove ambiguity. For business rules, it ultimately comes down to the words you use and ‘remembering’ the interpretations made of them. There’s no way to demonstrate compliance without words, and no way to support transparency and accountability without traceability. The solution to all these problems, which are problems of business governance and therefore business engineering, leads inevitably in one direction. That’s why I’ve put so much time into researching business rules since the early 1990s and before. (Originally we thought in terms of databases and integrity constraints, another difference in origin from expert systems.) It’s also why I’ve spent so much time on the SBVR standard over the past 6 years or more. (At the risk of oversimplifying hugely, SBVR is about words and sentences.) The bottom-line: The way we do things today simply has to change. Change does take time. It also takes false starts and trial-and-error. But we’ll get there. Hey, business automation is barely one human generation old. That’s incredibly fast in the big scheme of things. ~~~~~~~~~~~~~~~  Read more about the history of business rules: http://www.brcommunity.com/history.php