Project teams keep making conflicting trade-offs on master data and automation of controls. What foundational artifact should architecture publish?
Select an answer to reveal the explanation.
Short Explanation
Principles are the house rules on the fridge—master data once, automate policy where it pays off—so every project isn’t inventing new morals. Written principles make trade-offs consistent instead of random.
Full Explanation
Conflicting project trade-offs on master data and control automation signal the need for an explicit architecture principles catalog—such as mastering data once and applying policy as code where practical—to guide decisions consistently across municipal initiatives. A secret list of preferred vendors with no rationale is not a principles catalog. Per-project slogans that expire when the project ends provide no enterprise memory. Banning documentation of principles to “preserve flexibility” guarantees repeated incompatible trade-offs. Exam artifact: architecture principles as decision guides. Caveat: principles should be testable and allow documented exceptions; vague posters nobody applies do not help. Operationally, ratify a short principles list with examples for master data and automated controls, require architecture reviews to cite principles, and track exceptions with expiry so flexibility stays visible rather than silent. Require exception tickets against principles to carry an expiry date; expired exceptions must be re-justified or removed. Principles catalogs should include a short anti-pattern list—such as unmanaged spreadsheet sync for master data—so teams recognize rejected trade-offs quickly in review.