Conceptual Modeling Requires Conceptual and Critical Thinking

ART03x - edited feature imageI am surprised to see a lot of people jumping straight into logical or even physical modeling and skipping conceptual modeling. Don’t they understand the value of conceptual modeling? Don’t they understand the difference between the various levels of modeling? Or do they have cognitive limitations? In this column, I will elaborate on the importance of conceptual and critical thinking in the context of conceptual modeling.

Data models are meant to represent real world concepts, their relationships and related rules. They enable us to reflect the state of the world in data that can be stored and visualized. An important part of the quality of a data model is the extent to which it can represent facts in the real world.

This implies that you can only make a good data model if you really understand the relevant part of the real world—the universe of discourse. Understanding is key. It is easily clouded if you try to simultaneously  understand concepts and their representation in data. That is why you should start with conceptual modeling first, and do logical modeling later.

A lot of people find it difficult to conceptualize and abstract or to understand concepts or abstractions made by others. They are used to working with facts. They need to get things done. You can talk with them about the facts, but they do not necessarily understand the concepts and relationships that you derive from them. Also, confronting them with a formal model, with a lot of boxes, lines and symbols that they do not understand, does not really help. If this concerns people in the user organization, then a good conceptual modeler can guide them and ask the right questions. It becomes very difficult when the modeler itself is not really able to think at a conceptual level, and starts mixing modeling. That is when others get confused.

What is making matters worse is that people in the organization may think that they understand things, but they may have distorted or created a partial view on it. That view may be sufficient for their day-to-day work, but can lead to a faulty conceptual model in the hands of a modeler that does not truly understand it. A modeler cannot accept things that someone said at face-value. In that sense, conceptual modeling can be seen as a requirements elicitation activity. For requirements elicitation, it is also not enough to ask people what they expect from the system. People often do not fully understand the problem domain, have trouble communicating what they mean, omit information that they feel is obvious, or state things that are ambiguous. Other techniques such as user observation, role playing, and prototyping are needed to get good requirements that reflect what people really want.

An additional complexity raised by Mats Alvesson and André Spicer in their book “The Stupidity Paradox” is that people tend to show stupid behavior. They do things that are simply illogical and even have catastrophic effects on the organization. So why do they do this? Because it is functional— it helps them to do the things that their colleagues expect. It is just socially acceptable. They describe various forms of stupidity. People may close down cognitively, and just accept things that are close to what they already know. They may also have motivational defects and be unwilling to think. People may also have emotional reasons, being unable to comprehend emotions of others or focus on a particular emotion. Finally, people may also have moral reasons that may sound immoral to others.

Some of this stupidity may be detected by a good data modeler that is sensitive enough to feel that something is wrong. But the only structural way of approaching this stupidity is through critical thinking. Critical thinking means that one is not just accepting things that people say, but understanding the underlying assumptions, evidence, inferences, and meaning. Practically, critical thinking requires you to ask a lot of questions. Could you be more specific? How could we verify or test that? Is this in line with what you said previously? Have you also tried to look at it from the perspective of someone else? Can you give an example? Could you be more exact? Is that relevant in this context? How does that relate to the problem?

No-one says that data modeling is easy. However, a good data model is not complex. According to Occam’s razor, all other things being equal, the simplest theory is most likely true. A good data modeler is able to make a simple model of a complicated domain. A bad data modeler will make things complex. You cannot prevent inherent complexity, but modelers that introduce incidental complexity only make things worse. It is important that a modeler understands the universe of discourse and describes it in a conceptual model before starting logical modeling. In line with the Miriam-Webster dictionary, understanding requires grasping meaning, reasonableness, technical acquaintance, character, propensities, and plausibility. Or just in short: conceptual and critical thinking.

Share

submit to reddit

About Danny Greefhorst

Danny Greefhorst, MSc., is a Principal Consultant and Director of ArchiXL in Amersfoort, The Netherlands, and acts as an architect and consultant for clients in the financial and public sector. He has extensive experience with the definition and implementation of enterprise architectures, application architectures and technical architectures. In addition, he coaches organizations in setting up and executing their architecture function. Danny is responsible for the EA portal Via Nova Architectura and is a member of the governing board of the architecture department of the Dutch Computing Association. Danny is active in the architecture community, regularly publishes on IT and architecture related topics and is co-author of the book Architecture Principles: The Cornerstones of Enterprise Architecture. He can be reached at dgreefhorst@archixl.nl.

Top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept