A parks department debates whether Big Data applies only to an enterprise-wide Hadoop program or also to a departmental analytics effort on semi-structured reservation and IoT feeds. Which view matches BDPC scope thinking?
Select an answer to reveal the explanation.
Short Explanation
Big Data is not a VIP badge that only the enterprise Hadoop team gets to wear. If a parks crew is drowning in semi-structured feeds at real scale, that local pain is still Big Data territory. Enterprise programs are one level of adoption—not the only door.
Full Explanation
BDPC scope thinking treats Big Data as a workload condition that can appear at enterprise breadth or as a local high-scale problem. A parks department drowning in semi-structured reservation and IoT feeds can be doing Big Data work even without a citywide Hadoop program. Civic value does not wait for a mayoral "enterprise AI" brand; departmental service quality—bookings, occupancy, equipment health—can still demand Big Data practices.
Claiming Big Data exists only after every department shares one Hadoop cluster fails by concept: organizational politics do not define the technical threshold. Saying departmental feeds never qualify unless branded "enterprise AI" fails by concept: naming and branding are not workload tests. Restricting Big Data to finance relational warehouses and excluding parks IoT fails by concept: IoT and semi-structured civic feeds are classic Big Data sources when scale and complexity demand it.
Exam caveat: Big Data is about difficulty and characteristics of the data workload, not about whether the project holds an enterprise badge or lives only in finance.
Operational check: Assess parks reservation and IoT feeds against volume, velocity, variety, and current tool limits; if conventional tools fail, treat the departmental effort as in-scope Big Data and plan architecture accordingly.