The Data Modeling Addict July 2013

This is an excerpt from Data Modeling for the Business: A Handbook for Aligning the Business with IT using High-Level Data Models by Steve Hoberman, Donna Burbank, and Chris Bradley (ISBN: 9780977140077)

This is the eleventh 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 nine of the ten steps to building one: Identify Model Purpose, Identify Model Stakeholders, Inventory Available Resources, Determine Type of Model, Select Approach, Complete an audience-view HDM, Incorporate enterprise terminology, Signoff, and Market. In this article we will discuss the tenth step, Maintain. 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.

Remember that even after the model is complete, there is still a maintenance task that we must stay on top of. The HDM will not change often, but it will change. We need to have formal processes for keeping the model up-to-date and aligned with the other model levels. We also want to make sure that the HDM is actively used by other groups and processes in the organization and doesn’t become a passive artifact.

What works well is to have two additional steps in any software methodology:

  1. Borrowing from a HDM, and
  2. Contributing back to the HDM.

The first step takes place after the HDM is complete. For example, before starting a logical data model, one will need to reference the HDM and most likely use the HDM as a starting point for the logical. The second step in the methodology requires taking all of the learnings that came out of the project, and making sure any new concepts make their way back into the HDM. For example, during the logical data modeling stage the modeler learns that the many-to-many relationship between Student and Course contains the Registration concept. Therefore, Registration might become a new concept on the HDM. The presentation medium of a spreadsheet is a common way of capturing the mapping between a HDM and its related, more detailed logical and physical levels. Most modeling tools support a capability that captures the mapping and allows export into a spreadsheet format for easy viewing.

As with the other steps in building the HDM, it’s helpful to have a framework or methodology around the actions needed for the maintenance and publication of the model:

  • The Modeling Function. The primary purpose of this function is to create and maintain the data model. This is the function that data management professionals get mostly right—data modelers generally know how to get the graphical representation correct. While the picture is important as a communication tool, the richness of the model is in the underlying metadata that the function is also responsible for gathering. Managing metadata tends to be challenging, but there are robust tool sets that help with data modeling and metadata management.
  • The Architecture Function. The architecture function is responsible for data architecture integration and ensuring that the high-level data model represents the very high-level view point. The architect ensures that the HDM balances the needs of the ownership and modeling functions while still maintaining a corporate perspective.
  • The Ownership Function. The ownership function is responsible for reviewing and approving changes. The challenge with this function is ensuring that it is established successfully. Depending upon organizational maturity, the ownership function could consist of a data governance board, a stewardship community, a data ownership forum, or just a single business analyst or sponsor who needs to approve information. The name of the function is not the critical success factor. What is important is that the ownership community assumes responsibility for the planning and control of the data assets by using the high-level data model.

The Data Model Maintenance Processes

Now that we’ve defined the roles in this process, we’ll walk through the various steps of the process, which are outlined in the following table.

 Process Name       Function Responsibility      
 I  Change Model  Modeling
 II  Review Change Request  Architecture
 III  Facilitate Peer Review  Architecture
 IV  Approve Change  Ownership
 V  Implement Change  Modeling
 VI  Publish Model  Modeling

I. Change Model

The event that prompts this process is a change in the HDM. This could be a change in a business definition, a change in the name of a concept, an addition or deletion of a concept to or from the model, etc. Model revisions can be grouped into four categories:

A) Changes to the graphical model
B) Changes to the metadata
C) Changes to aesthetic layout
D) Changes in content resulting from project activity

II:  Review Change Request

The architecture function is responsible for data architecture integration and ensuring that the high-level data model represents a high enough view point. The purpose of this process step is to review the model to ensure that it represents the high-level view. If new concepts or concept enhancements have been added to the model, then the data architect will need to ensure that the data governance and data ownership functions accept these changes. Each new concept will need to be mapped to a data owner. The data modeler or business user can propose a new concept, but it is the responsibility of the data architect to identify candidate data stewards and/or a data owner to accept the ownership responsibilities of the concept.III: Facilitate Peer Review

This is often the most challenging aspect of change management, as the ‘softer’ skills of listening and facilitation are more important to success than technical skills.  The goal of this step is to achieve consensus on definitions, terminology, and rules.

IV:  Approve Change

Once agreement has been reached, the data owner or steward should have final say in whether this change is accepted.  Normally, this is a business person who can give a ‘reality check’ that this definition, terminology, or rule correctly applies to the business.

V: Implement Change

After the change has been approved, the modeling team actually implements this change in the production version of the HDM, making sure that the change is correctly checked-in through the change management system.

VI: Publish Model

The publication of the model may be one of the most important steps in this maintenance process.  If stakeholders are not aware that the change has been made, or that there are new definitions to use, they are not likely to use them, which will exacerbate the ‘silos’ of information and lack of sharing and reuse.

This column concludes the series of articles on the high level data 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