News Stay informed about the latest enterprise technology news and product updates.

'Stubborn' data modelers need sympathetic, but firm, handling

Data modeling experts offer tips on building effective models and dealing with the tendency of data modelers to get overly attached to their work.

Like the painter who falls in love with his subject, data modeling professionals tend to get emotionally attached to their work, but choosing the right data model for a given task means putting personal feelings aside, according to experts.

IT industry insiders say the data modeler's reputation for being passionate and unyielding is understandable. After all, they put a great deal of time, effort and heart into the process of conceptualizing database queries, mapping out the relationships between data sources and bringing it all to life in a colorful visual representation.

But the same passion that drives data modelers to do their best work can also lead to bickering and bruised egos when managers evaluate the finished product. Just imagine telling the painter that his work isn't good enough, or that someone else's work is better.

Other than sending flowers, data management professionals and consultants say there is little an organization can do to soothe hurt feelings when a data model fails to make the cut. There are, however, some simple steps that managers can take to ensure that they pick the best data model for the job.

The first step is to keep a cool head and avoid being swayed by the emotions of others, said Bill Harrison, a veteran data warehouse architect and data modeler with Omaha Public Power District, a public utility in Nebraska.

"[Data modelers] are pretty stubborn and think their way is the only way," he said. "But there are many ways to design a database if you follow a proven methodology."

Harrison likes to begin the decision-making process by printing out hard copies of the data models being evaluated and laying them out side-by-side on a table in his office. He then looks at them closely while running various imaginary queries through his mind. The purpose of the exercise is to get a sense for how those queries would play out in the real world.

"Typically, what you will see is that one model would be very specific and one would be very generic, and then you can make the call," Harrison explained. "I've seen generic models that are beautiful concepts and very elegant, but they're harder than hell for users to understand. You've got to keep simplicity and usability in mind and make it practical."

Harrison said some questions to consider when evaluating data models include: Is the model too complex? How long will it take to run a typical query? Will non-IT types and other business users be able to write their own queries with ease? Will it work well with the various applications and database management systems the organization runs?

Managers also need to keep the fundamental purpose of the data model in mind at all times, added Bill Inmon, an independent data warehousing consultant and the author of DW 2.0: The Architecture for the Next Generation of Data Warehousing.

While that advice may sound like a no-brainer, Inmon said organizations often make the mistake of thinking that a basic data model that works for one type of system can be easily manipulated to serve another.

"There are different data models for different purposes," Inmon said. "People get all wrapped around the axle about the data model without asking the question: What is the purpose of your data model? Is it to talk about operational systems? Is it to talk about a data warehouse? Is it about a workflow?"

Inmon compared the problem to a group of friends talking about the most beautiful women in the world.

"It's strictly subjective as to whom the most beautiful is and [with data modeling] it's the same kind of discussion. My data model is more beautiful than your data model," he said. "But once you understand that one data model serves one purpose and another data model serves a different purpose, then you can start to be objective rather than subjective."

Managers should also remember to keep the lines of communication with data modelers open throughout the process, said Len Silverston, author of The Data Model Resource Book. That means asking questions, suggesting tweaks and getting their feedback.

To illustrate the point, Silverston recalled a time when he was asked to come into a company and help evaluate several data models and one data modeler became despondent when his creation was not chosen. The data modeler's negativity ended up hurting the whole effort.

"Try to let people be right once in a while," Silverston said. "There is a lot of personal pride involved."

Dig Deeper on Database management system (DBMS) architecture, design and strategy

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.