A program places the only master person hub exclusively behind the warehouse team for analytics, while operational permitting apps keep creating conflicting local persons. What placement mistake is this?
Select an answer to reveal the explanation.
Short Explanation
If the master person file only lives in the reporting attic, the front desk keeps inventing new people. MDM belongs with operations and clear system-of-record rules—not only the warehouse.
Full Explanation
Placing the only master person hub exclusively behind the warehouse team for analytics, while operational permitting apps keep creating conflicting local persons, treats MDM as analytics-only. That placement mistake leaves operational create/update paths generating divergent identities that analytics cannot heal after the fact. Sound architecture aligns the hub with operational ownership, system-of-record rules, synchronization patterns, and interfaces that both operations and analytics consume. Giving operations golden-record access by design is not itself the mistake described; operational alignment is usually required. Publishing reference codes through a shared service is a healthy pattern, not the error. Documenting stewardship and match rules for operational and analytic consumers is part of correct MDM practice. Exam caveat: analytic copies or warehouses may still consume master data, but the hub’s authoritative create/update path and stewardship cannot live only in BI if operations remain the source of conflicting records. Operational check: map where person records are created today; define system-of-record and sync rules; expose operational APIs or services for golden identity; and measure decline in conflicting local person keys after cutover.