...
Ultimately, the MDM architects create a worksheet that contains the required attributes to complete an operation for a given entity for a given adaptor.
If an HTTP Operation
...
Is Not Required for an Adaptor,
...
Don't Analyze It
Example: There is never a situation where the analysts for the College Application system wants the MDM system 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 an MDR Should Generate a Notification 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 Elements Are Used by Only One System,
...
Then Don't Normalize Them
...
Unless They Are Used Inside Another Data Domain
The job of a MDM analyst is to create as little work as possible. A single element added to an MDR has an exponential effect on the complexity of the overall system.
Example: A college system uses an Ed Planning system that tracks meetings between the student and college faculty and staff. No Others systems may use the Ed Planning data but if no other systems in the systems use the system track such information so this scheduling system, then the schedulng data can be ignored in respect to MDM.
A Couple of Additional Points
...
The MDM adaptor might need to read and manipulate non MDR attributes to complete transactions
When building an MDR worksheet you also need a “non MDM” worksheet too to keep track and reference elements not considered for the MDR
...