Permitting remains authoritative in a departmental SQL system while a Big Data platform will power citywide analytics. How should the architecture integrate them?
Select an answer to reveal the explanation.
Short Explanation
The SQL permitting system still owns the truth for clerks. The lake should sync that truth for analytics—not pretend HDFS suddenly became the cash register.
Full Explanation
Permitting should remain authoritative in its departmental SQL system of record while the Big Data platform powers citywide analytics by syncing or landing permitting data—without blindly replacing the OLTP system clerks rely on for transactions. Architecture integrates the system of record and analytical platforms; it does not pretend HDFS suddenly became the cash register. Immediately shutting down the SQL system and forcing clerks to edit HDFS files by hand breaks operational workflows and transactional integrity. Ignoring SQL and scraping citizen screenshots from the public website yields incomplete, brittle, non-authoritative data unsuitable for official analytics. Duplicating every permit keystroke into three unrelated spreadsheets increases error and still fails enterprise integration and lineage. Exam caveat: system-of-record versus analytical copy is a classic BDPC distinction; landing data for analytics is not the same as migrating the system of record. Operational check: define CDC or batch extract from permitting SQL into the lake or warehouse, keep clerks on the SoR UI, reconcile row counts nightly, and publish which store is authoritative for operational edits versus analytics consumption.