A business unit at a retail bank wants to procure a specialist analytics platform that duplicates capabilities already provided by an existing enterprise data warehouse. A risk practitioner is asked how the enterprise architecture function should be used to manage the IT risk this decision creates. What is the most appropriate role for enterprise architecture here?
- AUse the architecture review to assess the proposed platform against the target-state architecture and surface the redundancy and integration risk before approval. Correct
- BLet the business unit procure the platform first and ask the architecture function to document it in the repository once it has been deployed into production.
- CDefer entirely to the business unit because tool selection is a local operational matter that sits outside the remit of the enterprise architecture function.
- DEscalate the request straight to the audit committee so an independent review can decide whether the analytics platform should be purchased at all.
Why A is correct: Architecture review checks a proposal against the agreed target state, which is exactly where duplication and integration risk are caught before money is committed and the estate fragments.
Why B is wrong: Recording a tool after deployment keeps the repository current, but it does nothing to manage the risk of the purchase itself and locks in the redundancy the practitioner was asked about.
Why C is wrong: Treating selection as purely local is tempting for autonomy, but it ignores that overlapping platforms raise enterprise integration and cost risk that architecture exists to govern.
Why D is wrong: Audit-committee escalation sounds rigorous, but it bypasses the architecture review that is the correct first-line mechanism and is disproportionate to a routine procurement decision.