A man once wandered upon a construction site for a large building. He walked up to the first man he encountered and asked what he was doing. He answered "I am laying bricks for this wall". The second man he approached said he was a glassmaker making stained glass windows. "I’m a carpenter building a door frame." the third man informed him. Then he came upon an old woman, hunched over, sweeping up the floor and removing the scraps left by the other workers. He asked her what she was doing. She answered "I’m helping to build a glorious cathedral!" Which person had the best perspective? Which person took more pride in their job? Obviously, the one with her eyes on the big picture. She was helping with something she believed in that was bigger then herself.

Sometimes we, as data administrators, lose track of our role. We forget that we are part of a bigger team, not an end in ourselves. While what we provide, data models, is important they are useless alone. The most beautiful, technically perfect stained glass window would be useless if it didn’t fit into the frame the carpenter built or if the bricklayer didn’t account for the space when building the wall. If they are not used toward a bigger goal, they are a waste of time. If they do not provide a practical purpose they are, at best, fancy wallpaper.

We should especially remember this when we meet with users. The goal of a modeling session is not to show how much we know, but to reflect back how much they know. When we truly get this we will become much more affective. The user does not care that you know all the latest buzzwords. They usually do not care what cardinality, 3rd normal form, or super-types are. They shouldn’t have to care. It is our job to extract the business knowledge from the user and reflect it back to them in a data model. We need to find a way to communicate to them, not force them to understand us. Some users are more visual and quickly grasp onto data models; others need you to put the business rules and relationships in writing. A logical model can be validated using properly written business rules and relationships. It is also imperative that the business rules and relationships are written in the language of the user. While it is beneficial if they can, the user does not need to understand how to read the model.

So now the hard part. If they do not understand data modeling principals, how do we get the user to give us the information we need? First, avoid talking over their heads. It will only confuse them if we start asking what something’s cardinality is, or defend a decision by saying "because it must be in third normal form". That’s not what they want to hear. They want to know the practical benefit of what you are doing and how it will help them.

Following are some possible examples of terms or phrases we should avoid, and some possible alternatives:

We must find a way to tailor our approach to the specific users. We need to guide them using whatever terminology or methodology they are most comfortable with. During one meeting I met with users who wanted to implement a satisfaction survey system. The system involved an initial survey and periodic check-up calls. The user came to the meeting with a stack of forms, phone scripts and reports.

The user understood their forms, and the need to automate them, so I focused the discussion on the forms. I let the user work through the documents page by page. It appeared that it would be an easier transition for the user to jump from the forms to screens then it would be to jump directly into a data model. They initially did not grasp the fact that the forms contained business entities, so I focused the conversations on the screens. On one side of the white board I started a potential screen flow and on the other side I stared the preliminary data model. I would ask them questions as they went along to verify any assumptions I made.

As we moved along I filled in enough of the screens to enable me to get their data requirements. To ensure I was properly catching the information requirements I let them talk but would nudge them with questions worded in their language. If a customer is called more than once will we know that? So a customer can have more than one survey? We had our first two entities.

We then started mapping the lines on forms to the screens (which they understood better then mapping them to entities). When I thought we hit a new entity I would draw it on the logical model. I explained the new entities in relation to their screens.

When we hit repeating groups they were at first confused. They didn’t understand why I needed to create a separate table. I didn’t say, "In a 3rd normal form model all repeating groups must be normalized". I said "If we put it in a separate table then you won’t be limited to how many answers we can store to that question". They understood that, and saw the benefit.

For this group using the screen flows to bridge between the paper documents and the data model worked. For another group it might not. The important thing is to leverage what they do know. We must try to think on our feet and determine the best way to facilitate the transfer of their knowledge. During the meeting I never mentioned normalization, repeating groups or 3rd normal form but we did come up with a model that was normalized, did not contain repeating groups, and was in 3rd normal form. The users agreed that the model reflected their understanding of the data.

People, departments and companies are all different. What works once may not work again. We need to be perceptive and adaptable. Try one approach, and if it doesn’t work try something else. Remember what’s important. The user must feel like their knowledge is driving the design. You are just reflecting that knowledge back to them. Don’t let your ego get in the way. They don’t care how smart you are if your knowledge doesn’t benefit them in a practical way. Don’t build a perfect stained glass window that doesn’t fit in the cathedral.

About the Author

The author, Daniel Roth, is an Information Architect at a large insurance company. He has many years of data processing experience as an application programmer, technical support specialist, DBA, and for the last 6 years as a data analyst. Dan can be reached at rothdaniel@aol.com