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
Tags: business semantics, business vocabulary, concept model, data model, functional silos, semantic silos, semantics, white collar automation
Ronald G. Ross
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.
Jacob Vos
| #
Quote: “a concept model can be used as the basis for designing a model of the data needed to support processes”.
I really would like to integrate them as tight as possible. Especially in the situations where business rules are defined on top of the concept model. I must not think about maintaining those rules both on top of the concept model and also – let’s say – in a conceptual model built in ORM.
How do you see practically such a relation (on tool level)?
Ronald G. Ross
| #
The long-term solution is platforms that can operate completely at a semantic level, and map concepts to ‘data’ automatically. That’s why I spend my time working on the SBVR standard. It’s a major shift in mindset … and certainly won’t happen overnight.