Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

What is a Concept Model?

A concept model organizes the business vocabulary needed to communicate consistently and thoroughly about the know-how of a problem domain. A concept model starts with a glossary of business terms and definitions. It puts a very high premium on high-quality, design-independent definitions, free of data or implementation biases. It also emphasizes rich vocabulary. A concept model is always about identifying the correct choice of terms to use in communications, including statements of business rules and requirements, especially where high precision and subtle distinctions need to be made. The core concepts of a business problem domain are typically quite stable over time.[1] Concept models are can be especially effective where:
    • The organization seeks to organize, retain, build on, manage, and communicate core knowledge or know-how.
    • The project or initiative needs to capture 100s or 1,000s of business rules.
    • There significant push-back from business stakeholders about the perceived technical nature of data models, class diagrams, or data element nomenclature and definition.
    • Outside-the-box solutions are sought when reengineering business processes or other aspects of business capability.
    • The organization faces regulatory or compliance challenges.
Definition of Concept Model

a model that develops the meaning of core concepts for a problem domain, defines their collective structure, and specifies the appropriate vocabulary needed to communicate about it consistently

The standard for concept models is the OMG standard Semantics of Business Vocabulary and Business Rules (SBVR).[2] Concept Model vs. Data Model A concept model differs from a data model in important ways. The goal of a concept model is to support the expression of natural-language statements, and supply their semantics – not unify, codify (and sometimes simplify) data. Therefore the vocabulary included in a concept model is far richer, as suits knowledge-intensive problem domains. In short, concept models are concept-centric; data models are thing-entity-or-class-centric. Data models can usually be rather easily derived from concept models; the reverse is much harder (or impossible). Like data models, concept models are often rendered graphically, but free of such distractions to business stakeholders as cardinalities. The Components of Concept Models[3] Noun Concepts. The most basic concepts in a concept model are the noun concepts of the problem domain, which are simply ‘givens’ for the problem space.
    • For BACCM these basic noun concepts are: need, stakeholder, value, change, context, and solution.
    • In finance, basic noun concepts might include financial institution, real-estate property, party, mortgage application, lien, asset, loan, etc.
Verb Concepts. Verb concepts provide basic structural connections between noun concepts. These verb concepts are given standard wordings, so they can be referenced unambiguously.
    • In BACCM some basic wordings for verb concepts include: Value is measured relative to Context, Change is made to implement Solution, Stakeholder has Need.
    • In a financial business, some basic wordings for verb concepts include: Lien is held against Real Estate Property, Party requests Loan, Asset is included in Mortgage Application.
Note that these wordings are not sentences per se; they are the building blocks of sentences (such as business rule statements). Sometimes verb concepts are derived, inferred or computed by definitional rules. This is how new knowledge or information is built up from more basic facts. Other Connections. Since concept models must support rich meaning (semantics), other types of standard connections are used besides verb concepts. These include but are not limited to:
    • Categorizations – e.g., Person and Organization are two categories of Party.
    • Classifications – e.g., ‘Toronto Dominion Bank’ is an instance of Financial Institution.
    • Partitive (Whole-Part) Connections – e.g., Dwelling and Land are two Parts of a Real Estate Property.
    • Roles – e.g., Applicant is the role that Party plays in the verb concept Party requests Loan.
Strengths A concept model:
    • Provides a business-friendly way to communicate with stakeholders about precise meanings and subtle distinctions.
    • Is independent of data design biases and the often limited business vocabulary coverage of data models.
    • Proves highly useful for white-collar, knowledge-rich, decision-laden business processes.
    • Helps ensure that large numbers of business rules and complex decision tables are free of ambiguity and fit together cohesively.
Limitations A concept model:
    • May set expectations too high about how much integration based on business semantics can be achieved on relatively short notice.
    • Requires a specialized skill set based on the ability to think abstractly and non-procedurally about know-how and knowledge.
    • Involves a knowledge-and-rule focus that may be foreign to stakeholders.
    • Requires tooling to actively support real-time use of standard business terminology in writing business rules, requirements, and other forms on business communication.
For more information about Concept Models, refer to Business Rule Concepts 4th ed, by Ronald G. Ross, 2013, Part 2. www.BRSolutions.com


