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

Ask yourself …

Why should every business define its own business vocabulary even though almost everybody operates in some larger community of practice? 

Why should every business invent its own business rules even though perhaps only 20% of its business rules directly impact competitive advantage? 

Why should regulatory bodies issue regulations without adequate definitions and provably correct (anomaly-free) business rules? 

Why should contracts, agreements, and deals be signed with terms of agreement and definitions already spelled out, only to have IT implement them essentially from the ground-up? 

What’s the knowledge economy? According to Wikipedia:

“Various observers describe today’s global economy as one in transition to a ‘knowledge economy,’ as an extension of an ‘information society.’  The transition requires that the rules and practices that determined success in the industrial economy need rewriting in an interconnected, globalized economy where knowledge resources such as know-how and expertise are as critical as other economic resources.”

Catch that part about rules?! ~~~~~~~~~~~~~~~~~~~~~~~ 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    

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php Let me use an example to sketch the workings of business rules in smart architecture based on points of knowledge[1].  Refer to the Figure to visualize how the system works.

Aside: I have been using this same slide since 1994(!).

Suppose you have a process or procedure that can be performed to take a customer order.

• An order is received.  Some kind of event occurs in the system.  It doesn’t really matter too much what kind of event this is; let’s just say the system becomes aware of the new order.
• The event is a flash point — one or more business rules pertain to it.  One is:  A customer that has placed an order must have an assigned agent.
• We want real-time compliance with business policy, so this business rule is evaluated immediately for the order.  Again, it doesn’t much matter what component in the system does this evaluation; let’s just say some component, service, or platform can do it.
• Suppose the customer placing the order does not have an assigned agent.  The system should detect a fault, a violation of the business rule.  In other words, the system should become aware that the business rule is not satisfied by this new state of affairs.
• The system should respond immediately to the fault.  In lieu of any smarter response, at the very least it should respond with an appropriate message to someone, perhaps to the order-taker (assuming that worker is authorized and capable).

What exactly should the error message say? Obviously, the message can include all sorts of ‘help’.  But the most important thing it should say is what kind of fault has occurred from the business perspective.  So it could start off by literally saying, “A customer that has placed an order must have an assigned agent.”  We say the business rule statement is an error message (or better, a guidance message). That’s a system putting on a smart face, a knowledge-friendly face, at the very point of knowledge.  But it’s a two-way street.  By flashing business rules in real-time, you have an environment perfectly suited to rapidly identifying opportunities to evolve and improve business practices.  The know-how gets meaningful mindshare.  That’s a ticket to continuous improvement and true business agility.

Smarter and Smarter Responses

Is it enough for the system simply to return a guidance message and stop there?  Can’t it do more?  Of course. For the order-taking scenario, a friendly system would immediately offer the user a means to correct the fault (again assuming the user is authorized and capable).  Specifically, the system should offer the user another procedure, pulled up instantaneously, to assign an appropriate agent.  If successful, the user could then move on with processing the order. This smart approach knits procedures together just-in-time based on the flash points of business rules.  It dynamically supports highly-variable patterns of work, always giving pinpoint responses to business events (not system events).  In short, it’s exactly the right approach for process models any time that applying know-how is key — which these days, is just about always! The Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) says this:  “Rules define the boundary between acceptable and unacceptable business activity.”  If you want dynamic processes, you must know exactly where that boundary lies, and how to respond to breaches (at flash points) in real time. Is that as smart as processes can get?  Not yet.  Over time, the business rules for assigning appropriate agents might become well enough understood to be captured and made available to the system.  Then when a fault occurs, the system can evaluate the business rules to assign an agent automatically.  At that point, all this decision-making gets tucked very neatly under the covers.  Even if the business rules you can capture are sufficient for only routine assignments, you’re still way ahead in the game. Smart architecture based on business rules is unsurpassed for incremental design, where improvement:

• Focuses on real business know-how, not just better GUIs or dialogs.
• Continues vigorously after deployment, not just during development.
• Occurs at a natural business pace, not constrained to software release cycles.

