The Data Modeling Addict July 2013

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.

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:

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!