Business units want local flexibility, while enterprise risk needs common guardrails. Which governance pattern fits?
Select an answer to reveal the explanation.
Short Explanation
Think house rules plus room rules: the enterprise sets the guardrails everyone shares, and domains fine-tune inside those lines. That federated mix beats either a rigid dictatorship or a free-for-all.
Full Explanation
When business units need local flexibility and enterprise risk needs common guardrails, federated governance is the fitting pattern: domains set standards within enterprise constraints rather than choosing pure centralization or pure anarchy. Centralizing every field definition in one team and banning local standards entirely fails by creating bottlenecks and ignoring legitimate domain nuance in diverse city services. Letting each domain invent unrelated rules with no shared constraints fails by fragmenting identity, privacy, and quality expectations across agencies that must still share data. Postponing all standards until a single global data warehouse ships fails by tying governance to a distant architecture milestone while daily civic work continues without guardrails. Exam caveat: federated does not mean unconstrained—enterprise policies remain the fence, domains operate inside it. Operational check: publish the enterprise guardrails (privacy, classification, stewardship minimums), charter domain councils with decision rights inside those rails, and review a sample conflict to confirm escalation to the city data council works. Document the federation model in the operating charter so local innovation and citywide risk controls remain intentionally balanced.