Each operational application keeps its own conflicting copy of customer-of-record attributes. When governance can support it, what operational architecture preference is stronger?
Select an answer to reveal the explanation.
Short Explanation
Five apps with five ‘customer truths’ is five arguments waiting to happen. When stewardship is real, a shared master data service hands out the authoritative attributes so apps stop inventing their own copies.
Full Explanation
When each operational application keeps conflicting customer-of-record attributes, and governance can support it, prefer shared master data services that supply authoritative attributes instead of embedding unmanaged duplicates in each app. Encouraging more embedded duplicates so every app owns a private truth multiplies reconciliation cost. Banning all shared services regardless of stewardship maturity ignores a valid pattern once ownership exists. Synchronizing duplicates only through unmanaged spreadsheet exports is fragile integration theater. Exam preference: mastered shared services when stewardship is ready. Caveat: master data without stewards and quality rules becomes a centralized mess; maturity is part of the decision. Operationally, select a high-pain citizen attribute set, stand up a governed master service with stewards, point two pilot apps at it, and measure reduction in conflicting values before wider rollout. Expand master-data scope only after pilot apps show reduced citizen-attribute conflict and stewards meet agreed quality SLAs. Shared master services should expose data-quality scores for authoritative citizen attributes so consuming apps can fail closed when mastery confidence drops below policy.