Click here to learn more about Donna Burbank.

Conceptual data models are a tool that I use frequently in my consulting practice, and I’ve found them invaluable as a way to communicate technical information concepts to a business audience. But, too often, the term “conceptual data model” comes with some negative baggage. Perhaps it is the term “conceptual” which conjures up ideas of lofty, theoretical notions constructed in an ivory tower. Or perhaps it is past negative experiences with data model exercises that were too abstract or too technical to be relevant to business stakeholders. This misconception can be frustrating since, when a conceptual data model is built correctly, it has a direct relationship with business initiatives and has concrete, “physical” business terms that a layperson can understand:  Customer, Product, Invoice, Location, etc. Hardly abstract, lofty concepts—on the contrary, they are the very foundation on which the business runs.

How, then, can we dispel the notion that the conceptual data model is an abstract, academic exercise? One way is to literally get the business stakeholders physically involved. Anyone who has ever worked with me and/or seen me present quickly realizes that I’m intrinsically unable to sit still. And I’m not alone. Studies have shown that both children and adults learn and retain information better when they are physically active. And we’ve all been involved in too many sedentary meetings that drain both the mind and the soul. Instead, try a more active and interactive method such as placing data concepts (or entities) on Post-It^® notes on the wall or whiteboard. Have the team write business terms on the notes and build an interactive “data model” on the wall. Importantly, these terms can be modified, moved, or even torn up as discussions take place. I’ve found that stakeholders are more engaged mentally when they are engaged physically. And there is something to the transient and malleable nature of a Post-It note that invites discussion and innovation. Their very nature suggest that they are open to discussion and modification, which is exactly the goal of a workshop.

Another aspect of making a conceptual data model “physical” is to use the physical, concrete terms used by the business. Ask leading questions and encourage input and, if necessary, disagreement. For example, “We’re calling this term a CUSTOMER, does anyone use a different term?” Perhaps other terms are offered such as CLIENT or PARTNER. Rather than rushing to standardize on a single term, investigate why there are differences. Is there a difference between a CLIENT and a CUSTOMER? Are these two terms for the same thing, or are there core differences in meaning? Perhaps, for example, a PARTNER is a wholesale “customer” and a CUSTOMER is an individual who shops at retail store. These are key differences to flesh out in the conceptual model.

It can be tempting to resolve differences in terminology by coming up with a more generic, abstract term. For example, perhaps we could use the term CONTRACT ENTITY to encompass all variations of customer because they all have some sort of contract with us? While that makes the model simpler to create, it obfuscates the meaning to a business users. When done correctly, the data model should describe the business so that a layperson can understand it with little or no modeling expertise. With a combination of aptly-named entities/concepts and clearly labeled relationship lines, the conceptual data model should read like a sentence. For example, “A customer may sign a contract with one or more salespersons.” You may even want to replace the standard “box-and-line” diagrams with graphical representations of the entities (e.g. a picture of a “customer”, a building to represent an “asset”), which further helps to clarify meaning and make the model “real” and “physical”.

The purpose of a conceptual data model is communication, and a variety of formats can be used to communicate—from pictures to spreadsheets to websites, depending on your goals and audience. A data model is a description of a business, and the goal of the conceptual data model is to elicit the information necessary from the business stakeholders to accurately represent the data assets of the organization. This is very different from the goal of a physical data model whose goal is to create database structures and the technical architecture needed to store information. With a business-centric conceptual data model, you should be flexible and creative in both the formatting and presentation of the model as well as the ways of interacting with stakeholders in order to capture the core business information required. The more business stakeholders can relate to the model as a representation of their physical world, the more successful you’ll be.

Often the perception is that the physical data model is the “practical” model. It is the concrete, architectural artifact that gets “real” work done. While I’m a huge proponent of using a physical data model, I would argue that a conceptual data model is equally practical, concrete, and real. The difference is the focus, which is on the business rather than the technology and the audience, which is businesspeople rather than DBAs. A conceptual data model can be used as a core, guiding reference for the business concepts and rules that help drive successful implementations for a variety of data-centric projects from MDM, to data integration, to data governance.

So get physical with your conceptual data modeling. Engage business users in an active and interactive way. Focus on the core, physical business concepts that drive your data architecture. And don’t be afraid to be creative in the presentation of the model, from using pictures to using spreadsheets in order to get your point across. In leveraging these techniques, you’re likely to find that the conceptual data model becomes a critical part of many of your data-centric projects, and a core component of your overall data architecture. Happy modeling!