Part 4: The 3 Types of Multidomain MDM Architectures
Posted by 
Share this Post
There are three main types of multidomain architectures.
Organizations that decide to master more than one data domain are best served by deploying an MDM architecture that has a coherent, unified approach to dealing with all master data types, rather than having inconsistent approaches to each one and a profusion of data hubs based on disintegrated technologies.
Once you decide on the domains of highest value to your organization, you’ll need to wrestle with how to implement your multidomain MDM solution.
However, there are three main types of multidomain MDM architectures: registry, hybrid and centralized. What are they, and how do you choose the best one for your needs? We’ll cover that in the next few posts in the Multidomain MDM series.
Determining which architecture style is best for your organization will depend on a number of factors including:
- How the data will be used
- The number of applications that will rely on the solution
- The stability of the ecosystem within which the solution will exist
- Specific requirements for transactional throughput, uptime, response time, performance and scalability
Organizations should consult with an experienced enterprise architect to help them decide which architectural style makes the most sense. Enterprise architects have the requisite skills to define the characteristics of the system and to evaluate how specific business needs can and will be addressed by a chosen model today and in the future.
All three styles have something in common; they all have a master data service that is the container for simple or complex master data objects. However, the three styles differ in the extent to which they store the data inside these containers.
The differences in these three styles are in the extent to which they store data inside these containers. For example, the registry style does not store all the data about the composite objects in the container, but instead stores only key references to the objects from the contributing systems. The actual detailed data is left in the external source systems. A registry system is based on a federated model that only brings the data together to complete a master data object as required.
Like the registry model, the hybrid model stores the key references to the composite object locally, but it also copies in all of the attributes required for that composite object from the outlying master data services. With a hybrid style, supplier, product, customer and other master data continue to reside in their external source systems, but a copy of the data from the different master data services is also in the centralized composite.
The centralized style consolidates multiple domains of master data into one location. In this model, customer, product, location and other master data services are no longer sourced by external systems, but instead from the centralized hub, which contains all of the attributes of the composite objects in one location and acts as the master for all data.
Companies need to determine which architectural style best meets their multidomain MDM requirements.
We’ll cover more specifics about each of the three models, as well as a guide for choosing which one best suits your needs, in the next multidomain posts.
This post is part of Marty Moseley's Multidomain MDM Series. View the table of contents for links to any parts you may have missed.
2 Responses »
Leave a Response
Entries(RSS)
If you look on MDM as a business philosophy or culture, then the scope widens into such things as published content (does the contact centre give the same information as the web site), centralised photograph stores, public domain master data such as Bing, Google earth and PO Addresses. There's also standard classifications such as "ethnicity" and "property type" and you may even consider metadata to be MDM in itself. I wonder therefore if "three types" isn't a bit simplistic though maybe you could shoehorn the other types in as it is usually wise to be pragmatic.
Another problem is that one person's master data might be just a classification of a bigger set, for instance, the person who only deals with public toilets isn't interested in the fact that it's just another property. Could this (contextualised data not public toilets) be deemed a "type"?
So is it as simple as three types or is it more complicated than that?
Hey Allen -
Great questions!
Let me try to help if I understand you correctly.
One core issue you're dealing with is "What is Master Data?" That's been covered elsewhere so I won't say too much about it. Suffice it to say that just because data are shared doesn't mean they're "master data." I think of master data as those "critical few" data which are foundational to an organization's success - not anything that's shared.
Now to your question of whether three types is overly simplistic: Yes, it might be, but in our experience, implementations fall into some hybrid of these styles - IOW, it is not uncommon for an installation to choose a Registry (or Federated) style, but also choose to put some additional attributes on those records other than keys, because there's no natural home for those in any of the endpoint apps.
I guess you could come up with another style, and I'd love to see what you are thinking. To me, you're either storing just keys and using federation to amalgamate the data you need, or you're including all shared data in the hub b/c you can't incur the overhead of assembling when needed, or you're mastering everything in real time in the hub, or you have some hybrid combination of those in the same implementation. Everything else you refer to can just be "payload" data or additional sources that may, as you point out, contain unstructured data.
Did I understand you correctly?
Thanks again!
Marty