A newly annexed department brings five legacy systems into the city’s data estate. What should architecture provide so onboarding is repeatable?
Select an answer to reveal the explanation.
Short Explanation
New neighbors need a welcome packet, not a scavenger hunt. A standard onboarding blueprint—interfaces, owners, classification, quality—keeps each department from reinventing chaos.
Full Explanation
When a newly annexed department brings five legacy systems into the city’s data estate, architecture should provide a standard onboarding blueprint covering interfaces, ownership, classification, quality expectations, identity and access patterns, retention, and observability hooks. Repeatable onboarding reduces one-off risk, accelerates safe integration, and creates even trust levels so citizens and staff are not surprised by uneven controls across systems. Ad-hoc weekend heroics with no checklist fail by producing uneven couplings, forgotten stewards, and undocumented exceptions that resurface in audits. Inventing a unique undocumented path for every department fails by preventing organizational learning and multiplying brittle snowflakes. Immediate production write access for all new systems with no review fails by bypassing security, quality, and system-of-record gates. Exam caveat: a blueprint is a minimum bar, not a claim that every system is identical—documented, risk-assessed exceptions remain acceptable when compensating controls are explicit. Operational check: run the five systems through the onboarding checklist; record owners, classifications, interface patterns, and quality baselines; withhold production write paths until checklist sign-off; and store the completed package in the architecture repository for reuse on the next annexation.