Consolidation is not the same thing as integration. What does it really take to integrate business practices? Let me illustrate with a thought experiment.
Imagine that the U.S., Canada, Cuba, Jamaica, and Japan were completely closed societies. However, to invigorate their sports, each allows one visitor for one day each century to bring a new game idea.
For the 1800s, baseball is chosen. Abner Doubleday arrives in each country, and talks about bases, runs, strikes, balls, innings, and all the other things of baseball. At the end of the day he leaves. Nobody knows what happens until the next visit, a hundred years later.
As it turns out, each country has embraced the game enthusiastically, and each now has a century of competitive results.
So taken are the countries with the game, they express a desire to merge their results, and to begin an international league. A commission is chartered for that purpose and hires business architects.
The initial results are promising. Each country uses the same nouns (i.e., bases, runs, strikes, batters, etc.), and many of the same verbs (e.g., “run is scored in inning”). A data model emerges that meets general approval.
Then the trouble begins. Not surprisingly, substantial differences have arisen over a hundred years in how each country plays the game.
In Japan, a batter loses so much face after one strike (not a foul ball) he is immediately retired.
In Canada (being a tolerant country), an unlimited number of strikes per at-bat is permitted but, to compensate, only two outs per inning.
In Cuba (being a socialist country), strikes are charged to the pitcher, rather than to the batter.
In Jamaica (suffering from earlier British influence), only two bases are used, the ball is bowled, ‘pitch’ refers to the playing field, and games may continue for two days.
Can the results be merged? Yes and no. Because they are based on the same words, they can be consolidated (lumped together). However, because each country plays the game differently, they cannot be integrated (compiled meaningfully).
What does it take to achieve true integration of business practices? Without common standards for how the game is played, integration is impossible. To play ball you need business rules and a shared rulebook.
John Zachman says you can (and probably should) develop each of the following three kinds of artifacts to “excruciating level of detail”.
1. For the business management’s perspective (row 2), a conceptual model (roughly CIM in OMG terms).
2. For the architect’s perspective (row 3), a business logic design (roughly PIM in OMG terms).
3. For the engineer’s perspective (row 4), a class-of-platform design (roughly PSM in OMG terms).
Because each is a different kind of model, there is a transform from one to the next. One implication is that it is possible to make a clear distinction between analysis (CIM) and design (PIM). Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That’s wrong.
A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It’s about communication.
A logical data model is about how you organize what you think you know about the world so it can be recorded and logically manipulated in a systematic way.
I started my career in data. It took me as much as 15 years of intense work on business rule statements (1990-2005) to fully appreciate the difference. But now I am very clear that concept models do need to be developed to excruciating level of detail in order to disambiguate the intended business communication. Most businesses don’t do that today. They jump in at data design (conceptual, logical or even physical). And they unknowingly pay a big price for it. By the way, a good concept model can be readily transformed into a first-cut logical data model – just as Zachman says.~~~~~~~~~~~~~~~www.BRSolutions.com
OMG released version 1.3 of SBVR (Semantics of Business Vocabulary and Business Rules) last month – comprehensively reorganized for approachability, but not changed. Some thoughts …
Ever hear the conversation that three baseball umpires once had? If you don’t live in a baseball country, it’s an archetypical story, so you’ve probably heard some variant. By the way, in American English a ‘pitch’ is a throw of the ball for the batter to try to hit, not the field of play. Meanings matter!
The first umpire says, “Some pitches are balls and some are strikes. I call them as they are.”
The second umpire says, “Some pitches are balls and some are strikes. I call them as I see them.”
The third umpire says, “Some pitches are balls and some are strikes. But they aren’t nothing till I call them.”
Most modeling techniques primarily focus on modeling the real world as it ‘really is’. They essentially take a first-umpire point of view or maybe second-umpire. I come from that tradition too. My 1987 book Entity Modeling was about doing that … modeling the real world as it ‘really is’. Pretty much all professionals with some IT background come from that world.
Working with business people and business rules for the last 25 years, however, has taught me that business is really more of a third-umpire world. Think of laws, regulations, statutes, contracts, agreements, terms & conditions, policies, deals, bids, deeds of sale, warranties, prospectuses, citations, complaints, receipts, notices … and business policies.
Even businesses that deal with tangible stuff (e.g., railroads, electrical transmission, infectious diseases, etc.) live in a third-umpire world. And many of the most automated organizations around have no tangible product at all (e.g., finance, insurance, government, etc.). They really exist only in a world of words (between people).
It’s humbling to realize that the way the business world ‘really is’ is more directly the product of words exchanged by the players in a conversation game than anything IT professionals can model directly. But why would it be otherwise? Do IT professionals really know better than business owners, business managers, lawyers, engineers, subject matter experts, etc.? Really?!
SBVR, in contrast to almost all other standards, doesn’t try to model the way the real world ‘really is’. Instead, its focus is on modeling what is said about the way the world really is. It’s fundamentally a third-umpire standard. You simply have to understand what the words mean – and that’s a human-communication issue.
Yes, the SBVR world view is a game changer. It also happens to align closer with some of the most exciting new work in computerization today including cognitive computing and machine learning.
I stand accused by peers in the standardization community of wanting to go beyond the ‘capture, exchange and production of information’. Sure, I can live with that.
When you show business people class diagrams or data models, you’re not really talking business. Class diagrams and data models are design artifacts that inevitably focus on how knowledge about real-world things is to be represented (and manipulated) as data in machines. If we want business people to talk business to us, we must talk business back. That means talking about their words, concepts and meanings. To do that you need to develop business vocabulary in a structured way – i.e., develop a concept model.Practitioners are slowly starting to ‘get’ this. Examples:
IIBA’s recently released Business Analysis Body of Knowledge (BABOK) version 3 devotes a new section to concept models.
A solid standard exists for concept models – OMG’s Semantics of Business Vocabulary and Business Rules (SBVR). Version 1.3 of the standard, comprehensively reorganized – but not changed – is due out this week.
I was reading some discussion about data models the other day and came across the following:
“The relationships between entities define the rules about which entities relate to others, as well as the number of minimum and maximum occurrences on each side of the relationship.”
Rules is definitely the wrong choice of word here. The misconception that relationships per se in data models represent (business) rules goes all the way back to the 1980s. It’s simply wrong. Instead I would say:
The relationships between entities provide structure for the data model, specifically indicating which entities relate to which and how. Specifications for a relationship typically indicate the number of minimum and maximum occurrences allowed on each side of that relationship – i.e., their cardinalities.
Of the three typical cardinality values – zero, one and many – only one removes any degree of freedom, and thus could be said to represent a rule. In any case, cardinality per se is a specification device; the business rule is in the meaning – for example:
A customer may be related to at most only one sales area.
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
Richard Welke, Professor and Director at Georgia State University, commented:
Any process improvement or change process is a metaprocess of the process it’s targeted at. And, of course, it in turn can have a metaprocess (the process for deciding when and how to change the process improvement, or more generally BPM process). Hence it is a meta-meta-process relative to the specific organization process or “routine” being examined/managed.
My reply: Yes, which leads to the questions of …
Meta-meta-data. A similar argument can be made for “data”. Any data that describes other data is metadata. Metadata, in turn, can have metadata (the data that describes metadata, or more generally a repository model). Hence it is meta-meta-data relative to specific business data being managed.
Meta-meta-meta? I don’t think any ‘meta-” above meta-meta-process or meta-meta-data would be meaningful (add value). I could be wrong I suppose.
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*
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 ResponseI’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?!
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!
“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
“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.”