In the early days of MDM, a common question was, “union or intersection?” Business Unit A has 30 attributes for customer. Business Unit B has 50. 10 of them are common. The question was, in other words, “should MDM manage all 70 attributes, or just the 10 common attributes?”
The image conjured up in my mind is an enterprise data model that covers a good part of a wall. It doesn’t go very far because the model is too big. It tries to control everything, which in a large enterprise is a political dead-end. So we smartened up and said, let’s centrally control only what’s really important. That’s why we started doing MDM in the first place!
My response to the union-or-intersection question was, “as few as possible to accomplish your goal.” The best form of governance governs only as much as needed and no more. As a rule of thumb, go for the intersection, not the union. Maybe even a subset of the intersection.
Federalism means the central authority should have control only over a limited and clearly defined set of the things. The rest would be locally controlled. It strikes a balance between scale and agility. Apply this to master data, it means the MDM program should be responsible for a limited set of shared and important data elements, which, when centrally managed, brings about benefit that outweighs the cost. Everything else should be locally managed. “Local” could be a business unit, a functional areas, or a geographical region. The MDM program should not seek to control every attribute.
Besides benefit-cost considerations, it’s hard to get buy-in for centrally controlling every attribute. Business units with some degree of autonomy would violently object to handing over control of all their master data to a central authority. Especially when that central authority is IT. Imagine when they need to add an attribute only useful for that business unit, and having to go to corporate IT and get on a queue. It compromises local agility. If they’re forced to do so, they’d create a shadow IT organization.
But a limited subset doesn’t mean it’s easy or insignificant, because those attributes are typically the most important. They’re used very widely, therefore definitions and rules are the most contentious. A major oil company decided to govern only 5 attributes of customer across every geography and every line of business. And that is a massive multi-year effort. Many companies opted to only govern the IDs or keys for master data. In these cases we see federalist principles in action.
A great case study is a global CPG company that applied federalism to their product hierarchy. The headquarters of this $50 billion company maintains a standard corporate product hierarchy in a global MDM instance, whose lowest level is “Global Product.” At this level, packaging and localization attributes do not exist. The hierarchy is designated as federal master data and distributed to all regions around the world monthly.
Each region maintains its own MDM application, which receives the read-only global hierarchy. The local MDM applications allow regional product managers to manage as many entities as they like below “Global Product”. Furthermore, the regions are responsible for mapping their regional products to “Global Product.” The regional product master is then distributed to the next level of federation: the local applications, including ERP, CRM, SCM, and other legacy applications. Each application maintains its local product data.
This policy helps create consistent and high-quality product master data worldwide, and enables global brand/category management and financial reporting. At the same time, because it still allows a high degree of local autonomy, local agility is preserved.
In the next blog of this series, I’ll write about federation for BI and data warehousing.
The posts in this blog series on federalism in data management: