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

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[1]. 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).[2] Version 1.3 of the standard, comprehensively reorganized – but not changed – is due out this week.
• Proven methodologies support concept modeling.[3]

~~~~~~~~~~~~~~~~~~~~~~~~~ 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