In my last article I provided an overview to the ten steps for completing the High-Level Data Model (HDM) (see http://www.tdan.com/view-featured-columns/14409), 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):
-
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.
-
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.
-
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.
-
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.
