Shared datasets used across agencies lack owners, interface contracts, and freshness expectations. What modern architecture orientation addresses that gap?
Select an answer to reveal the explanation.
Short Explanation
If a shared dataset is a product, it gets an owner, a label on what’s in the box, and a promise about freshness—just like a service citizens rely on. Orphan dumps don’t earn that trust.
Full Explanation
Shared datasets used across agencies without owners, interface contracts, and freshness expectations are unmanaged byproducts. A modern architecture orientation treats shared datasets as data products with clear owners, contracts, and service levels so consumers know what to expect. Treating shared datasets as anonymous byproducts with no SLAs invites breakage. Hiding shared datasets from catalogs reduces accountability rather than risk. Assigning ownership only when a production outage is already underway is reactive governance. Exam language: data-product thinking for shared civic datasets. Caveat: product status implies lifecycle—versioning, deprecation, and support hours—not only a friendly name. Operationally, pick a cross-agency dataset, assign a product owner, publish contract and freshness SLA in the catalog, and measure consumer satisfaction and incident rate after the change. Review data-product SLAs with consuming agencies on a fixed cadence and adjust ownership when freshness or contract breaches repeat. Data-product contracts should state support hours and incident severity mappings so cross-agency consumers know how freshness failures will be handled. Without product ownership, shared datasets regress into anonymous extracts that break quietly across agencies until a public-facing failure surfaces.