Data Models, Date-A-Models and the missing course content

Fellow data professional, Chris Bradley, had a great story from a conference. A passer by had asked what the event was about and the answer “it is about how to data model” came across as “how to date a model”. Chris’ story telling is priceless as the dialogue had gone on for sometime until the disconnect was discovered, but if got me thinking, could we get more out of this story?

When people learn how to data model, there is a lot of focus on understanding the concepts. What are the Entities? How may they Relate to each other? Could this be a one-to-one relationship?

Not that I am speaking from personal experience, but presumably if you want to date a model, you’ld also want to be aware of what kind of relationship could be possible, what other entities are there to see things may fit and how lines are drawn.

Whether the course is on how to data model or date a model, there would have to be emphasis on how to manage what you create? Once you get the date, how do you make it worthwhile? Will there be a second chance, a third? Will there be long term value? What ongoing complexities may need to be managed? When it is about a collaborative relationship, how will you deal with unexpected questions, semantic misunderstandings, or gaps?

In Data Management, we often do a great job in defining a data model that is flexible with content and constructs we are proud of. Too often however, the modeler focuses just on the creation and not how the information is shared or stored through the model. What are the quality expectations? How would we know if, not just the model but the system it enables is meeting the need?

This to me is the key difference between a Data Modeler and a Data Architect. A great modeler understands the concepts to represent them effectively, and perhaps through different mediums (relational, dimensional, XML…). A data architect also understands who needs the information for what purposes, what are the available data sources, what are integration or quality complexities and how they could be managed over time.

It is not about having all the answers but understanding what is it that would truly matter and continuously working to achieve it.

Whether you are working on data modeling or dating a model, good luck in your endeavors.

Cheers

2 Responses to Data Models, Date-A-Models and the missing course content

  1. With respect to considering the entire lifespan of a data element, do you think that the presence of tools like Business Objects, that abstract out the underlying data storage mechanism for ‘read’ purpsoes, have any impact on your distinction between Architects and Modelers?

    • dataminstrel's avatar dataminstrel says:

      I believe what differentiates a modeler and an architect is end to end perspective more than the tool.a data architect would also look at quality of information exposed through the model across it’s lifecycle, whiled most pure modelers may be content with good structure, naming, definitions.

      That said, the more data architecture is considered unnecessary due to easy configurability of the tools, the higher the risks of missing key discoveries to the success of the solution due to staffing or planning gaps.

      Any specific trigger for the question out counter views?

Leave a reply to Paul L (@planzi) Cancel reply