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.
Malcolm Chisholm, Ph.D. has over 25 years of experience in enterprise information management and data management and has worked in a wide range of sectors. He specializes in setting up and developing enterprise information management units, master data management, and business rules. His experience includes the financial, manufacturing, government, and pharmaceutical industries. He is the author of How to Build a Business Rules Engine and Managing Reference Data in Enterprise Databases and Definition in Information Management. He writes numerous articles and is a frequent presenter on these topics at industry events. Chisholm runs the websites http://www.bizrulesengine.com, http://www.refdataportal.com and http://www.data-definition.com. Chisholm is the winner of the 2011 DAMA International Achievement Award.
Be the first to comment on this post using the section below.