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