The business, the model and the data

Recently my team was tasked with creating a Conceptual Data Model. As I had never done this before, I googled around to see what resources are available. I found a few things, but didn’t find a huge number of examples, so I thought that I’d share my experience for the next person who embarks on this journey.

What is a Conceptual Data Model?

A Conceptual Data Model a business-centric representation of an information domain or area. It shows all of the data concepts that exist within an organisation’s framework, along with their definitions and relationships to one another. We’ve all seen conceptual models, which show the design of a system or product from a very high-level. These are used (mainly) for the purpose of communicating the general idea and concepts that make up whatever it is that you are describing. A Conceptual Data Model is similar, in that it shows the structure of a set of data from a high-level.

The three levels of data modelling include Conceptual, Logical and Physical. The conceptual data model is at the highest level of abstraction in the data modelling world, while the physical is the lowest. The physical data model will show the reality of what is in a database, with all of the technical detail. A logical data model will show the tables and the attributes. The conceptual data model will show just the business concepts that this particular set of data represents.

Here’s the big question: why?

There was some push-back against the pursuit of developing a conceptual data model. There were many arguments against it, but they all revolved around the universal question "what’s the point" (A.K.A. what’s in it for me)? 

It is a good question. Working at this highest level of abstraction can seem academic, though it has much practical value. A conceptual model will provide:

• A list of the fundamental concepts that are used in an organisation
• Consensus on what terms are used to refer to those concepts
• Consensus on the definitions of the concepts
• Clear understanding of the relationships between these concepts, including their cardinality
• The ability to communicate the structure of the current information domain to a non-technical audience

With the clear understanding of the business concepts, you can understand what data points you need to represent them.

Conceptual models vs conceptual data models

The main difference between a conceptual model and a conceptual data model becomes apparent in its creation.

In a conceptual model, you start with the object that you are describing; whether it is a car, government, piece of software, etc., diagram out the concepts, functions and relationships and then present it to your audience. With a Conceptual Data Model, you start with the audience: the business. It’s their data that you are working with, it’s their business that you are going to describe with the data, so we need their help to understand what they do. 

Why would we want to waste their time? Can’t we just look at the industry and get a common conceptual data model from the internet? Though this seems like a quick-win, I would advise against it. Two businesses within the same industry work to differentiate from each other so that they can provide a unique selling point. The differentiation can be their purpose, products, pricing or something else. Furthermore, each enterprise has individual goals to achieve their vision. The combination of these factors create a distinct culture which will be represented in the use of terms, as well as the understanding of concepts within the business. The Conceptual Data Model needs to reflect that unique business in order that you can effectively provide the data in a structure that will match their requirements. 

OK, so how?

How do we develop a conceptual data model? First we get the business terms that the company uses to describe the different parts of the business, e.g. “Customer”, “Product”, “Employee”. Already we’ve run into questions: Are these the words that the company use? Does the company that you are modelling for call their customers “Customers”, “Clients” or something else? What word do they use for whoever is consuming their product or service? Define that word rather than using the dictionary/industry-perfect word for that particular concept. The purpose is to get the business concepts on paper in the language and thinking of the business.

Time to define

Next: create a definition for each of the business terms identified in the previous step. When working at this high-level of abstraction, it’s important to be very general. Once again, it’s what the business thinks that matters – for example, if they define a customer as anyone who is on their Customer Relationship Management system, regardless of whether they have used one of their services or purchased a product, that’s what you define a customer as.

However, I wouldn’t recommend pulling a lot of data stakeholders into a room and asking them “What’s a customer”. That approach is likely to result in glazed eyes, irritated stakeholders and nothing else. A better idea is to set up a group of people to work on these definitions, including a few business subject matter experts, data people and key stakeholders in whatever concepts you are working with.

Discuss

Brace yourself: attempts to define commonly used terms can lead to very robust discussions. It can get heated. This is excellent; getting all of the views and ideas of what a particular term means is one of the key objectives. The gladiatorial display of opposing viewpoints jostling for the title of “correct” may cause you to want to abandon the project, but persistence will sort out confusion within the organisation.

There may be some surprising outcomes, especially when the terms are presented to the wider business. Some of the outcomes of these discussions will show that people have slightly different nuances of what a particular term means. At times they have different words for the same concept. At other times it will emerge that different parts of the organisation have completely different interpretations of the same word. These differing viewpoints need to be addressed. Consensus on the meaning of a concept must to be reached before anyone can know what data points are needed to represent the concept.

Getting Consensus

There are many techniques to get to a consensus, such as card-sorts, providing a description without a name, put the concepts to a vote, plus many more. One I would not recommend is the “I’ve been here the longest so therefore I’m right” method, or any other method that appeals to an authority. It can cause resentment. At times a subject matter expert will be able to provide a very powerful case for one view or another, but it’s important to ensure that all viewpoints are heard and the people present are allowed to voluntarily agree rather than be told to. Language is a very sensitive subject. Human beings do not like being told how to speak and can quickly become defensive in protection of their culture, even when the culture only exists within a small team in an organisation.

Once the consensus is reached, the agreed term and definition of a concept should be entered into the Business Glossary so the wider business can be made aware.

Defining Relationships

Once the concepts have names and definitions you can define the relationships between them. This will involve an understanding of business rules and can be different for each organisation. Can a customer have more than one address? Can one product order be the result of many advertising campaigns? As always, there will be people in the business that can help with this.

Done

So the concepts, terms used to refer to them, their definitions and the relationships between them are now defined. Next step is to drop down a level and define the concepts that exist within a concept e.g. Active Customer, Inactive Customer. 

Many benefits will have been realised by now. One of the main ones is that everyone now knows what they mean when they use a term and can easily and quickly reference the definition to ensure that their assumptions are valid. 

A conceptual data model should be a living document and made available for anyone who is interacting with the information domain it represents. The discussions around the meanings of. and realationships between concepts will very likely continue, but this is good as it will lead to further clarity and consensus within the business.