Leaders ask what principle should close a data-architecture program so tomorrow’s team can evolve the estate safely. What should be emphasized?
Select an answer to reveal the explanation.
Short Explanation
Architecture is a gift to the next crew, not a trap. Write down the constraints, interfaces, and who owns what so change stays safe instead of archaeological.
Full Explanation
Closing a data-architecture program with lasting civic value means emphasizing documentation of constraints, interfaces, and ownership so tomorrow’s team can evolve the estate safely. Evolvability depends on those explicit elements—not on secrecy, tribal knowledge, or permanent freezes—because municipal needs, regulations, and integrations continue to change. Maximizing undocumented tribal knowledge so only today’s experts can change anything fails by creating bus-factor risk and accidental breakage when staff turn over. Hiding interfaces and ownership so teams discover dependencies only in production fails by institutionalizing outage-driven learning at citizen expense. Freezing the estate forever and rejecting all future evolution fails by turning architecture into a museum that cannot meet shifting civic priorities. Exam caveat: documentation must stay current enough to be trusted; stale diagrams without ownership updates can mislead—pair lightweight living catalogs with architecture decision records for consequential choices. Operational check: verify that critical interfaces have owners, published contracts, and constraint notes; sample a proposed change and confirm dependencies are discoverable before production; schedule periodic catalog hygiene with accountable stewards; and include documentation freshness in architecture health reviews.