I read this article with a mixture of amusement and dismay, amusement in the sense that these were the kinds of issues we addressed in the late 90s - early 00s and dismay that the author seems to be ignorant of the design patterns that exist is this area.
Now the author might be satisfied with this definition, but to my mind any definition of Master Data Management would include reference to the following:
And so on.
The author goes on to rightly identify one of the major challenges facing any large organisation in the past - the inability to identify it’s relationship with other business entities. It took a while but eventually most companies realised the flaw in trying to model a relationship as if it was in fact the business entity. This point seems to be completely lost on the author, who having identified the issue then goes on to compound the problem by spending the rest of the article centring everything around the customer! Thus the client ends up with a better version of the past rather than a solution for the future.
Had the author concentrated on modelling customer as a relationship between legal entities (a natural person or some form of incorporated body) then it would indeed make it easier for the client to identify the entity that was a prospect (relationship) who became a customer (relationship), the customer who is also a vendor (yet another relationship) and so on.
a. articles found on the Internet (and sometimes elsewhere) are not always written by journalists.
b. journalists (just like politics) talk with “scientific” accents the evening about something they do not know / does not have a single idea in that morning.
Are today youngsters less knowledgeable than the same age population twenty years ago ?
Yesterday, a man that is 105 y/o made a record on bicycle (# of kms runs during an hour). What journalists do not tell is how tall and weight this guy is He is less than 1.60m tall and less than 50 Kg (I forgot, on his previous record three years ago, I think, these were the tall/weight they gave - around these values).
If he was 1.75m / 75Kg, the record will not be tried. The heart (as a pump) have far more work to do to send blood everywhere from head to feet. This is one reason of his record (no cigarette, no wine, no , sport all his life also helped).
Thanks for reading my article in the last XDev publication! First off let me say that I appreciate any and all feedback from my readers.
You are of course absolutely right that MDM is more than what I presented in the article. There are literally whole books written by much smarter folks than myself on this topic.
The struggle I faced in writing the article was how much of this huge topic to cover in about 2,000 words. I picked an approach that I thought would help give most folks an inkling of what MDM is. To say that I left out huge parts is a bit of an understatement. I also chose to keep the relationships as simple as possible in order to communicate the concepts and ideas. As for modeling person / organization I prefer the party role model as articulated by Len Silverston and David Hay (no their models are not identical, but most of the main concepts exist in each).
As for the design patterns comment (in the context of MDM) you are correct that there are some others, a few certainly better than the ones I mentioned. Sometimes because of the vendor that you have selected for your MDM implementation (for whatever business / technical requirements) you are forced into a particular design approach. The patterns I articulated here are based on IBMs MDM product(s). So are they the latest and greatest design patterns? No. But neither are they the very worse (at least I don’t think so). I have also used / implemented Informatica’s MDM product and their design approach is certainly different. Not bad, just different.
You obviously have a great deal of experience in this area. I would very much like to hear your opinion on this topic!
What design patterns / product do you prefer?
This is a topic that I really do enjoy discussing and have a bit of experience implementing (two customer and two product MDMs). I was thinking about further developing the topic in other columns. Do you think that would be helpful? Are there areas that you feel like should be emphasized more than others?
As for the editing faux pas I try to be diligent about that sort of thing, but inevitably I miss something and want to bang my head against the wall for such obvious mistakes. However that sentence is more mangled than what I usually manage to let through. I will go look at my original copy tonight and see if indeed I did slaughter it that badly.
@Emile Schwarz ~ I can honestly say that I have absolutely zero journalistic training, but certainly a lot of data modeling and architecture training. And I am always looking to learn more in both these fields.
I just checked my original copy that I sent in and it appears to be in good shape. I asked Marc to look into it. I suspect something just got mangled in translation. Not anyone’s fault, just happens sometimes.