Nonsense poems can be a lot of fun, but they are really not a paradigm for communicating effectively in a business environment. The interesting thing about them is how they mix words that are familiar in ways that are odd and introduce terms that we think we should understand but which, upon reflection, are impossible to understand.

Yet this is precisely the situation that many people who are not familiar with data models find themselves in when data modelers seek to explain what they do. Perhaps as a reaction to this, data modelers tend to avoid explaining themselves or complain that other people simply "do not get it." However, in the end, we data modelers do need to explain what we do to other people, and it must be intelligible. We not only need to contribute value but also demonstrate that we add value to the enterprises we serve. And in trying to show our value, we cannot afford to have our colleagues think that we are talking nonsense to them.

The Diagrams

Data modelers are rightly enthusiastic about what they do. Yet data models are not intuitive to someone who has not had them explained carefully (and repetitiously). A business user and I once attended a course in which a data model figured prominently. After two weeks of the course, he confided in me that he still did not understand which way data flowed in the model. He had not grasped the idea of logical priority, which is fundamental to a data model. Instead, he had fallen back on the more familiar idea of temporal priority, which we see in data flow diagrams and other models.

To say that technical artifacts like data models should not be presented to users is to escape responsibility. I have noticed that other technical artifacts, such as swim lane diagrams, use cases and RACI matrices, are easily assimilated by users. Thus, some visual representations are more successful with the business community than logical data models.

What Data Model?

Part of the problem is the data model itself. Data modelers traditionally tend to focus on logical data models. These can be very detailed, and the visual representation can therefore be overwhelming and not effective at communicating information to the business. Yet, the temptation to print out a huge data model on a plotter and hang it on the wall is irresistible. Unfortunately, the usefulness of such diagrams declines when the number of relationships increases so the lines pass under entities and cross over each other in untraceable tangles. Trying to understand a visual representation of a complex data model from a diagram on paper is impossible for anyone, let alone business users.

However, business users can grasp less complex visual representations. Subject area models are one example. These are simple but quite important. Subject areas are a taxonomy of an enterprise that show major areas of interest from a data point of view. They are also useful for grouping applications and business functions. From a data modeling perspective, subject areas are important because they represent major parts within which there is constancy for terms and concepts that can vary across an enterprise. For instance, the concept of "customer" may include prospects in the marketing subject area, but for the accounting subject area, it only represents people who have paid or owe money. Because a typical enterprise only has 15 or fewer subject areas, a diagram will not be overwhelming to business users.

The next level of detail is the conceptual data model. This is often overlooked in the rush to create logical data models. It shows major business concepts with important relationships between them and is closely associated with the production of a glossary of business terms. Unfortunately, many data modelers think it is a logical data model without full attribution. This is a mistake. A good conceptual model is important for really understanding the business. It can uncover significant issues that have gone unrecognized in the way the business manages its data. Because conceptual models have relatively few concepts (their equivalent of entities), contain only things that are described in real business terms (e.g., they are not "party" models) and do not include many attributes in the concepts, the diagrams are something that business users can understand and think about. Indeed, conceptual models are so useful that other disciplines produce them, albeit under different names, such as domain models.

Data modelers can always discuss issues of individual entities, attributes and relationships without forcing an entire logical data model on business users. Such models are simply too complex to be used to discuss entire data landscapes. Subject area models and conceptual data models are much better candidates for engaging business users in broad discussions about data.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access