In physics, antimatter has the same mass, but opposite charge, of matter. Collisions between matter and antimatter lead to the annihilation of both, the end result of which is a release of energy available to do work.
In this blog series, I will use antimatter as a metaphor for a factor colliding with a master data management (MDM) matter that not only annihilates it, but also prevents a release of energy needed to make MDM work.
I call these factors the antimatters of MDM.
When the customer role crashes the MDM party
When most people think of MDM, they think of customer MDM. So, when a new MDM program or its pilot project is started, most organizations think choosing your first master data domain is an easy choice: customer.
There are two issues with this approach. The first is that customer is not actually a domain, or an entity, to be more precise. Customer is one of the roles within the Party master data entity. For an excellent overview of MDM data modeling concepts, listen to this podcast with John Owens: Demystifying Master Data Management.
The second issue is that starting with the customer role is a surefire way to crash your MDM party. David Loshin has stated on several occasions that the most dangerous question in data management is What is a customer? It’s the most dangerous question because it’s the most difficult one to get a single answer to, which is ironic (and not in the Alanis Morissette sense) considering MDM is infatuated with a single version of the truth.
Starting with customer – even if you correctly state you are starting with the customer role within the Party master data entity – is perhaps the most powerful antimatter of MDM. No failed project ends well, but a disastrous failure could eliminate the matter of even attempting MDM again (or at least anything called MDM).
Planning a successful party is all about location
I like starting MDM with the Location master data entity. It’s easier to achieve consensus on the definition of a location (e.g., postal address). You can validate location with external reference standards (e.g., the USPS for US postal addresses). The business justification can be based on the cost savings of eliminating not only redundant storage of location data, but perhaps also redundant technology since many organizations purchased (sometimes without knowing it) more than one postal address validation tool and its reference data updates.
Starting with the Location master data entity not only puts MDM on the organization’s map, it also puts in place the technology infrastructure and, more important, the communication and collaboration framework that will provide the solid foundation that MDM needs to plan a successful party for the Party master data entity.
3 Comments
Great post as always Jim.
I agree with you that starting MDM with customer is a recipe for confusion and chaos, if not outright disaster as you've mentioned. Starting with Location can be, and usually is, much more rewarding and fruitful. However, I have had occasion to wish that I hadn;t started with Location as the focus of an MDM effort. In the Environmental business (think US EPA), there are many different definitions of location. For air quality, it can be the specific lat/long of a smoke stack, as there are often more than one stack at any given physical address. A similar situation can hold true when referring to water resources -- there are many physical addresses (e.g. postal addresses) around a lake or pond.
Taken separately, there really wouldn't be an issue. However, in environmental protection, these layers of air quality, water quality and monitoring hazardous waste (which has it's own "location" issues) are pulled together to form an overall picture. To pull these layers together is an inherent MDM effort so as to ensure that everyone is speaking in the same terms.
In short, I have yet to see a particular domain or subject area in MDM that doesn't present challenges. It's one of the reasons (in my opinion) that it takes a certain skill set to be able to work in this niche! :-)
Again, thanks for a great posting!
Thanks for your comment, Karen.
Yes, a postal address is only one example of a location, and in certain industries, or business cases within an industry, location can easily become quite complex.
Much of that complexity, however, often comes from the relationships between Locations and Parties or Locations and Assets.
Starting with a unique representation (i.e., a single version of the truth) for each location, whether it's a postal address, lat/long, GPS, or some other geographic coordinate system, make it easier to manage those relationships.
In your example, although there can be more than one stack at a given postal address, there is no need to redundantly store the postal address multiple times. The same goes for the more detailed location of each stack, which would have to use a geographic coordinate system to pinpoint exactly where each stack is, but there is still no need to redundantly store the coordinates.
Of course, this relative simplicity (pardon the pun) certainly doesn't make it a simple matter to convince all of the organization's systems to use the unique location keys that MDM would create, or to model the location-asset and location-party relationships the same way that a MDM data model would.
But it is still easier than customer, since I have never had someone tell me they disagreed with the definition of a valid postal address or geographic coordinate :-)
Best Regards,
Jim
You're absolutely right Jim. The biggest barrier in the process is getting all parties to agree!