Emergency dashboards need second-level machine telemetry, while monthly grant statistics do not. What principle should architects apply?
Select an answer to reveal the explanation.
Short Explanation
A fire dashboard cannot wait for next month’s spreadsheet. Grant stats can. Match how fast the data arrives to how urgent the decision is—that is Velocity meeting the job.
Full Explanation
Applications differ in freshness requirements. Life-safety dashboards often need second-level M2M feeds, whereas monthly grant reporting tolerates batch latency. Architects should match source Velocity to application urgency rather than forcing one cadence everywhere. Misaligned latency wastes cost or endangers civic situational awareness.
Forcing every civic dataset onto a one-second streaming bus fails by concept: grants statistics do not need that cost. Using only monthly batch for life-safety dashboards fails by concept: emergencies cannot wait a month. Ignoring Velocity because Variety alone solves freshness fails by concept: format mix does not create timeliness.
Exam caveat: Match Velocity and latency to each application’s urgency—avoid one-cadence absolutism and do not confuse Variety with freshness.
Operational check: Publish an SLA matrix (life-safety seconds vs grants monthly), provision streaming only where justified, and review monthly whether any app is on the wrong cadence. Document residual risk for civic operators and revisit after the next production change window. Confirm owners, SLAs, and rollback criteria in the runbook before go-live. Record the decision in the architecture decision log for auditors.