Multi-Domain and Federated MDM Hubs: Two Key Considerations
As the early adopters of Master Data Management are starting to move beyond their single data domain implementations and branching out to other domains, we’re seeing the timely arrival of MDM hubs capable of handling data from multiple domains. So, what are multi-domain and federated hubs? What are some key questions to consider? And what are companies tending to adopt for global strategies? Here’s my take on these questions.
The first key consideration is “what business problem are you trying to solve with MDM?” The answer will point you in the direction of what data is required to solve that business problem. Invariably in this “business process centric” approach to MDM data, you’ll discover that you need data from multiple domains to solve the problem.
The term “multi-domain” has emerged as a way of distinguishing MDM hubs capable of managing more than one primary domain of data. The need for the term arose to distinguish single domain hubs (such as a dedicated product information management or PIM hub) from “multiform” MDM hubs from Siperian, IBM or Oracle, all of which are capable of managing multiple domains of data such as customer, supplier, product, location, and their associated hierarchies.
The rollout strategies that companies are adopting for their MDM initiatives are to start small and then build from there. In the “business process centric” approach, as each additional business problem is tackled by an organization, additional domains of data are added to the MDM hub, using the same methodology for each successive problem.
While this approach sounds similar to a data warehousing analyst, the key to the MDM approach is that data stewards (reporting to the business function) will manage the data within a data governance framework. In other words, a business process solution which is capable of being managed by the business.
The second key consideration is “how will you achieve enterprise MDM?” That is, managing MDM data on a global basis using a centralized hub vs. a series of federated hubs. While the term “federated” has been used in association with Registry style MDM hub implementations, the term is now also used with the Persistent style hubs, but using a different architecture from Registry style hubs.
Companies have two options in addressing a global deployment of a Persistent style MDM initiative.
The first is to implement a centralized hub in a single location that will be accessed from all other locations as data is needed. This requires constant synchronization of data between global source systems and the centralized persistent hub.
The second option is for each location to maintain its own local hub and then federate across the local hubs to a single corporate hub. The federation of persistent hubs requires the infrastructure to maintain data and metadata synchronization between local hubs and a corporate hub. Data sources will be synchronized at the local level with each local persistent hub.
The deployment strategies that most global corporations are following with Persistant style MDM hubs is to use federation across local persistent hubs rather than a single centralized hub in one location that must be accessed from all other locations for MDM data.
The federated approach avoids overlapping data in local hubs and with a common set of technologies in all global locations supports a consistent data stewardship approach.
For those of you who have implemented master data management in your organization, please let us know whether you’ve chosen a centralized hub or a series of federated hubs.