Definitions of business terms with subtle IT or ‘data’ bias are an anathema to effective communication with business partners. Good business definitions are oriented to what words mean when used by real business people talking directly about real business things.

Here are 5 basic criteria for great business definitions:

 

1. It should be easy to give examples for the thing defined, but there should be no counterexamples.
2. Each definition should communicate the essence of what a thing is, not what it does, how it’s used, or why it’s important.
3. The definition of a thing should focus on its unique characteristics.
4. Each thing you define should be distinguishable from every other thing you define using the definition alone.
5. Each definition should be concise and as short as possible without loss of meaning. A definition should be readable.

One thing may surprise you about great business definitions. The very first noun in each definition is absolutely key. These first words are the secret sauce of excellent business definitions. Read more in our new Primer (free download).

~~~~~~~~~~~~~~~~

Extracted from: How to Define Business Terms in Plain English, by Ronald G. Ross – free download, 26pp, pdf, http://www.brsolutions.com/publications/crafting-definitions-a-primer/

There’s a high premium on knowing how to craft great definitions. Every business analyst should know how. We’ve just published a new Primer on creating business definitions (see below – free download).

There are various schools of thought about how to define terms, some arising from professional terminologists and academia. But those approaches are often relatively arcane and not well-suited to everyday business practice.

So you should stick with common dictionary practices. They are perfectly adequate for your needs. By ‘dictionary’ I mean natural language dictionaries of course, not any kind of dictionary arising from IT (e.g., data dictionaries).

If you want to talk about how data is retained or exchanged, do a data model. A good data model has definitions too of course, but they subtly relate to fields and data types, not directly to things in the real world. That bias throws them off-center for business communication. This implicit mindset is often hard for those with a data or IT background to unlearn. But not impossible! If you fall into this category, our Primer will teach you how.

Our new Primer is organized as a set of guidelines, each with one or more examples. Each guideline can be understood on its own, but the overall set is mutually supportive and comprehensively interlocking. Master this set of guidelines and your definitions are guaranteed world-class.

~~~~~~~~~~~~~~~~

Extracted from: How to Define Business Terms in Plain English, by Ronald G. Ross – free download, 26pp, pdf, http://www.brsolutions.com/publications/crafting-definitions-a-primer/

How does legality work with business rules? To say that differently how should an intelligent tool work so as to help you establish the business regimen you want to follow where legality is involved? Consider the example of Same-Sex Marriage. Let’s suppose you want to make it illegal. SBVR[1] does not have an innate concept/approach for “legality” in the sense of MWUD[2] 1: attachment to or observance of law. So if you wanted “is legal” in the most direct sense, you must define a unary verb concept for the concept Same-Sex Marriage. In a looser sense, if you are in an organization (business) with the standing to define business rules, you could do several things, as follows. (I’ll make up a bit of vocabulary here.) 1. Specify a behavioral rule A behavioral rule is one that can be potentially violated by people or organizations. The relevant rule might be expressed as follows:

The people united in a marriage must not be of the same gender.

Then you would decide how strictly you want to enforce the rule. Options range from strictly enforced to guideline. The rule would be active when a relevant state of affairs arose (i.e., specific people get married). 2. Define several definitional rules A definitional rule is one that cannot be violated; it exists to ensure the consistency of the concept system you chose to follow. Relevant definitional rules might be expressed as follows:

• The people united in a marriage are not to be of the same gender.
• The people united in a same-sex marriage are to be of the same gender.

See the conflict? Your friendly intelligent tool would (immediately) disallow one or the other specification. The rules are clearly in conflict; the logical conflict would simply not be allowed to stand. 3. Define the relevant definitions

• Marriage: the uniting of people of different genders in wedlock
• Same-Sex Marriage:  the uniting of people of the same gender in wedlock

Again, your friendly intelligent tool would (immediately) disallow one or the other specifications. The definitions are clearly in conflict; the logical conflict would simply not be allowed to stand. Actually, under the covers, approaches 2 and 3 work exactly the same way In SBVR. SBVR recognized that some people prefer to do things via rules, some with definitions, and if truth be told, most times you will do some of both. ~~~~~~~~~ www.BRSolutions.com    

Guest Post by Markus Schacher We should first agree on the semantics of underlying concepts and only then start to think about the best terms for those concepts. One particular technique I often apply in such cases is the following: 1.    Name controversial concepts with proxy names such as “Greg”, “Mike” or “John” (or whatever name you prefer) to get potentially misleading names and their implicit connotations out of the way of progress. 2.    Draw a concept diagram showing those concepts as well as important semantic relationships among them. 3.    Formulate intensional definitions for each concept – still using the proxy names. Ensure that those definitions are consistent with the relationships shown on the concept diagram. 4.    Identify one or more communities that “baptize” those concepts by giving them better names. If synonyms and/or homonyms appear among those communities, that’s just how the world is; we simply have to live with it. This is why SBVR formally supports semantic communities as well as speech communities. ~~~~~~~~~~~~~  www.BRSolutions.com

Professionals should always focus on business solutions first, then and only then on designing systems. Not just lip service, I mean applying the power techniques of true business architecture[1]. The first two of these techniques are:

• Structured business strategy. See: http://www.brsolutions.com/2015/05/31/basics-for-business-architecture-1-structured-business-strategy/

 

• Business processes and business rules. See: http://www.brsolutions.com/2015/06/02/basics-for-business-architecture-2-business-processes-business-rules/

The third technique is structured business vocabulary – a concept model. The value-add companies produce today is based on rich operational business knowledge. No business solution can prove truly effective if business people (and the tools they use) are unable to communicate about that knowledge clearly. Who profits from operating in a Tower of Babel? A concept model[2] is about identifying the correct choice of terms to use in business communications (including statements of business rules) especially where subtle distinctions need to be made. A concept model starts with a glossary of business terms and definitions. It puts a premium on high-quality, design-independent definitions, free of data or implementation biases. It also gives structure to business vocabulary. Essential for any true architecture is stability over time. Are the core concepts of an operational business stable over time? Yes.[3] Did you know that?! ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

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

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 4^th ed, by Ronald G. Ross, 2013, Part 2. www.BRSolutions.com

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

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