...
This provides some background on many of the challenges in orchestrating the MDM process when defining data domains a Federated data management system. The process of moving an organization towards is MDM is rigorous but if done properly, it provides a single interface for governance, data event notifications and a golden source of truth operational data store.
...
It is common for organizations to have duplicate information on different systems. For example, student information could be stored in both an SIS and Learning Management System (LMS). As more systems are brought on line, more data is duplicated. Disparate systems aren't necessarily a bad thing but are often a sign that an organization allows groups to acquire systems that meet their needs.
...
Example: There is never a situation where the analysts for the College Application system wants YOUnite to create (POST) a new student - they need to maintain control of that process so there is no need to analyze the required elements for a POST /student for the College Application system.
Generally Speaking, All Changes to a Data Record Should Generate a
...
Change Event to All Adaptors Interested in That Data Domain
If that application tied to an adaptor has a well written RESTful interface it will allow you to register a callback for changes -- if not then you will need to discover a way to detect changes.
...
Example: A college course catalogue system would not get a notification that a student has been deleted from the system but several others would such as the college application system and the college SIS.
If data sychronization is happening outside of MDM there is a good possibility that MDM won't detect it and the benefits of unified data governance and data event notifiations won't be realized.
If Data Elements Are Used by Only One System, Then Don't Normalize Them Unless They Are Used Inside Another Data Domain
...