One of the most fundamental components of any MDM implementation is 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.
Let’s clear up what a taxonomy is.
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”)
But wait, if it isn’t a taxonomy what is it?
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, [email protected], 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…
When designing your taxonomy:
- DON’T Bake in purely organization elements that don’t help define… Some of the biggest gotchas I see are Brand, Region, and Status
- DON’T make your taxonomy overly simple and generic… unless it’s a strategic decision to not care about differentiating those things
- DON’T make your taxonomy too complicated… There should be a describable benefit for each node in the taxonomy because there is a cost to maintain the governance on them
- DON’T implement an industry-standard as YOUR primary taxonomy without strong consideration… they are probably more volatile than you are, they are probably much broader than you need, they likely don’t provide specificity in your areas of specialty.
- DO try and keep it top-down usable… If you are looking to put something in your taxonomy; there should be one obvious level 1 node for it; within that level 1 there should be one obvious level 2 node for it; until you get to your leaf-level where it lives.
- DO implement a taxonomy that will be stable… not because they *can’t* change but because they shouldn’t *have* to. NOTE: There will be additions as you expand your offerings, splits as you refine your governance in areas, combinations as you move out of segments, and other intentional strategic shifts as business shifts.
- DO consider rolling out business rules to handle mapping your taxonomy to your other classifications where the task can be algorithmically described… Usually, a combination of branch/leaf and attribute(s) can map to most organizational restructuring, including standard classifications.
- DO dedicate the effort to ensure your taxonomy is well defined and efficient for today and scalable for whatever tomorrow may bring you…