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

Fundamental Challenges Facing Your Business: #2 – Business Communication

Do people in your company always mean the same thing when they use the same terms? Almost certainly not, right?! So ask yourself, how good are your business communications and requirements likely to be if people don’t mean the same things by the terms they use? And how good is your automation likely to be? Gurus talk about application or functional silos in organizations. I believe the problem is even more basic than that – organizations today essentially have semantic silos. Look under the covers of any broken process or poor set of requirements and you inevitably find poor communication practices. These days you don’t have the time not to define, structure and manage your business vocabulary. These days a concept model[1] is no luxury. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com


[1] Ronald G. Ross, “What Is a Concept Model?” Business Rules Journal, Vol. 15, No. 10 (Oct. 2014), URL:  http://www.BRCommunity.com/a2014/b779.html

Continue Reading

Circular Definitions: Quiz

Question: Can you spot the circularity among these three definitions?

Need: a problem, opportunity, or constraint with potential value to a stakeholder

Solution: a specific way of satisfying one or more needs in a context

Stakeholder: a group or individual with a relationship to a change or a solution

  Answer 1: The definition of “need” references “stakeholder”, whose definition references “solution”, whose definition references “need”. The definitions don’t need to be circular. It’s simply bad definition/glossary practice. How can the circularity be removed? “Need” should simply be defined as “problem, opportunity, or constraint”. That’s the essence of the concept. Whether it has “value to a stakeholder” is an assessment. Just because one person says something (a need) has value and another person says it (the need) does not (which happens all the time by the way) doesn’t mean the thing is not a need to either: (a) the person who has it, or (b) the person who says it has no value. The latter person would say “that need has no value”. He/She just called it a “need”, so how can it not be a ‘need’? Answer 2: There is actually a second circularity in the definitions: need –> value –> stakeholder –> solution –> need. Changing the definition of “need” as I propose above will fix that second circularity too. “Need” is a very basic concept. If there were no need, there would be no reason to assess what value it has to what stakeholder (including the one who proposed it). If there were no need, there would be no solution, context or change (in the BA’s world). It’s a seed concept. Principle: In developing a vocabulary it’s best to start from terms whose definitions use no other terms … i.e., from seed concepts. Otherwise, circularities will make Swiss cheese of your brain. www.BRSolutions.com

Continue Reading

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

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

Rules and Vocabulary of the Road for South Africa

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(!).

Continue Reading 1 Comment

What’s the Concept?!

In a data modeling discussion forum, a practitioner recently asked:

Has anyone seen an object super-type used to encompass both Party and System Component?

Examples of Parties: people, organizations

Examples of System Components: projects, proposals, computer systems

In over a dozen responses, not one person asked for a definition! My Response I’m surprised … no amazed … no horrified … by this discussion. It pretty well illustrates my frustration with data modeling. I should simply point out that in the real world, projects and proposal are not system components in the sense probably meant, then stop right there. Clearly the question mixes apples and oranges. But let’s work it through a bit more. What is the thing that that the proposed supertype (more general concept) would represent? … Which is to say, how would you define the notion in your head when you say the corresponding thing exists in the real world? If you can’t define the concept in any coherent way, that should be the end of the discussion. This is why I recommend starting with concept models, instead of data models. Since I’ve done a few data models in my time, I’ll jump to the other side of the fence and propose a definition for the sake of discussion.

more general concept x: an agent that can make and respond to requests

Systems, people, and organizations can all do those things. However, proposals can’t … unless you are talking about a software object representing a proposal. So here’s a revised definition …

more general concept x: a software agent that can make and respond to requests

But any software object can basically do that. Is that what is meant? Are we talking about (a) things that exist (can be jointly classified) in the real world, or (b) things that exist in software representations of the real world? My fear is that concept x is simply a design artifact that doesn’t really correspond to anything. It’s just an optimization for technology’s sake. Do we really want to go there?!

Continue Reading

Words of Wisdom re: Business Rules Initiatives from the Sydney BBC Conference … See If You Agree

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

Continue Reading

‘Concept Model’ vs. ‘Fact Model’ … Where in the World are the Instances?

In a dramatic development, the new release of SBVR (1.1) has replaced the term “fact type” with “verb concept”, and the term “fact model” with “concept model”, for all business-facing use.[1] Why the problems with “fact type” and “fact model”? Let me see if I can explain. First some background: Since its inception in the early 2000s, the OMG standard SBVR[2] has focused on “fact type” and “fact model”. That’s no accident – the underpinning of SBVR in formal logic is based on the work of Terry Halpin, who in turn based his work on Sjir Nijssen’s. Sjir Nijssen was using the terms for database models as early as the 1970s. By the way, both bodies of work are world-class. Now to the problems: If someone gives you an example or instance of a customer, where is that customer? In a database? No, of course not. The customer is out there in the real world. Similarly, suppose someone gives you an example of some customer visiting some retail store. Where did that visitation take place? In a database? Again, of course not. The visitation also happened out there in the real world. The bottom line is that when most people talk about things, those things exist or happen in the real world. But not if those people happen to be logicians or database gurus. Then instances of the things they talk about formally are likely to be in some database – i.e., data. The formal terminology is usually more refined – e.g., “population of facts” – but it is what it is. And it’s not the same stuff as is in the real world. Where does that lead you? If you’re a logician or database guru, you need to classify all the facts – hence “fact type”. You also need a model of all the fact types – hence “fact model”. If you’re not a logician or database guru, however, you’re clearly going to need something else. What exactly fits the bill? Here’s a clue: Databases hold data; those data represents facts. Those facts have meaning, but to understand that meaning you need to understand the concepts that are used. In business basically all we have is words to refer to things in the real world. What do those words communicate? The words communicate what you mean; that is, the ideas or concepts you have in your head when you say or write them. So what we need – or more precisely, what we need to share – is a model of what you mean by those words. In short we need a concept model. More on SBVR The world might or might not need another information modeling standard. The point is debatable. The soul of SBVR, however, lies in meaning[3] and language – what concepts we mean by the words we use in business communications (especially but not exclusively business rules). In the standards landscape that focus sets SBVR apart. What kind of language concepts do we need in organizing and expressing meaning? The answer is really quite simple (once you see it) – you need nouns and verbs. Those nouns and verbs stand for concepts – noun concepts and verb concepts, respectively. For example:
  • The noun “customer” might stand for what is meant by the definition “one that purchases some commodity or service”. 
  • The verb “visits” (as in “some customer visits a retail outlet”) might stand for what is meant by the definition “customer physically appears at retail outlet”
