The city proposes organizing stewardship around data domains such as customer, location, and asset. What operating-model idea does this apply?
Select an answer to reveal the explanation.
Short Explanation
Customer, location, asset—think chapters in the city's data story, each with a steward who knows that chapter. Domains keep ownership tidy instead of one giant orphan pile. Subject-area structure is how operating models scale.
Full Explanation
Domain-oriented operating models group related data subjects so owners and stewards align to business meaning and lifecycle across systems. When the city proposes organizing stewardship around domains such as customer, location, and asset, it applies that pattern so accountability follows coherent subject areas rather than only application silos. Requiring all data to report to a single spreadsheet owner with no domain structure creates bottlenecks and shallow expertise. Claiming domains are only for network VLANs and never for data stewardship confuses infrastructure terminology with IM operating models. Rotating stewardship randomly each week destroys continuity and learning on critical civic entities. Exam caveat: domain boundaries should be designed with real shared entities in mind; overlapping domains need clear lead owners for conflicts. Operational check: publish a domain map with owners, map critical systems into domains, and pilot stewardship rituals on one domain before citywide rollout. Municipal DG councils should resolve cross-domain disputes through documented leads rather than ad hoc email threads. Review domain boundaries annually as new shared civic entities appear across departments.