The Data Modeling Addict – January 2011

In my last article I provided an overview to the ten steps for completing the High-Level Data Model (HDM) (see, which is also known as a subject area model or conceptual data model. In each article I will explain one of these ten steps. In this article I will explain the first of these ten steps, Identify Model Purpose.

Before starting any data modeling effort, first identify why the model needs to be built. Underlying every reason for building a HDM is communication. We build data models so that we can ensure everyone has a precise understanding of terminology and business rules. Part of this step is to identify what needs to be communicated and to whom we are communicating it.

One of the fascinating outcomes of this first step is the realization that the model stakeholders see the world very differently from each other. (If they don’t see the world differently at this first step, they surely will while building the high-level data model and attempting to agree on a single definition for Customer, for example.) Therefore, they also may have differences of opinion on the purpose of the model. You will find that the same skills that get people from different departments to agree on definitions for terms like Customer are invaluable in Step 1 for gaining consensus on why the model is being built.

Good facilitation skills can never be underestimated in this first step. The skillful facilitator knows when to involve upper management and when to use ‘tough love’ techniques such as making the bold statement, “No one is leaving this room until we all agree on why we are building this model in the first place!” It is not worth investing time and money in the other nine steps without a clear, agreed-upon reason for the model. That doesn’t mean the high-level data model cannot have more than one purpose, but there should be one primary purpose for building it.

Once there’s consensus on the purpose of the data model and it is documented, we can combine this knowledge with a number of factors to determine whether a top-down, bottom-up, or hybrid approach is ideal. Matching the right factors with the right modeling approach will dramatically increase the probability of having a successful model.

Here are the most common reasons for building a HDM (remember, communication is the main reason behind each of these):

  1. Capture existing business terminology and rules. The most popular use of the HDM is to gain an understanding of an existing area of the business. We can model a department such as Sales or Accounting, a line of business such as Home Mortgages, or even the entire organization. If the model crosses broad functional areas, it can become a valuable tool for people with different backgrounds and roles to understand and communicate with each other on the same concepts, and agree or debate on issues.
  2. Capture proposed business terminology and rules. Our businesses continuously try to find ways to improve execution of the day-to-day events that keep us in business. For example, if it takes 5 hours to manufacture a widget, how can we get this down to 4 hours and 30 minutes? Therefore, after understanding existing business terminology and rules, we need to agree on a future state for this same set of terminology and rules.
  3. Capture existing application terminology and rules. In the beginning of a project, there is always a period of time where there are large gaps in understanding the existing applications. This may include functionality, terminology and reporting gaps. It may include internally-built applications as well as packaged software such as Enterprise Resource Planning (ERP) applications. It may include both operational and reporting systems.
  4. Capture proposed application terminology and rules. The HDM is a very good place to start capturing the concepts and business rules for a new application. This way terminology, rules and definitions can be agreed upon prior to detailed project analysis. It will save time, money, and unpleasant surprises further down in the software lifecycle. As with the existing application, this may include functionality, terminology, and reporting gaps. It may include both operational and reporting systems. It may include internally-built applications as well as packaged software such as enterprise resource planning applications.

 In the next column I will go into detail on Step 2, Identify model stakeholders.

Share this post

Steve Hoberman

Steve Hoberman

Steve Hoberman has trained more than 10,000 people in data modeling since 1992. Steve is known for his entertaining and interactive teaching style (watch out for flying candy!), and organizations around the globe have brought Steve in to teach his Data Modeling Master Class, which is recognized as the most comprehensive data modeling course in the industry. Steve is the author of nine books on data modeling, including the bestseller Data Modeling Made Simple. Steve is also the author of the bestseller, Blockchainopoly. One of Steve’s frequent data modeling consulting assignments is to review data models using his Data Model Scorecard® technique. He is the founder of the Design Challenges group, Conference Chair of the Data Modeling Zone conferences, director of Technics Publications, and recipient of the Data Administration Management Association (DAMA) International Professional Achievement Award. He can be reached at

scroll to 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