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:
It should be easy to give examples for the thing defined, but there should be no counterexamples.
Each definition should communicate the essence of what a thing is, not what it does, how it’s used, or why it’s important.
The definition of a thing should focus on its unique characteristics.
Each thing you define should be distinguishable from every other thing you define using the definition alone.
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).
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.
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 does not have an innate concept/approach for “legality” in the sense of MWUD 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 ruleA 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 rulesA 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
Semantics of Business Vocabulary and Business Rules
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.
To understand the future of processes, you must dig a little deeper than many people do.
Process thinking goes back well over a 100 years, to the origin of modern iron and automobile production. The raw materials and finished goods of such manufacturing and production processes are literally spatial – 3-dimensional. What can you do to significantly improve productivity in a 3-dimensional world? The answer these days is simple: You build robots. Robotization has literally changed the world during the past 30-40 years.
Rather than manufacturing and production processes, however, the world is now increasingly focused on white-collar and digital processes. What 3-dimensional presence do the raw materials and finished goods of these processes have?
Well, exactly none. The raw materials and finished goods of these processes aren’t physical and simply have no spatial presence whatsoever (except maybe for paper artifacts). Robots (at least physical ones) aren’t an option. That fact of life makes a huge difference in how you have to think about automation for such processes.
Instead, the raw materials and finished goods of such processes are all about your operational business knowledge – your intellectual capital – and your capacity to express and apply it. That capability, in turn, depends directly on your business terminology and business language. For white-collar processes you have no choice – the world is semantic. So you must deal with the subject matter semantically.
That takes us in a very different direction than most professionals currently foresee. For one thing it takes us toward natural language and away from diagrams-for-everything. That’s a huge shift in mindset. Imagine having a business conversation with your smart phone about gaps and ambiguities in business policies and in the meanings of the vocabulary you use to talk about subject matter knowledge. Don’t think that’s possible? Have you watched your kids talking to their smart phones lately?
Sooner or later businesses will realize that operational business knowledge differentiates their product/services and enables their ever-more-automated processes to function. Capturing, managing and re-using that intellectual capital puts a premium on structured business vocabulary (concept models) and on business rules expressed in structured natural language. Those business rules are the only way you have to ensure quality from white-collar and digital processes.
Read more on this topic:
Are Processes and BPM Relevant in the Digital Economy? http://www.brsolutions.com/2015/10/19/are-processes-and-bpm-relevant-in-the-digital-economy/
Measuring Quality and Defects in the Knowledge Economy: http://www.brsolutions.com/2015/10/27/measuring-quality-and-defects-in-the-knowledge-economy/
Quality and Tolerances in the Knowledge Economy: http://www.brsolutions.com/2015/10/29/quality-and-tolerances-in-the-knowledge-economy/
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. The first two of these techniques are:
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 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. Did you know that?!
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 is no luxury. ~~~~~~~~~~~~~~~~~~~~~~~~~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 seedconcept.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.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).Concept Model vs. Data ModelA 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 ModelsNoun 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.
StrengthsA 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.
LimitationsA 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
 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.
 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.
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
“I found the course interesting and will be helpful.
I like the pragmatic reality you discuss, while a rule tool would be great, recognizing many people will use Word/Excel to capture them helps. We can’t jump from crazy to perfect in one leap!
Use of the polls is also great. Helps see how everyone else is doing (we are not alone), and helps us think about our current state.”
Trevor – Investors Group
“Instructors were very knowledgeable and could clearly explain concepts and convey importance of strategy and architecture.
It was a more comprehensive, holistic approach to the subject than other training. Emphasis on understanding the business prior to technology considerations was reassuring to business stakeholders.”
Bernard – Government of Canada
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”
Jeanine Bradley – Railinc
“You did a wonderful job!! The material was organized and valuable.”
Janell – Texas State University
“Sessions flow together well and build upon the concepts for the series which makes the learning easy and better retention.
The instructor is knowledgeable and very attentive to the audience given the range of attendees skill and knowledge of the subject at hand. I enjoy her training sessions.”
Deborah – American Family Insurance
“Your work has been one of the foundations of my success in our shared passion for data integration. It has had a huge impact on innumerable people!”