A city enterprise architect must explain ingestion, storage, processing, and serving layers to non-technical directors. What is the main purpose of those layers?
Select an answer to reveal the explanation.
Short Explanation
Layers are like a kitchen line: intake, pantry, prep, and plating. Keep those jobs apart so the city is not stirring raw logs into the public dashboard by hand. One emailed spreadsheet is not an architecture.
Full Explanation
Layered Big Data architectures separate ingestion, storage, processing, and serving so each concern can scale and change independently. Directors should grasp that raw collection is not the same as curated delivery to apps and dashboards. Clear layer purpose prevents treating the lake as both warehouse and user interface for civic services.
Proving civic systems need only a single spreadsheet shared by email fails by concept: monoculture sheets are not layered architecture. Replacing all analytics with printed monthly binders and no digital serving fails by concept: serving layers exist to deliver digital results. Showing that processing erases the need to store raw records fails by concept: storage remains a distinct concern.
Exam caveat: Layers separate collect/keep/transform/deliver concerns—spreadsheet monocultures, paper-only serving, or processing-without-storage miss why layers exist.
Operational check: Brief directors with a four-box diagram (ingest/store/process/serve), name one civic system per box, and forbid “the lake is the app” language in architecture reviews. Document residual risk for civic operators and revisit after the next production change window. Confirm owners, SLAs, and rollback criteria in the runbook before go-live.