There is no other practical way to communicate business concepts and establish relationships among them. You need nouns and verbs to write sentences and convey meaning – it’s as simple as that. Once you look at the problem this way, forcing “fact model” and “fact type” on business people is unnatural and unnecessary. It commits a cardinal sin in business analysis – using unnatural terms for natural business concepts. The most natural terms for the concepts meant by SBVR are “concept model” and “verb concept”. About Business Rules For my part, I didn’t arrive at this understanding through the path above – or for that matter any other path you are likely to guess. The need for the shift dawned on me when I saw business rules being included in populations of facts. Hold on, how could a rule be treated as a fact?! Well, exactly! To a logician or database guru, however, treating a rule as a fact makes perfect sense. Formal logic is all about propositions. A business rule is a proposition taken to be true – in other words, a fact. So of course business rules belong in populations of facts and therefore in fact models. It couldn’t be any other way. And I agree. The only problem is that in SBVR we want to talk directly about the real world. The Bottom Line So a concept model in SBVR is a ‘map’ of noun concepts and their relationships based largely on verb concepts.[4] Actually, it’s more than that. By ‘map’ I don’t mean either of the following on its own:
  • A set of concepts and definitions loosely related (e.g., a glossary) – although definitions are clearly essential. 
  • Some diagram(s) – although often quite useful.
Rather, I mean a non-redundant, integrated, anomaly-free structure of concepts based on interlocking definitions – a blueprint of meanings. How is an SBVR-style concept model different from (and better than) a traditional “conceptual data model” (or entity-relationship diagram)? Instead of mere lines to represent relationships between noun concepts, with an SBVR-style concept model we have verbs. These verbs reveal the intended meanings of the relationships. With verbs I can verbalize – literally communicate (and demonstrate) what is meant. No more hidden meaning!


[1] But not in the underpinning of SBVR in formal logic.
[2] Semantics of Business Vocabulary and Business Rules. See the SBVR Insider section of www.BRCommunity.com for discussion. SBVR 1.0 was released by OMG in December, 2007.
[3] I refuse to use the “S” word here. There’s really no need for it. Few business people I’ve ever met say “semantics” in the course of normal business conversation, except perhaps in the sense of “Oh, that’s just a matter of semantics.” (which indeed, to be fair, it usually is).
[4] I say “largely” because certain important structural elements of concept models, including classifications and categorizations, are not based on verb concepts.

Continue Reading 3 Comments

Moving the Goalposts for Data Models … Deliberately

A practitioner recently said this: “Even if we assume that a technical methodology might exist to generate a complete and correct data model from a set of articulated business rules / facts, in my opinion this approach just moves the target from the data modeling area to the need to verify the articulation of business facts / rules for completeness and correctness.” Exactly! And why would that be a problem?! Here’s an additional advantage: The core concepts (concept model or fact model) of an operational business area are very, very stable. Don’t believe it? As proof see http://www.brcommunity.com/b594.php (short case study, well worth a quick read). The problem with current data modeling practices is that a large gap often exists between the business view of things (operational business things) and the ‘data’ view of those things – even when trying to keep to a ‘conceptual’ view. This gap gives business-side people a ready excuse to drop out. But data modelers alone can’t provide the necessary business know-how for a robust, complete model. The problem is so big, it’s hard to see. Current data model practices evolved bottom-up, from database designs. (I believe I can speak with some authority here. I was editor of the Data Base Newsletter, 1977-1999, and wrote three books related to the matter in the late ‘70s and early ‘80s.) It’s time for us to approach the problem top-down. There is a natural way to build concept systems – it starts with basic business communication. The standard for such an approach already exists – SBVR. (For discussion see BRCommunity’s SBVR Insider section.) We’re already living and working in a knowledge economy … We need to start acting like it!

Continue Reading

Data Modeling: Art or Science?

A practitioner recently commented: “Everyone has their biased view of what a data model is. Data modeling is art – not science. Give 6 data modelers one set of requirements and you’ll get 7 solutions all distinctively different.” My response: To me that’s a huge problem. No, ‘data’ modeling is not a science, but nor should it be an art. Actually, it should be engineering. Engineered solutions have to stand up to rigorous tests. But we lack that in ‘data’ modeling. Why? Because ‘data’ modeling is divorced from its initial business context, which is operational business communication, including business rules. You need nouns and verbs for that, and those nouns and verbs should stand for well-structured concepts. Give me a model of well-structured concepts that has been ‘proven’ by verbalizing business rules and other formal business communications and I guarantee I can come up with the best data model. I’m talking of course about concept models (sometimes called fact models).

Continue Reading 1 Comment