[1] Ronald G. Ross, “How Long Will Your Fact Model Last? — The Power of Structured Business Vocabularies,” Business Rules Journal, Vol. 12, No. 5 (May 2011), URL:  http://www.BRCommunity.com/a2011/b594.html
[2] This discussion is consistent with that standard, but explains concept models from a business point of view. See the SBVR Insider section of www.BRCommunity.com for more information about SBVR.
[3] The first set of examples in each of the following two subsections is from the Business Analysis Core Concepts Model (BACCM), a part of the IIBA’s Business Analysis Body of Knowledge (BABOK), version 3.

Continue Reading

A Follow-Up Note to Business Analysts about ‘Decision’

In a recent blog post I called attention to the fact that there’s a major collision of terminology with respect to the term decision as used by different communities. See: http://www.brsolutions.com/2014/07/06/a-note-to-business-analysts-about-%e2%80%98decision%e2%80%99/ My basic observation was that both communities are correct in their own context – but since the contexts intersect the result is a significant potential for confusion.
  • Business Analyst Community. Decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
  • General Business Community. Decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.
Let me make some additional observations. A first question one should ask to clarify decision is what is the time horizon? Is it strategic or operational? A second question one should ask is what does decision actually refer to when used by each community for a given time horizon? Table. What Decision Refers to Based on Community and Time Horizon
Time Horizon of Decision

General Business Community

Business Analysis Community

strategic

strategic business decision strategic project decision or change initiative decision or option analysis

operational

operational business decision  —
  In contrast to operational decisions, strategic decisions are always longer in time horizon, and generally made only once (which isn’t to say they can’t be revisited sometimes). This point is true for both communities. The distinguishing characteristics of an operational business decision is that it:
  • Is highly repetitive (100s, 1000s, or more per day, hour, etc.).
  • Can be encoded as practicable business rules.
Note: My analysis doesn’t address operational decisions for the Business Analysis Community (the cell show with dashes). That’s not because decision isn’t applicable in that context, but rather simply because it’s outside the scope of the present discussion. I recently saw the following draft definition of decision, which illustrates the problem of mixed meanings quite clearly.

An activity to answer a question or select an option from a known or knowable set of possible options. Typically defined in terms of business rules and made in response to events or at defined points in a business process.

  • The first part of the definition is reasonable for decision in any usage. It applies to both communities and to any time horizon.
  • The second part of the definition pertains only to the meaning of operational business decision. Strategic decisions, whether for the General Business Community or for the Business Analysis Community, are generally not based on specific business rules and are not made in response to events or at defined points in a business process. Strategic decisions are simply different in kind from operational business decisions.
The focus of a strategic decision is also quite different for each of the two communities.
  • General Business Community: The focus is on conducting future business in a certain way.
  • Business Analysis Community. The focus is on conducting a proposed initiative in a certain way to change the business itself.
Bottom Line: For clarity, I would always qualify decision to indicate which kind is meant. We certainly don’t need any more confusion in business engineering than already exists! www.BRSolutions.com

Continue Reading

Concept Models Are Simply Not Data Models

I certainly understand the need for data models, and that fact they should be coordinated/integrated with process models. Who would question that these days?! But to re-engineer business decisions or knowhow-intensive business processes (or both), you need a structured business vocabulary – i.e., a concept model. The purpose of a concept model is to provide the terminology and wordings to write hundreds (or thousands) of rules coherently and consistently. Building such blueprint is not an insignificant undertaking. Yes, a concept model can be used as the basis for designing a model of the data needed to support processes, but that’s not its primary objective. Rather its purpose is to understand what the business rules and decision logic are talking about business-wise at ‘excruciating level of detail’ (to borrow a phrase from John Zachman). A concept model involves hundreds of terms, some whose meanings are obvious, some whose meanings you think are obvious but aren’t, and some whose meanings are simply mysterious. We constantly have to caution against setting expectations too high about how much integration based on business semantics can be achieved on relatively short notice. Even though it seems like ‘defining business terms’ should be relatively easy, concept modeling is by far the hardest work we do. The problem in virtually every organization in the world today is that these business semantics have never been developed well enough (think semantic, rather than functional, silos) to take automation of logic to the next threshold – i.e., to white-collar automation. Yet that’s exactly where a great many organizations currently want (and urgently need) to go. www.BRSolutions.com

Continue Reading 2 Comments

A Note to Business Analysts about ‘Decision’

Perhaps the following point about the term decision is already clear to all, but at the risk of stating the obvious, I’ll make it anyway. There’s a major collision of terminology with respect to decision as used by different communities.    
    • In the business analyst community, decision is often used in talking about business analysts’ own work – i.e., what methods to use, go/no-go on change, tool selection, choice of elicitation approach, etc. Its usage also seems to cover the sense of “management decision” – e.g., what course should project work take.
    • In the larger business community, decision always refers to a determination in business activity – e.g., should this applicant be given a mortgage, what should be charged for shipping an order, etc. This is the focus of decision in the business rules / decision engineering community.
