A service desk needs to recognize returning residents during the call, but party matching only runs in a weekly batch. What architectural concern does this raise?
Select an answer to reveal the explanation.
Short Explanation
If the match job only wakes up on Sundays, Monday's caller still looks like a stranger. Real-time desks need match latency that fits the conversation, not the batch calendar. Architecture follows the clock the business actually uses.
Full Explanation
A service desk that must recognize returning residents during the call while party matching only runs weekly raises an architectural concern: match and sync architecture must meet operational timing requirements; weekly batch may be too slow for real-time civic service. Latency design is part of MDM fitness-for-use. Claiming weekly batch is always sufficient because MDM never supports operations fails against the service-desk need. Telling desks to ignore identity and collect a new resident record every call fails by multiplying duplicates. Saying latency is irrelevant if the golden record appears in a monthly dashboard fails the operational use case. Exam caveat: match cadence must match channel latency needs—batch vs near-real-time is an architecture decision. Operational check: define maximum acceptable identity lag for the service desk, compare to current match/sync SLA, and upgrade to event or more frequent sync if weekly fails the test. Document the latency requirement in the municipal non-functional requirements for MDM. Keep verification evidence with the municipal runbook so audits can prove the chosen control was applied as designed and that rejected alternatives would have left city services exposed to the failure modes described above.