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.

 Step
 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

submit to reddit

About Steve Hoberman

Steve Hoberman is a world-recognized innovator and thought-leader in the field of data modeling. He has worked as a business intelligence and data management practitioner and trainer since 1990.  Steve is known for his entertaining, interactive teaching and lecture style (watch out for flying candy!) and is a popular, frequent presenter at industry conferences, both nationally and internationally. Steve is a columnist and frequent contributor to industry publications, as well as the author of Data Modeler’s Workbench and Data Modeling Made Simple. He is the founder of the Design Challenges group and inventor of the Data Model Scorecard™. Please visit his website www.stevehoberman.com to learn more about his training and consulting services, and to sign up for his Design Challenges! He can be reached at me@stevehoberman.com.

Top