In the context of their own communities both usages are correct. Unfortunately, the collision often results in confusion about the appropriate focus – and about which methods to use – for both audiences. In situations such as this, the best practice is to define the concept in question for each community. Terms considered to be obvious usually aren’t. It’s not clear to me that this has been done explicitly in the business analyst community. Another best practice is to qualify the term every time it’s used. So we always say operational business decision when talking about the business context, not just decision. That also distinguishes the concept we mean from other potential sources of confusion – e.g., strategic business decisions and system-level decisions or IT decisions. I believe what the business analyst community means by decision is strategic project decision or strategic change decision. But I can’t really be sure since as I say the term doesn’t seem to have been defined. www.BRSolutions.com

Continue Reading 3 Comments

Ten Rules for Validating Business Rules with Business People

Here are some practical do’s and don’ts we’ve learned on the years for validating business rules with business people in facilitated sessions. I should warn you, some of these points are counterintuitive.  
  1. Determine whether there is already a trusted source or implementation for a rule. Always re-use, don’t rewrite.
  2. Of course there are exceptions. There are always exceptions. Document them and move on.
  3. Limit discussion about organizational responsibilities for applying the rules. That’s a different discussion.
  4. A rule only addresses exactly what it says explicitly.  For example, “high credit usage” doesn’t necessarily mean “high risk”.
  5. How strictly a rule is to be enforced is a separate issue from just what it says. Focus on practicality and precision, not on whether a rule is strictly enforced or just a guideline.
  6. Don’t jump into whether or not current data elements support some aspect of the rule. That’s system design.
  7. Take it as a given that analytics might be used to sharpen some rules. That’s homework.
  8. The goal is consistency and precision for people too, not just for automation.
  9. Avoid brain churn. Eliminate all matters from further discussion except what remains uncertain. If a rule in isolation is not that important, just move on.
  10. Rules are living, breathing things. Don’t be afraid to put a stake in the ground, e.g., a specific number for a threshold, because with well-managed rules, it can be changed at any time.
www.BRSolutions.com

Continue Reading 2 Comments

The New Litmus Test for Business Agility

The point of knowledge (POK) is a real place. POK is where know-how – business rules – are developed, applied, assessed, re-used, and ultimately retired.  In other words, POK is where business rules happen. When you start to fully understand business rules, a whole lot of other pieces of the puzzle fall right into place.  You arrive at smart architectures, which gives you smart knowledge management and smart processes. In smart architecture, business systems become knowledge companions, enabling never-ending, on-the-job training.  Flash points of knowledge – real-time evaluation of business rules – enables dynamic processes and personalized, just-in-time delivery of up-to-date guidance. A smart architecture is one equipped to address the formidable challenges facing businesses today – the accelerating rate of change, massive customization, and products and services that are ever richer in knowledge.  Effective engineering of the POK is the new litmus test for agility. The question you should be asking: How do you get your company to the point of knowledge? ~~~~~~~~~~~~~~~~ Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php www.BRSolutions.com  

Continue Reading

Metaprocess vs. Governance Process

Mark Linehan commented[1]: Well-run businesses have a formal governance process: a business process for managing changes to other business processes. Defined this way, a governance process is a metaprocess. My reply: There is a governance process in every organization, whether well-run or not. Unfortunately it’s often unstructured and ad hoc. In any case, governance is about “the making and administration of [business] policy in [an organization]”[2]. Yes, the business policies can certainly have the effect of changing (transforming) other organizational processes. But that’s indirect. So I think calling a ‘governance process’ meta- is a bit tenuous.


[1] This series of point/counterpoint replies is a follow-up to my post “Meta Here. Meta There. Meta Everywhere?” (March 31, 2014), which generated a surprising amount of great discussion. (Thanks all!) Refer to: http://www.brsolutions.com/2014/03/31/meta-here-meta-there-meta-everywhere/ The definition I’m using for meta- is from Merriam-Webster’s Unabridged Dictionary [3b]:

3b: of a higher logical type – in nouns formed from names of disciplines and designating new but related disciplines such as can deal critically with the nature, structure, or behavior of the original ones *metalanguage* *metatheory* *metasystem* 

[2]from Merriam-Webster Unabridged Dictionary [“govern” 1a]

Continue Reading 1 Comment

