Chris Colyar, VP of Technology Consulting at Amplifi
One of the most fundamental components of any MDM implementation is the taxonomy. The taxonomy is the skeleton against which the entire solution is structured, supported, and enacted. If the taxonomy is wrong, it can lead to either violation of core principals around data governance or excessive work effort being spent to prevent and respond to those very principals manually. Product MDM is the domain with the most stringent taxonomy requirements, so we’ll use that as the primary subject.
You may have heard terms such as hierarchy or classification also used to describe this skeletal structure, and those could also be correct, but in many cases are actually talking about other things. The reason I specifically use the term taxonomy I like the analog to the scientific categorization of living things (remember “Kings play cards on fat green stools?”). In MDM, the taxonomy helps us differentiate two *things* not just by what they are, but by the data points, we can use to describe them: Shirts have size and material; TVs have screen size and resolution. The taxonomy also allows us to define how similar things are: Those TVs have an awful lot of similar attribution to computer monitors. A dog is a dog, but then again, a black lab and a collie can be pretty different.
Before I get lost in the metaphor, I’ll simply say, the taxonomy should be definitional. By giving an object a home in the taxonomy, we’ve concretely identified what that object is as well as all pertinent data points (pre-business-rules) needed to comply with our governance standards. That being said, that object can only have one home in the taxonomy. It *is* a thing. If you’re ever in a situation where your MDM object can have multiple homes in the taxonomy that means your taxonomy needs work, it isn’t a taxonomy at all (or you’re looking for the advanced write up in handling bundles, kits, and other “cross-breeds”)
One of those other things… categorizations, classifications, and hierarchies. These are also very important in any solution, but they serve different purposes. The primary use of each of these, in the end, is to reorganize your objects in a way that helps another purpose. They could be purely organizational; reflecting business units, brand structures, internal portfolio assignments, etc. They could be focused on presentation means; web navigable structuring, data point faceting, driving collection-oriented associations, etc. They could exist as primary structures in your operations already such as financial reporting, resource planning, merchandising, etc. They could be used to contractually integrate with other systems via standards such as GPC, UNSPSC, eCl@ss, etc. In most implementations, we have our primary taxonomy with objects associated with at least four other classifications.
I’ve learned from some great speakers over the years that you should leave your guests with something simple, structured, and actionable, because if you can’t, what were you trying to do? Anyway, I happen to love bulleted lists as well so…