The Data Modeling Addict – October 2011

Excerpt from Data Modeling for the Business: A Handbook for Aligning the Business with IT using High-Level Data Models 

by Steve Hoberman, Chris Bradley and Donna Burbank

This is the fourth in a series of articles covering the ten steps for completing the High-Level Data Model (HDM), which is also known as a subject area model or conceptual data model. In our article series so far, we covered an overview of the HDM and two of the ten steps to building one: Identify Model Purpose and Identify Model Stakeholders. In this article we will discuss the third step, Inventory Available Resources. Here are all ten steps as a reference (the step in bold is the focus on this article):

  1. Identify model purpose.

  2. Identify model stakeholders.

  3. Inventory available resources.
  4. Determine type of model.

  5. Select approach.

  6. Complete an audience-view HDM.

  7. Incorporate enterprise terminology.

  8. Signoff.

  9. Market.

  10. Maintain.

Now that you have identified why you are building the model and the superset of individuals who will be involved in building and using it, we need to identify the actual resources we will be using to build the HDM. The two types of resources are: people and documentation.

People include representatives from both business and IT. Business people may be management and/or knowledge users. IT resources can span the entire IT spectrum, from analysts through developers, from program sponsors to team leads. From the people side, this step can be as simple as assigning actual people to the builder roles in Step 2. For example, if we are building a HDM of the manufacturing section of our business, Bob, the business analyst who spent 20 years of his career working in the plant, would be an excellent resource to assign as a builder.

A word of advice about people involvement in building the HDM – It’s ok to have as many people as possible involved in building (or at least validating) the HDM. This does not mean “analysis paralysis” sessions with everyone in one room debating what a Customer means, but instead productive smaller group sessions to help build the model often followed by a large session to culminate the completion of the HDM in a model walkthrough with all participants. This final presentation of the model should lead to little or no surprises as the participants in the room have all been involved in some way building or validating the model. If there is anyone you think may give you resistance on the model, make sure to make him/her an author of the model – it’s hard to argue the model is wrong when your name is on the model!

Documentation includes systems documentation or requirements documentation. Systems documentation can take the form of standard vendor documentation for a packaged piece of software (e.g. SAP/R3 standard documentation or the Customer Relationship Management (CRM) software user guide), or documentation written to support a legacy application. Requirements documentation span business, functional and technical requirements and can be an essential input to building the HDM.

Using systems documentation often leads to building the HDM using a bottom-up approach. That is, starting with something existing and very detailed such as a database specification or interface layout, and then rolling up this very detailed information into concepts on our HDM. I worked with a team once to build an HDM for a university, and systems documentation was our primary source of input. We might have come across the term “STUDENT” somewhere in twenty different database table names for example, and therefore determined that STUDENT is a concept that should exist on our HDM.

Likewise, using requirements documentation often leads to building the HDM using a top-down approach. That is, starting with what the stakeholders want and letting this drive the concepts on an HDM. A requirements document might say for example, “We need to know the salesperson who receives commission on an order.” We, with the help of the stakeholders, can then extract concepts such as “SALESPERSON”, “COMMISSION”, and “ORDER” from statements such as this.

 In the next column I will go into detail on Step 4, Determine Type of Model.

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