Meta-Cognition

Julian Sammy, management consultant and all-around guru, commented[1]: What about metacognition?

awareness and understanding of one’s own thought processes,

or …

thinking that explores thinking.

My reply: Here’s some of what Wikipedia says about metacognition:

This higher-level cognition was given the label metacognition by American developmental psychologist John Flavell (1976). The term … literally means cognition about cognition, or more informally, thinking about thinking. Flavell defined metacognition as knowledge about cognition and control of cognition.

Following my ‘verb-not-proposition rule’ for meta- I get cognition that knows about, and controls, cognition. In other words, metacognition is about (also from Wikipedia) “when and how to use particular strategies for learning or for problem solving”. Yes, good one! http://www.brsolutions.com/


[1] This series of point/counterpoint replies is a follow-up to my post “Meta Here. Meta There. Meta Everywhere?” (March 31, 2014), which generated a surprising amount of great discussion. (Thanks all!) Refer to: http://www.brsolutions.com/2014/03/31/meta-here-meta-there-meta-everywhere/ The definition I’m using for meta- is from Merriam-Webster’s Unabridged Dictionary [3b]:

3b: of a higher logical type – in nouns formed from names of disciplines and designating new but related disciplines such as can deal critically with the nature, structure, or behavior of the original ones *metalanguage* *metatheory* *metasystem*

 

Continue Reading

Is There Such a Thing as Meta-Architecture?

Louis Marbel, President, Interactive Design Labs, commented[1]: Is there such a thing as “meta-architecture”? This is a simple one – yes! Let me explain. Essentially, an architecture description is a specification of the structure/form for organizing the function of system of interest in order to achieve its intended purpose effectively. The system of interest can be a building, bridge, enterprise, software system, application, enterprise/business data, etc. Now a meta-architecture is a high-order system that operates on an architecture specification as an instance/object, and can validate and/or evaluate the specification to determine consistency and coherence. This view of meta-architecture is consistent with predicate logic and concepts such as meta-types for software type systems, which are also specifications of the behavior of objects. My reply: You say “meta-architecture is a [high-order] system”. But you also say an “architecture [description] is a specification of … structure/form”. “Structure/form” is not the same thing as a “system”. So doesn’t that violate the fundamental meaning of meta- … something that operates on other things of its own kind? I have no doubt that there’s such a thing a meta-system. Should we think of (true) architecture as a system? http://www.brsolutions.com/


[1] This series of point/counterpoint replies is a follow-up to my post “Meta Here. Meta There. Meta Everywhere?” (March 31, 2014), which generated a surprising amount of great discussion. (Thanks all!) Refer to: http://www.brsolutions.com/2014/03/31/meta-here-meta-there-meta-everywhere/ The definition I’m using for meta- is from Merriam-Webster’s Unabridged Dictionary [3b]:

3b: of a higher logical type – in nouns formed from names of disciplines and designating new but related disciplines such as can deal critically with the nature, structure, or behavior of the original ones *metalanguage* *metatheory* *metasystem*

Continue Reading

Meta-System?

Alexander Samarin,Swiss business architect, commented[1]: You have defined metaprocess as a process that orchestrates or transforms other processes. I think that orchestrate is more relevant to “system of processes”. My reply: Good point about orchestrating being the right verb for meta-system rather than metaprocess. As always, we need to be careful not to think of system in just the computer sense. Merriam-Webster Unabridged Dictionary [MWUD] defines system in the sense I mean here as:

1a: a complex unity formed of many often diverse parts subject to a common plan or serving a common purpose  b: an aggregation or assemblage of objects joined in regular interaction or interdependence : a set of units combined by nature or art to form an integral, organic, or organized whole : an orderly working totality : a coherent unification

A system in that sense could include rules, roles and many other things. It’s much more than just a process. Huge difference. So yes, I agree with meta-system orchestrates other systems. http://www.brsolutions.com/


[1] This series of point/counterpoint replies is a follow-up to my post “Meta Here. Meta There. Meta Everywhere?” (March 31, 2014), which generated a surprising amount of great discussion. (Thanks all!) Refer to: http://www.brsolutions.com/2014/03/31/meta-here-meta-there-meta-everywhere/ The definition I’m using for meta- is from Merriam-Webster’s Unabridged Dictionary [3b]:

3b: of a higher logical type – in nouns formed from names of disciplines and designating new but related disciplines such as can deal critically with the nature, structure, or behavior of the original ones *metalanguage* *metatheory* *metasystem*

 

Continue Reading