The Manifesto says it this way:  “An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.”  That’s exactly what you need for knowledge retention, as well as to move pragmatically toward the knowledge economy.  Business rules give you true agility.

---

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php For me the point of knowledge (POK) is a real place.  POK is where elements of operational business know-how — business rules — are developed, applied, assessed, re-used, and ultimately retired.  In other words, POK is where business rules happen.  Knowledge is power, so  you can also think about POK as point of empowerment. POK corresponds to point of sale (POS) in the world of commerce.  POK and POS are similar in several ways:

• In both, something is exchanged.  In POS, it’s goods.  In POK, it’s operational business know-how (from here on I’ll just say know-how).
• In the world of commerce, we often say that consumer and supplier are parties in point-of-sale events.  Each of us is a consumer in some point-of-sale events, and many of us act as suppliers in others.  The same is true for POK.  Each of us is a consumer of know-how in some POK events, and many of us act as suppliers in others.  Sometimes we switch roles within minutes or even seconds.
• A well-engineered experience at the point of sale has obvious benefits both for the consumer — a positive buying experience — and for the business of the supplier — real-time intelligence about sales volume, cash flow, buying trends, inventory depletion, consumer profiles, etc.  A well-engineered experience at the POK likewise has obvious benefits.  For the consumer, it means a positive learning experience.  For the business of the supplier, the benefits include real-time intelligence about the ‘hit’ rate of business rules, patterns of evolving consumer (and supplier) behavior, emergence of compliance risks, etc.

The consumer/supplier experience at  the POK is crucial to worker productivity and job satisfaction.  In no small measure, optimizing this experience is the real challenge in POK engineering.  It must  be deliberate.  After all, what’s exchanged  at the POK is know-how — something you can’t carry around in your hands. Today, much of your know-how is tacit — lose the people, you lose the know-how they carry in their heads.  How can you avoid that?  Make the know-how explicit as business rules.  That’s what POK are about. Critical success factors in engineering an effective POK include:

• Communication must be strictly in the language of the business, not IT.
• Interaction must be gauged to the knowledge level (and authorization) of each individual party.
• Less-experienced parties playing the consumer role must be enabled to perform as closely as possible to the level of the company’s most experienced workers.
• Know-how — business rules — must be presented and applied in a succinct, highly-selective fashion.
• Know-how — business rules — must be presented and applied in a timely fashion (i.e., ‘just-in-time’) to accommodate fast-paced refinement and change in business policies and practices.

You can find definitions and discussion of all terms in blue on Business Rules Community: http://www.brcommunity.com/BBSGlossary.pdf 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 ~~~~~~~~~~~~~ Discussion …  First a definition to make sure we’re on the same page …

incremental design:  developing a system through repeated cycles (iteratively) and in smaller portions at a time (incrementally)

Business rules are unsurpassed for step-by-step enhancement of deployed know-how in business capabilities over time (incremental design).  The Business Rules Manifesto[1] puts it this way:  “An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.”  That’s exactly what you need for know-how retention and to move pragmatically toward the know-how economy.  Support for incremental design with business rules is quite straightforward.  For example, a decision task might start off manual (performed by humans).  As time and resources permit, decision rules for handling the simplest cases can be captured and encoded, removing these cases from the manual workload.  Perhaps you start supporting a modest 20% of all cases.  The only required changes to the system to support additional cases are to specify:

(1) What new cases are covered (by providing appropriate selection criteria). 

(2) What new outcome(s) are needed (if any) for the new cases covered. 

(3) What new (encoded) decision rules should be used for the new cases. 

At a subsequent time, you ramp up to 50% of all cases, then perhaps 80%.  You may never get to 100% – nobody is talking about taking humans completely out of the loop for every operational business decision(!).  The net result is simply applying human resources where best suited, the really hard cases.

