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

I am gearing up for a week of seminars (through FTI http://goo.gl/jtu2K1) and a keynote (at BASSA http://www.sbs.co.za/bassa2013/) in South Africa the next several weeks. To prepare me for my visit, Cecilia Pearce has kindly explained some of the rules of the road, and the related vocabulary, that apply in Johannesburg and Cape Town. I’ll report back on any discrepancies I run into. I hope not to run into anything else(!). Steve Erlank of FTI and Cecilia both write they are ‘holding thumbs’ for me. Turns out that’s a good thing. ‘Holding thumbs’ is an idiom used to wish good luck, like crossing your fingers. Who knew? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rules and Vocabulary Acks: Cecilia Pearce Behavioral Rule: The show of a hand, similar to the royal wave, solves all indiscretions that may have occurred. Behavioral Rule (with low enforcement level): A red light, on a robot, does not necessarily mean a vehicle will stop. Definition: A ‘robot’ is referred to as a traffic light in America. Behavioral Rules: ‘Taxis’ seem to believe they own the road. They have the right of way and may stop at any time. They may decide to switch their hazards on as they stop … if they work. Take care not to tailgate. Definition: A ‘taxi’ is a cross between a cab and a bus, but a mini version. It transports about 18 passengers. Definitional Rules for Taxis: A ‘taxi’ is not easily identified by color or signage. A ‘taxi’ may be recognized by:

• being in very bad condition.
• usually being overloaded.
• using its hooter almost all the time.

Definition: A ‘hooter’ is known as a horn in America. Motivation for Constant Use of Hooters: To attract possible passengers. Definition: A ‘hooter symphony’ occurs when there is a traffic jam. Note: Do not expect any resolution of the traffic problem from a ‘hooter symphony’. You’ll be disappointed. Behavioral Rules for the ‘Taxi’ System: Should you see somebody standing on the side of the road making weird hand signals, chances are that the signals are not intended for you. This is the mechanism used by prospective passengers to inform an approaching taxi of their destination. Facts: In South Africa the taxi driver is not provided with your destination; instead a taxi driver goes to specific destinations. Taxis have designated routes but not designated dropping-off areas. Major Behavioral Rule: And do remember, we drive on the left hand side of the road(!).

Business rules do not ‘float in space’. They mean only what the words they use are defined to mean. So they are tied directly to business vocabulary (concept model), which in turn is represented in a system by a data model or class diagram. These days if approaches for business systems don’t step up to semantics, they’re simply not state-of-the-art. BTW, with machines more powerful every day, they should be ‘stepping up’. That means direct support for structured natural language – e.g., RuleSpeak. ~~~~~~ See the latest on RuleSpeak 3.0 (free download): http://www.brsolutions.com/b_ipspeakprimers.php

1. No government or regulatory or similar body should issue operational policy unless the vocabulary is fully and precisely defined (in people language, as possible under SBVR) and the business rules are spelled out in practicable form (as in RuleSpeak). Try to imagine the amount of time and energy wasted because everybody has to do their own interpretation. Ridiculous in a knowledge economy. (Same basically true for legal contracts and agreements, etc.) There ought to already be an eMarket in off-the-shelf, industry-specific know-how models (vocabulary and rules). It will happen … sooner or later. 2. Is the DMN standard going to solve all your problems? No, of course not. It’s an important step in the revival and reinvigoration of decision tables, but you can already see all-too-familiar patterns of hype and misguided thinking. Yes, I would like the standard … needed badly (if it turns out to be good — an open question, but I sure hope so). 3. The OMG mission focuses on machine interoperability. When people need so badly to speak to other people precisely, and in a day and age when machines have become so powerful that they can begin to speak limited people language, isn’t perhaps the OMG mission a bit outdated or incomplete?

Rule: Every product must be tested on animals. Clear? Maybe not. Better define that bit of vocabulary ‘tested on animals’!

When one company acquires another, or two companies merge, there is inevitably much consternation over data migration. Indeed, it’s always a hard problem. Underlying every data migration problem, however, is a concept migration problem. By ‘concept migration’, I really mean integration of business vocabularies. After all, business vocabulary comes before data. Consider the case of two airlines merging their frequent-flyer programs. (I live in Houston – Can you guess which airlines I might be talking about?) The airlines need business rules for how concepts from the respective programs line up with each other. (At the onset I’m sure they won’t.) Even better, the airlines should start with a business strategy for the business problem (what we call a Policy Charter) and set of business policies, then develop the business rules. A corresponding problem exists in building a new business capability. An existing set of concepts exists (probably implicit in the data and not well-formed). You also have a revised set of explicit concepts in the form of a structured business vocabulary (concept model, also called fact model). Yes, you will probably have a data migration problem, but first you have a concept migration problem. So before your business model is complete, you need to develop an appropriate set of business ‘migration’ rules to specify how the transition in business practices should take place. In other words, you need to ask:

Are there concepts in the current business capability that need to be reorganized for, or ‘mapped’ to, the new or revised concepts of the future-form business capability?

Here is an example ..

Current Situation: Currently marketing reps can make hand-shake deals with customers on the road (‘road deals’). In the past, these deals were usually based on long-standing connections, so proper documentation of the details (often missing) was not too important.

With faster rates of turn-over and more specialized products this traditional business practice has become problematic. So the business will no longer support road deals. A new concept is being introduced for ‘spontaneous’ deals, called spot deal, which provides better coordination.

When the future-form business capability is deployed, however, some road deals will still be in force. How should these existing road deals be handled?

Business Tactic (in the Policy Charter): ‘Road deals’ are to be discontinued.

Business Transition Rule: Any “road deal” made in the past by a marketing rep that has never been formulated into a contract must be considered a spot deal.

A business transition rule is really about semantic migration. That fancy-sounding term isn’t needed though. At issue simply is knowing exactly what the words we use mean. Tackle that issue as a business problem, and the system solutions will fall into place. ~~~~~~~~~~~~~~~ My business partner, Gladys S.W. Lam, will be using the airline example in one of her talks at the Business Rules Forum Conference http://www.businessrulesforum.com/ Oct 28 – Nov 1 in Ft. Lauderdale.

I am pleased to announce that a comprehensive set of authoritative FAQs about the Business Rules Manifesto has been added to BRcommunity.com: http://www.brcommunity.com/brm.php The Manifesto is celebrating its 10^th anniversary this year – and remains as powerful and as vibrant to today’s business challenges as ever. I will be covering a good many of its insights in my Sunday tutorial, Business Rules: The Why and the What, at this year’s Business Rules Forum conference, part of BBC2012 (Oct. 28 – Nov. 2, Ft. Lauderdale, FL): http://www.buildingbusinesscapability.com/ The FAQs explain in-depth how the Manifesto relates to a great many pressing issues on today’s business agenda, including …

• Requirements
• Business Processes
• Business Analysis
• Business Agility
• Enterprise Architecture
• Zachman Framework  
• Knowledge Retention
• Events
• Enforcement

The new BRCommunity Insider also provides insight into the general positioning and structure of the Manifesto, as well as point-by-point clarification of individual Principles. The Manifesto is just 2-pages and free. It has now been translated into some 15 languages: http://www.businessrulesgroup.org/brmanifesto.htm The Manifesto is a rare thing in our field – a timeless work that seems more and more prescient which each passing year.

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  

1. ‘I’m not sure what that means.’
2. ‘That’s not what I meant.’
3. ‘I thought that was in scope.’

~~~~~~~~~~ From Alexander Gunjko’s presentation at the Sydney Building Business Capability (BBC) Conference – Sept. 10-11, 2012

From Matthew Cooper’s presentation at the Sydney Building Business Capability (BBC) Conference – Sept. 10-11, 2012 …

• “No progress will be made until you achieve a common business vocabulary. You just have to have it.”
• “Vocabulary, facts, rules. You can’t do them one at a time. You have to do them together, iteratively.”
• “Writing business rules helps you get your concept model right … and find out when it’s wrong.”
• “It’s uncanny how business rules help you identify inconsistencies and problems in current or proposed practices so early-on. Massive benefit!”
• “In our experience not more than perhaps 10% of project effort went to establishing a common vocabulary.”