Re-engineering knowledge work is the central problem of the knowledge economy. In recent work at Centers for Disease Control (CDC) and current work a major bank in Canada we used RuleSpeak® to create what I call a “single source of truth for operational business IP (intellectual property)”. This is far more than a conceptual data model. Beyond structured business vocabulary its central feature is comprehensive rules. It may be like what some professionals call a “conceptual ontology” (as opposed to an operational ontology to be embedded in IT systems). But we would never use the term “ontology” in our work.  Most business people and SMEs simply wouldn’t ‘get’ that. The idea is that all audiences (or subcommunities) in an organization should work off a single trusted source of explicit know-how (business vocabulary and business rules), no matter what their specific responsibilities:

• producing training materials for line workers.
• making changes in operational policies.
• providing proof of compliance for auditors.
• creating new products.
• communicating with IT.

Here are some key observations about our work to create a single source of business truth:

• Our primary audience is not IT. Yet our work is of sufficient precision that straightforward translation into an implementation form can basically be taken as a ‘given’.
• Our approach recognizes that people are the essential ingredient in business (as opposed to other kinds of knowledge problems). People can violate rules. For coordinating the work of people, direct support for behavioral rules, not just definitional or decision rules, is a must.
• Our work could not be undertaken without a structured natural language for business rules like RuleSpeak. The non-IT audiences do need rich business semantics, but they have no desire whatsoever to become semantic programmers. They simply would not commit if the work were conducted on that basis.
• No one today knows what the optimal syntax is for expressing all forms of business know-how in all circumstances. I suspect there isn’t one. That fact, plus the exponential increase in computer capability for processing natural language, indicates clearly that focusing on syntax is simply the wrong direction. RuleSpeak is based on, and was one of the reference languages for SBVR (Semantics of Business Vocabulary and Business Rules, on OMG standard), which supports a non-syntax approach. A language for ‘speaking’ with computers that is not a computer language – now that’s an idea whose time has definitely come!

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

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

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.

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.”

Business Process Models: A completed transform often achieves a business milestone and a new state for some operational business thing(s). Example: claimant notified. Fact Models: In fact models (structured business vocabularies) such states are represented by fact types, for example, claimant is notified (or claimant has been notified if you prefer). A fact model literally represents what things the business can know (remember) about completed transforms and other operational business events. Business Rules: Business rules indicate which states are allowed or required. They should not reference business processes or business tasks by name, just the states they try to achieve. For example, a business rule might be: A claimant may be notified that a claim has been denied only if the specific reason(s) for denial have been determined.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  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  

I’m an avid fan of soccer … and, of course, business rules. I recently found the following business rule via a Twitter search and just had to ask what it meant. FootballRascal – Can’t sign a player and then loan him out to another Premier League club in same window, business rule as fee charged Ronald_G_Ross – For U.S. audience, but avid football fans, what is motivation for not-in-same-window business rule? MeJonWhite – Personally, I have no idea, can’t see the logic. He could go on loan internationally, but not domestically. Ronald_G_Ross – Just one more ques. re not-in-same-window business rule. Uh, what’s a window? Period of time? Season? MeJonWhite – Summer window is July 1st – Sept 1st, it’s just the off season registration period. January is the Jan window. I am still in the dark, but I didn’t want to bug the kind folks any more. What I need is a blueprint to the concepts, a fact model, to bootstrap my way into a meaningful conversation quickly.

One of the first rules of business analysis should be never waste business people’s time. One of the fastest ways to waste their time is not knowing what they are talking about … literally … and do nothing about it. So you end up just wasting their time over and over again. Unacceptable. Is there a way to avoid it? Yes, by taking the time to understand exactly what concepts the business people mean when they use the words they use.  I believe business vocabulary should be job one for Business Analysts. If you don’t know (and can’t agree about) what the concepts mean, then (excuse me here for being blunt) you simply don’t know what you’re talking about. (And sometimes, unfortunately, neither do the business people … which is something important BAs should find out as early as possible.) So structured business vocabularies (fact models) are a critical business analysis tool. How else is there to analyze and communicate about complex know-how in a process-independent way?! Looking at the issue the other way around, you can make yourself look really smart about a complex area in a relatively short time by having and following a blueprint. We’ve had that experience many, many times in a wide variety of industries and problem areas. (Try jumping between insurance, pharmaceuticals, electricity markets, eCommerce, race care equipment, credit card fraud, trucking, taxation, healthcare, banking, mortgages, pension administration, ship inspections, and more! We do.) There’s no magic to it – like contractors for the construction of buildings, you must have or create structural blueprints. For operational business know-how, that means bringing an architect’s view to structure the concept system of the problem space …  just a fancy way of saying develop a well-structured business vocabulary. Then a whole lot of things will fall right into place for you. P.S. By the way, I’m not talking about any form of data modeling here. Also, there’s no real need to use the ‘S’ word (semantics) for it.  

Difficulties in communicating within organizations are by no means limited to communications among business workers, Business Analysts, and IT professionals. In many organizations, business workers from different areas or departments often have trouble communicating, even with each other. The business workers seem to live in what we might call semantic silos (reinforced by legacy systems).  A well-managed, well-structured business vocabulary (fact model) should be a central fixture of business operations. We believe it should be as accessible and as interactive as (say) spellcheck in Microsoft Word. Accessible business vocabulary should be a basic element in your plan for rulebook management, requirements development, and managing know-how.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  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    

I have been involved in a great on-going discussion on LinkedIn about data models. I posed the question: Is there any proven way to demonstrate data models are correct, complete, and stable with respect to the operational business and its needs? You might enjoy joining in: http://goo.gl/MsnXu It was literally 25 messages into the discussion that I realized “data model” was being used in two distinct ways in the discussion. And even then it had to be pointed out by a participant who seemed to know one of the other people.

• I always mean “data model” in the ‘old’ way, in which the data model supports real-time business operations (or close thereto). In that world, you must design for integrity, which generally means ‘highly normalized’ in the relational sense.
• In the old-but-not-nearly-as-old world of OLAP, real-time operations and updates are not a concern, so de-normalization (and redundancy) are presumably acceptable. (I’ll leave that question to the experts.)

That’s always the problem with vocabulary – deeply buried assumptions that prevent you from hearing what you need to hear. From experience, I know the trap oh-so-well, but here I fell right into it myself. What’s the answer to the question I posed for “data models” (of the kind I meant)? Focusing on the meaning and structure of business vocabulary, not data, as a core part of business analysis.  Note to self (a rule): When you enter any discussion, be clear what you mean by the terms you use – even (and maybe especially) the ‘obvious’ ones.