I was with a client for lunch one day and we asked the server "What do you have on tap?"  She was gone quite a long time, but came back and said "Beer."  It turned out she was right.  But her answer was not that helpful. One of the odd parts of every new project I have to deal with is getting everyone to understand that the question "Can you help us with a data model" results in me asking. "What do you mean by data model?" That's right, I have to ask team members what a data...

In my last post, I suggested that the conventional “facet” approach to designing master data models (in which each master domain is modeled, designed, and implemented in isolation from the others in the enterprise) creates gaps in the ability to effectively build applications that facilitate successful execution of end-to-end business processes. For example, the perception (and consequently the definition) of the role of a “customer” changes between the marketing, sales, finance, fulfillment, an...

In my previous post, we examined some of the challenges associated with developing data models for master data entities managed within an MDM environment, and I implied that achieving the holy grail of MDM, namely the (elusive, if not purely mythical) “golden record” would first require a practice for business-oriented data conceptual and logical data modeling. We tend to have a “dimensional attitude” about master data, focusing on “customer master” or “supplier master” or “product master” as i...

I had a recent email exchange in which a customer was looking for guidance in developing data models for master data entities used across multiple business functions and domains. One of the motivating factors was the desire for evolving a “golden record” (a term that makes me bristle each time I hear it, by the way) for each master entity type – a golden customer record, a golden product record, etc. I expressed my concern about two things: attempting to create a model intended to represent a s...