There are four different architectural styles possible in MDM. The architectural styles are different from Master Data Management architecture patterns. Architecture styles show the way an MDM is actually implemented, whereas the architecture patterns are more for the purpose of application of MDM. It is also possible that you can implement your MDM infrastructure by following one or combination of these architecture styles.
The MDM Architecture styles are:
External Reference Style for Master Data Management
In this style the MDM-CDI hub is a virtual reference for the data, which is physically laying in the source systems. In other words, the MDM Hub does not contain any physical data, but the pointers to the data. This means that when a client system (the system which is using the data from the MDM platform), places a request for customer data (say), the MDM hub will point the request to the source system which contains the physical customer data. The other implication of this style is that the source system (which contains the physical data), will be doing all the sanitization and standardization of the data.
Here are the situations in which this architecture style is suitable;
- Few or one source system for a given master data- This style will typically not work, where there are 4-5 systems(say) having individual slices of customer master data. It will be difficult to ensure that all of them are following the consistency, standardization and sanitization of data
- When there is little or no overlapping data across the source systems: If you have three systems carrying the slices of Customer Master Data with no overlap, its fine. If there are overlaps, you will be having implementation issues in specifying the true source of a given customer record.
- When you just want to have the reference for a given customer through customer_ID. This kind of architecture does not help when you are searching for an existing customer on other unique identifiers. For example- this will work if I want to have the data on customer ID WS2345, but will not work if I want to have the customer data for the customers who were born in 1965, and stay in New York State.
Registry Style for Master Data Management
This is next level of sophistication. The difference between external reference style and the registry style is that the registry style also carries the unique identifier fields, while still maintaining the pointers to the physical data lying in the source systems. For example, while the external reference style will just carry the customer ID, the registry style will contain the address, email, PIN code, telephone numbers etc.
Another clarification!!- the registry style does not carry only the unique identifier fields, but other fields, which can help it to do a quick search on finding the right record for you. For example, the unique identifier fields could be just an email ID. However, the registry style hub will contain the name, address and other details to help a client system (system which uses MDM for information) to search for the customer (s)
The registry style is done in the similar scenarios as the external reference. It is also used for the following additional situation:
- When the client systems are searching for an existing customer or are checking if a customer already exists.
- When the client systems need only the limited number of fields, which are available in the hub itself. For example, if you feel that 50% of the usage of MDM will be to seek 4-5 key fields, you may place them in the registry style, even if they are more than being a unique search identifiers.
The registry style is typically one way update of the Hub by the source system. The Hub will not be updating or checking on the sanity of data in the client system.
Reconciliation Engine for Master Data Management
It is like registry style, but is not limited to only unique identifier or search-needed fields. One can be flexible on which fields you want to maintain in Hub and what fields in the source systems. The other key difference is that unlike registry styles, where the source system is the master reference of attributes contained in Hub, the reconciliation engine has Hub being the master reference of the attributes contained in it. For example-
In registry style, while you are maintaining the name, address and email of the customer, the data will be provided one-way by the source system. In reconciliation engine, the updation of these fields in done in the Hub and then updated in the source system.
Transaction hub for Master Data Management
This is the ‘nirvana’ architecture style, whereby all attributes of the master data are maintained in the Hub and the Hub is the master reference of the entire master data. The source system will not contain the master data (and refer to Hub for its operational needs) OR even if it contains the master attributes, they will be updated one way from the Hub. This kind of architecture is typically used when you have multitude of reference points for Master data, which you want to bring into a common platform. More than resolving an issue, this kind of architecture is a great opportunity, as it truly integrates the Master data as an enterprise resource.
TIP- In a typical evolution path, one starts with registry style and progresses through external reconciliation and finally to transaction hub. There are many MDM platforms, which enable you to move to Transaction Hub and that is possible when you have 2-3 systems having a given master data.
TIP- The above architecture styles are for one master data type (say customer). You may end up adopting different styles for different master data types, given the state, quality and distribution of your master data. |
