Domain teams want local data copies for autonomy, while the enterprise architecture board wants one centralized store for consistency. What is the sound response?
Select an answer to reveal the explanation.
Short Explanation
Autonomy and consistency pull like two dogs on one leash. Say the trade-off out loud, then add contracts, lineage, and shared definitions so neither side pretends the tension vanished.
Full Explanation
Domain teams often want local data copies for autonomy while enterprise architecture seeks centralized consistency for official city metrics and shared identity. The sound response is to make the autonomy-versus-consistency trade-off explicit and add compensating controls—interface contracts, lineage, quality gates, reconciliation cadence, and shared semantics—where consistency matters most for civic decisions. Unexamined centralization that always forbids domain-owned stores without analysis fails by choking delivery and ignoring legitimate workload, latency, or sovereignty needs. Unlimited silent duplication with no reconciliation or ownership fails by exploding conflicting truth, cost, and citizen-facing confusion. Declaring trade-offs irrelevant because tools will auto-harmonize without design fails by abdicating architecture to vendor myths. Exam caveat: the right balance varies by domain criticality—person identity and official KPIs usually need stronger consistency controls than ephemeral scratch data—and compensating controls must be real, funded, and tested, not aspirational slides. Operational check: for each contested municipal dataset, document the chosen default (shared versus local), required contracts and lineage, reconciliation frequency if copies exist, owners accountable for drift, and a quarterly review that detects silent forks before they reach council packets.