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

Many or most IT methodologies remain essentially in the Dark Ages with respect to knowledge management. They seem to focus blindly on pumping out code faster and faster. We may be living in a knowledge economy, but we’re sure not acting like it. When I say knowledge management I don’t mean what probably comes to mind. I’m not talking about fuzzy text in vast e-mail archives or tacit knowledge in people’s heads. I’m talking about explicit business rules. Business rules (done correctly) represent knowledge – core operational knowledge. Many companies today are in peril of losing or outsourcing that knowledge. Who’s to blame? Business managers for not ‘getting it’ of course. But that’s just where the buck stops. Ultimately practitioners are to blame. They’re not making core operational knowledge tangible to their managers. How you make that kind of knowledge ‘real’? True business-side rulebook management[1] (which is not the kind BRMS offer).[2] That’s no longer optional either. In a knowledge economy your company simply can’t afford to lose its business rules! ~~~~~~~~~~~~~~~~~~~~~~~~~ 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

You can find definitions and discussion of all terms in blue on Business Rule Community: http://www.brcommunity.com/BBSGlossary.pdf ~~~~~~~~ 1. Business Governance We define business governance as follows: 

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

Our definition is based on Merriam-Webster Unabridged Dictionary [MWUD] definitionsfor governance 1, 2a, 4a, and 5. Why should any divergent definition be created?

1: the act or process of governing

2a : the office, power, or function of governing

4a: the manner or method of governing : conduct of office

5: a system of governing

And have a look at the MWUD definition of 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 rules and policies in that definition.  ‘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).  Clearly, business governance and business rules are directly linked.  Why haven’t more people recognized the direct link between business governance and business rules?! 2. Governance Decision The original decision to create a business policy or business rule is an example of a governance decision.  Governance decisions should be part of a special business process, the governance process, which also coordinates deployment and retirement of business rules.  To support business governance you need a systematic approach, which is provided by a rulebook and general rulebook system (GRBS).  These tools also provide the traceability needed to support compliance. 3. Governance Process We define governance process as follows: 

a series of business actions and checkpoints indicating who should be doing what (business roles), and when, with respect to deploying business policy and business rules

That just follows naturally, doesn’t it? ~~~~~~~~~~~ Excerpted 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, 2011, 304 pp, http://www.brsolutions.com/bbs

I’ve been writing a lot recently about the knowledge economy and what makes a business smart. Let me dig a little deeper. The kind of knowledge I’m talking about might be better described as know-how.

know-how:  accumulated practical skill or expertness …  especially:  technical knowledge, ability, skill, or expertness of this sort[1]

Know-how that you can encode and retain is represented by business rules and the structured business vocabularies (concept models) on which the business rules are based.  Know-how is a subset, a small one probably, of knowledge.  Briefly, knowledge can range from practical to theoretical, from certain to probabilistic, and from frequently applicable to infrequently applicable.  At the risk of saying the obvious, you can’t run the day-to-day operations of a business on knowledge that is theoretical, probabilistic, or infrequently applicable.  In short, business rules are about know-how management, a strictly limited subset of knowledge management. Like knowledge, know-how can be either tacit (in people’s heads) or explicit.  The classic test for when knowledge is tacit is ‘lose the person, lose the knowledge’.  Obviously you want to retain know-how. As a senior manager recently put it, “No organization should depend on absent brains.”

know-how retention:  expressing know-how explicitly in a form understandable by business people and business analysts, and managing the know-how, such that it is always available for future reference or use (by those capable and authorized)

The over-time infrastructure needed to retain know-how is provided by a general rulebook system (GRBS).  It’s what rule management should really be all about. ~~~~~~~~~~~~~~~~~~~~~~~ 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, 2011, 304 pp,http://www.brsolutions.com/bbs

United Airlines recently rolled out this new business policy regarding upgrades on one of its routes. Once you get past the fluff, it simply says its Houston-Lima route is no longer eligible for free upgrades. A practicable version of the business policy would be a bit wordier. How easy would it be for your company to deploy a change in business policy like this to all relevant operations and IT systems?  How long would it take and how much in resources would it consume? Would the results be traceable and reversible? The ‘thinking’ part of changing business policies will never be easy. The goal of rulebook management is to make the discovery and deployment parts as easy as single clicks. Why not move toward smart governance today?!

United Airlines today rolled out this new business policy regarding upgrades on one of its routes. How easy would it be for your company to roll out a change in business policy like this to all operations and all systems with a single click?

guest post by Cay Hasselmann ~~~~~~~~~~~~~~~~~~~ The two oldest references on a business rule language I personally could find was in the British Library. One was on the building of the Pyramid in the Cheops Dynasty (2613-2498 BC), where 100,000 workers were involved for over 20 years. In some scrolls you will find what I would say are part of a basic rulebook.       The other is from China during the Chou Dynasty (1046–256 BC), which is a rulebook for government officials.