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.