A municipality wants a target data architecture that can adapt as services change. What process stance best supports that goal?
Select an answer to reveal the explanation.
Short Explanation
Start with what the city must be able to do—license, bill, respond—and how fast, safe, and reliable that must be. Architecture that traces back to capabilities and non-functionals bends when services change; architecture that starts with a random tech stack snaps.
Full Explanation
Adaptable municipal data architecture is driven from business capabilities and non-functional requirements so designs can change as services change. Copying another city’s diagram without linking decisions to local capabilities produces ornamental architecture. Freezing technology choices first and deriving business needs afterward inverts good design. Treating non-functional needs as optional after the physical model ships leaves latency, security, and availability as afterthoughts. Exam emphasis: capability- and NFR-driven architecture. Caveat: capabilities should be expressed at a stable grain—licensing, utilities, public safety—not as fleeting project names. Operationally, list the service capabilities the architecture must enable, capture NFRs for freshness and protection, and evaluate design options against that matrix before locking platforms. Maintain a living NFR register for freshness, protection, and availability per capability so adaptable designs remain testable as services change. Revisit capability-linked architecture when services are reorganized so domain boundaries and NFR targets move with the municipal operating model rather than with forgotten diagrams. Non-functional targets should be measurable—minutes of freshness, recovery objectives, classification coverage—so adaptability can be verified, not asserted.