A Business Analyst recently said, “Business Rules themselves tend to be too unstructured to stand alone “. Au contraire! Well-expressed business rules are discrete, specific, and context-independent. Think about laws, regulations, contracts, agreements, deals, policies, etc. as common sources for business rules. Business rules are interpretations that make those things practicable. Those things can certainly stand alone. So can the interpretations. The test of ‘practicable’ (the term used in relevant standards) is ‘Can a worker who is authorized and capable know what to do or not to do as a result of reading it?’ Business rules must be well-structured to pass that test. More broadly, ‘practicable’ means ready to deploy into the business for workers to follow, or to pass over to IT as part of requirements in building systems – either way with the same results. Practicable business rules are encoded know-how of the business, vital operational IP. They are explicit, not tacit, so they can be retained, managed and re-used. Business rule management is the most practical means around for meaningful knowledge retention.

Celebrating the 10^th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #7 Question: How do business rules relate to knowledge retention? The classic test of whether knowledge is tacit or explicit is this: If you lose the person, do you lose the knowledge? Clearly, you want basic business know-how to be explicit, so a basic principle of the Manifesto is …

3.3. Rules must be explicit.  No rule is ever assumed about any concept or fact.

Rules capture and encode operational business know-how in a form that can be retained, managed and re-used. What are rules really about? A well-expressed rule is based on terms and facts (or more accurately, noun concepts and verb concepts). These concepts represent the basic stuff of the business – operational-level things that are talked about, managed and processed day-in and day-out, often many, many thousands of times. Rules provide criteria that guide this operational activity in a consistent way. So the Manifesto emphasizes …

3.4. Rules are basic to what the business knows about itself – that is, to basic business knowledge.  

In business, of course, knowledge is not an end in and of itself. Rather, the goal is consistent application of the knowledge – as well as its continuous improvement. Achieving these goals requires that the people who understand the knowledge – business people, subject matter experts, and business analysts – be able to work with it directly and effectively. After all, the true test of knowledge quality is not whether an application program runs, but whether you get the right (or best) results. So the Manifesto says …

9.3. Business people should have tools available to help them verify business rules against each other for consistency.

In the plainest possible terms, IT professionals simply shouldn’t be the ones to determine whether business logic ‘works’.

Celebrating the 10^th Anniversary of the Business Rules Manifesto http://www.businessrulesgroup.org/brmanifesto.htm Question: What does the business rules ‘mantra’ mean? The traditional business rule mantra, a central idea of business rules, dates back to at least the mid-1990s. It is expressed in the Business Rules Manifesto (Article 3.1) this way:

Rules build on facts, and facts build on concepts as expressed by terms.

Perhaps not obvious in the statement is the insistence on declarative expression of business rules. When business rules are expressed declaratively, no meaning (semantics) can be hidden in the sequence of the statements (“in between the lines”). Literally, you can read the statements in any order, and get the same meaning. The liberation of business rules from procedural means of capture and expression (e.g., processes, procedures, use cases, etc.) means that each statement can be validated on its own merit. It also produces the highest degree of reusability (for the business rules). The importance of ‘rule independence’ is expressed by the subtitle of the Manifesto: The Principles of Rule Independence. What do you get when you express business rules declaratively? Encoded knowledge, or as I prefer to say, know-how. The importance of capturing and retaining core business knowledge (know-how) is even more urgent today than when the Manifesto was written in 2002. It is emphasized by the heading of Article 3: Deliberate Knowledge, Not a By-Product (of requirements and IT development). Additional Note: In early 2012, SBVR was revised to focus more directly on real-world language and concepts (always its original intent)[1]. So the Mantra today would be more accurately expressed:

Business rules are based on verb concepts, as expressed by wordings. Verb concepts are based on noun concepts as designated by terms and names.

Literally, you need nouns and verbs to write sentences. A good business rule statement is always a sentence.      

I’m kicking off 2012 with a couple of things I just don’t get. Here’s the first one: Why is it that people discussing ‘knowledge management’ seem to have so little understanding of the core know-how actually needed to run (and change) day-to-day business activity? Core operational know-how consists of business vocabulary, business policies, and business rules. That ‘knowledge’ is currently locked away in IT applications and platforms (or in people’s heads) where it is virtually immune to change. That’s a boon to service providers and IT departments, but a bane to business agility. What business really needs today is agile governance … but few seem to be talking about that. P.S. Social media won’t help much here. You simply have to ‘do’ business rules.