The Data Modeling Addict – July 2012

Excerpt fromData Modeling for the Business: A Handbook for Aligning the Business with IT using High-Level Data ModelsThis is the seventh 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 five of the ten steps to building one: Identify Model Purpose, Identify Model Stakeholders, Inventory Available Resources, Determine Type of Model, and Select Approach. In this article, we will discuss the sixth step, Complete an Audience-View HDM. Here are all ten steps as a reference (the step in bold is the focus on this article):

Once we are confident about which approach we should take, we need to build the audience-view HDM. This is the first high-level model we build. Our purpose is to capture the viewpoint of the audience without complicating information capture with including how their viewpoint fits with other departments or with the organization as a whole. Our next step will reconcile the deliverable from this step with enterprise terminology. Here our purpose is just to capture their view of the world.

Top-down

If the approach taken is a top-down approach, initial information gathering in the form of studying requirements documents or interviewing business users is a good starting point. Using the top-down approach, information gathering focuses on what the business wants. The initial model can be created by standing at a whiteboard or flipchart with the users. Sometimes 30 minutes at a whiteboard with a business user can reveal more about what they want than spending hours reading requirements documents. The top-down approach also helps build a strong rapport with the business.

It is often difficult to start from scratch when using the top-down approach. It’s a daunting task to stand in front of a completely clean white board or flipchart and ask a room full of people what they need; and it’s not always easy for the room full of people to articulate what they want. In these situations, it’s a good idea to do some homework and present a starter model that can be torn apart or molded into what the business needs. You can use a model that you began yourself, a high-level industry data model or an XML messaging standard. If you are putting together a starter model for the meeting, it can be as simple as a list of concepts you know will be included, such as Customer and Product. If you are considering using an industry standard such as an industry standard data model or XML messaging standard, stay tuned, we’ll talk more about how to leverage industry standards in the next chapter.

The top-down approach relies heavily on meetings with the users, initially ignoring the existing systems. Eventually we will have to map to the existing systems, but we can do this much later in the requirements process. In the 1980s and early 1990s during the Information Engineering boom, these meetings were called Joint Application Development (JAD) sessions. The term ‘JAD’ is rarely used anymore, but the same types of meetings take place today under different names, such as ‘User Requirements Gathering Sessions’. In these meetings, people who play different roles on the project, from business users to analysts to modelers and developers, work together to document a solution.

Bottom-up

The bottom-up approach starts with the existing systems environment. We ‘reverse engineer’ existing systems, which means we take the actual database design from an existing system and work our way up to the high-level data model. We can create several data models, starting with a physical, then work our way up to a logical, and finally to a high-level data model. We then modify the high-level data model to meet the business’ new needs and ‘forward engineer’ the changes down to the logical and physical models, eventually implementing the new functionality that does what the business needs it to do.?

If we are a ‘dreamer’ with the top-down approach, then we are a ‘realist’ with the bottom-up approach. We know that eventually the business requirements have to have some relationship with existing applications so why not base the requirements upon the existing systems?

With the bottom-up approach, we perform ‘data archeology’ by examining sometimes hundreds of pages of documents and thousands of tables, and rolling them up into concepts. Data archeology means we are looking at columns in tables and trying to figure out what their purpose is in life, similar to an archeologist who is trying to piece together shards of clay to determine whether they come from a pot or a vase. For one project I worked on, I scanned over 600 pages of documentation from an ERP system and identified a handful of concepts for the HDM.

Hybrid

If the approach taken is the hybrid approach, we do a bit of both information gathering and data archeology, spending a relatively small amount of time on each and going back and forth between the two techniques until the model is complete. For example, we might spend a few days understanding a subset of the existing application environment, then meet with the business to understand their requirements, which then leads to exploring different parts of the application environment, which leads to more questions on the requirements, and so on until the model is complete.

In the next column, I will go into detail on Step 7, Incorporate enterprise terminology.