A project proposes a new “integration database” so every department can dump and query shared tables freely, with no named owner or quality controls. What is the main architecture risk?

An ownerless “integration database” where every department dumps and queries shared tables freely is a classic architecture anti-pattern. Without named stewards, quality controls, and clear system-of-record status, the store becomes ungoverned sprawl: conflicting schemas, silent dependencies, unclear trust, and change control that no team can safely exercise. Consumers cannot tell which fields are authoritative, producers cannot change structures without unknown blast radius, and audits struggle to assign accountability. Concern that documentation will slow informal teams misses the point—absence of ownership, not presence of light documentation, is the failure mode. Vendor licensing refusal is not a genuine architectural constraint of shared databases and distracts from governance design. Claiming the pattern always improves lineage automatically without stewardship is false; lineage and trust require intentional contracts and controls, not communal dumps. Exam caveat: mediated hubs, lakes, or API platforms can be sound when ownership, contracts, and quality gates exist; the exam rejects ownerless free-for-all stores, not all shared integration approaches. Operational check: refuse to stand up a shared dump without a named owner, write policy, quality rules, and change process; prefer published interfaces or a governed hub; and inventory writers/readers before any new table is added.