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):
-
Identify model purpose.
-
Identify model stakeholders.
-
Inventory available resources.
-
Determine type of model.
-
Select approach.
-
Complete an audience-view HDM.
-
Incorporate enterprise terminology.
-
Signoff.
-
Market.
-
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.
